File Transfer Protocol
Enable an agent to recognise File Transfer Protocol (FTP), assess an implementation or session, and determine which file operations are supported, authorised and safe.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
recalled by Codex without web access - no source was read
Researched by: Codex
Purpose and description
Enable an agent to recognise File Transfer Protocol (FTP), assess an implementation or session, and determine which file operations are supported, authorised and safe.
File Transfer Protocol (FTP) is an application-layer protocol for transferring files between a client and a server over TCP, using a control connection and separate data connections for file contents and directory listings.
It can be Identify whether an endpoint speaks FTP and determine its supported extension profile.; Establish an authorised session with the required peer validation and channel protection.; Select and test a compatible active or passive data-connection method.; List, retrieve or modify remote files within explicit operation permissions.; Assess whether an interrupted transfer can be resumed or retried without unacceptable duplication or overwrite.; Interpret replies and verification evidence to report successful, failed or indeterminate outcomes..
Distinguishing features
An FTP exchange uses a command-and-reply control connection and separate connections for directory listings or file data.
FTP control exchanges include commands such as USER, TYPE, RETR and STOR, with structured three-digit replies.
Active and passive FTP differ in which peer initiates the data connection; this is distinct from the direction in which a file is transferred.
FTPS applies TLS protection to FTP; SFTP does not use FTP's command and separate-data-connection model.
FTP transfer settings can affect representation, so a successful text-mode transfer does not necessarily imply byte-for-byte identity.
Scope
+ FTP identity, specifications and negotiated extensions
+ Control-channel commands, replies and session state
+ Separate data connections and active or passive operation
+ File-transfer representations, directory operations and restart behaviour
+ Authentication, transport protection and operation permissions
+ Protocol-specific interoperability and transfer-outcome evidence
- SFTP, which is a separate protocol associated with SSH
- HTTP file delivery and other neighbouring transfer protocols
- General TCP/IP routing, firewall administration and network infrastructure
- File contents, business meaning and document lifecycle
- General filesystem design, storage durability and backup policy
- FTP client and server product management beyond protocol behaviour
Characteristics
- Protocol specification and extension profile
- Applicable FTP specifications, extensions and implementation documentation Determines which behaviours are required, optional or implementation-specific.
- Advertised and observed capabilities
- Advertised features; commands accepted, rejected or untested Capability advertisements and demonstrated support provide different evidence.
- Control-session state
- Disconnected, connected, authenticating, authenticated, transfer pending, closing Command validity and the interpretation of replies depend on session state.
- Data-connection mode
- Active or passive; PORT, EPRT, PASV or EPSV where supported Determines connection initiation and influences reachability through network boundaries.
- Transfer representation
- Negotiated TYPE, including ASCII or image/binary Representation affects transformations and the meaning of size or identity comparisons.
- Authentication context
- Session identity, authentication mechanism and applicable authorisation policy Establishes whose permissions govern requested operations.
- Channel protection
- Control and data protection recorded separately, including TLS negotiation and peer-validation results A protected control connection alone does not establish that file data is protected.
- Requested file operation
- Retrieve, store, append, list, inspect metadata, rename, delete or manage directories Different operations require different permissions and carry different mutation risks.
- Transferred data volume
- Bytes, with whether counted on the connection or in the local representation Supports progress and outcome assessment without assuming counts prove integrity.
- Transfer outcome
- Not started, in progress, protocol-reported success, independently verified, failed or indeterminate Separates successful protocol completion from verified content and uncertain partial effects.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 18 findings · 30 questions.
FTP identity and profile Establishes the protocol boundary and the capabilities applicable to a particular implementation.
An agent must distinguish FTP from similarly named protocols and avoid assuming every FTP endpoint supports the same extensions.
Protocol boundary
Identifies the FTP sense and its relationship to protected variants.
FTP identification evidence
Record evidence of FTP command-and-reply behaviour rather than relying solely on a service label or port.
- What observed exchange or authoritative documentation identifies this service as FTP? definition
- Does the service use FTP, FTP with TLS, or a separate protocol such as SFTP? boundary
Extension profile
Separates specified, advertised and demonstrated capabilities.
Capability evidence
Record the applicable specifications and evidence for individual supported commands or extensions.
- Which specifications and implementation documents define this endpoint's claimed FTP profile? provenance
- Which capabilities are advertised through FEAT or documentation, and which have been confirmed by permitted use? measurement
Control session and replies Models command sequencing, session context and interpretation of server responses.
FTP replies can indicate intermediate progress, a request for further input or final completion; confusing these leads to incorrect actions.
Session context
Tracks the protocol context in which a command will execute.
Command preconditions
Record authentication state, working directory and negotiated settings relevant to the next command.
- What identity, working directory and transfer settings currently apply to this control session? measurement
- What state transitions or preceding commands are required before the requested operation? action
Reply interpretation
Connects replies to pending commands and their completion state.
Preliminary and final replies
Distinguish acceptance or progress from final success and classify failures without treating reply text as a substitute for reply structure.
- Does the received reply report preliminary progress, completion, a need for further information or failure? definition
- Which final reply is still required before the agent may report the pending operation as complete? action
Data connection establishment Models the separate connections used for file data and directory listings.
A working FTP control session does not prove that a data connection can be established or that its destination is acceptable.
Active and passive negotiation
Records connection initiation, addressing and supported negotiation commands.
Data endpoint selection
Identify which peer opens the data connection and how its destination is obtained.
- Will the client or server initiate the data connection, and which of PORT, EPRT, PASV or EPSV establishes its parameters? definition
- Which supported method is compatible with the observed address family and network restrictions? action
Data path validation
Assesses reachability and the acceptability of the negotiated peer.
Reachable and authorised peer
Treat the negotiated data destination as something to validate, including when addressing is affected by NAT.
- What evidence shows that the negotiated data connection can open and carry the requested listing or transfer? measurement
- Does the proposed data peer satisfy policy, or would it cause an unauthorised third-party connection? boundary
File semantics and recovery Defines how FTP operations address files, represent data and handle incomplete effects.
Transfer completion alone does not settle byte preservation, overwrite behaviour or whether retrying an operation is safe.
Paths, metadata and representation
Records the remote namespace and transfer settings needed to interpret an operation.
Target and content interpretation
Establish how a pathname resolves, how metadata is interpreted and whether the selected representation preserves the required content.
- How do the current directory, pathname encoding and server conventions determine the target file? definition
- Are directory facts obtained through MLST or MLSD, an implementation-specific LIST format, or another supported mechanism? provenance
- Which TYPE setting matches the required text conversion or byte-preservation behaviour? action
Completion and restart
Tracks partial files, final replies and the evidence needed for recovery.
Verified outcome and safe retry
Separate protocol-reported completion from content verification and assess the effects of restart, append or replacement.
- What final reply, size comparison or independently available integrity evidence supports the reported outcome? measurement
- Does the endpoint support REST for this operation and representation, and what identifies a valid restart position? boundary
- After interruption, should the agent resume, restart, inspect a partial target or seek a decision because retry could overwrite or duplicate data? action
Authentication, protection and authority Establishes the session's identity, channel protections and permitted file effects.
FTP capability, successful authentication and permission to perform a particular operation are separate conditions.
Identity and channel protection
Records authentication and protection of control and data traffic independently.
Protected authenticated session
Assess credential exposure, TLS establishment, peer validation and data-channel protection without assuming that FTPS secures every channel automatically.
- How is the session authenticated, and are credentials sent only under the protection required by policy? measurement
- How is TLS established, how is the server identity validated, and what protection applies to each data connection? measurement
Operation authorisation
Connects requested protocol actions to allowed effects on remote files.
Permitted file effects
Record authority to read, create, replace, append, rename or delete the specific target, including anonymous-session restrictions.
- Which target-specific operations are authorised for this identity and the agent's task? boundary
- Before issuing a mutating command, what evidence establishes its overwrite, append or deletion effect and whether that effect is permitted? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Check these first
Recalled without web access and unsourced; every item is a lead to verify.
- This describes the network protocol, not a discipline or field of knowledge.
- The listed kinds overlap: connection mode, authentication policy, and TLS protection are independent distinctions.
- Standards and identifiers are recalled without source inspection; implementation support and deployment prevalence require verification.
- Which of these check these first hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Kinds and varieties
Recalled without web access and unsourced; every item is a lead to verify.
- Active-mode FTP
- Passive-mode FTP
- Anonymous FTP
- Authenticated FTP
- FTP secured with TLS (FTPS)
- Which of these kinds and varieties hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Identifiers and schemes
Recalled without web access and unsourced; every item is a lead to verify.
- IANA service names and port numbers - ftp: TCP 21; ftp-data: TCP 20 - Port 21 is the conventional control port; port 20 is the conventional server-side source port for active-mode data connections, not a universal data-transfer port.
- URI scheme - ftp - Identifies FTP resources.
- FTP reply codes - Three decimal digits, with the first digit from 1 through 5 - The first digit distinguishes preliminary, completion, intermediate, transient failure, and permanent failure replies.
- Which of these identifiers and schemes hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Standards and regulation
Recalled without web access and unsourced; every item is a lead to verify.
- RFC 959, File Transfer Protocol (FTP), published in the Internet RFC series and designated Internet Standard STD 9.
- IETF RFC 2428, FTP Extensions for IPv6 and NATs, specifies EPRT and EPSV.
- IETF RFC 3659, Extensions to FTP, specifies additional capabilities including machine-readable directory listings.
- IETF RFC 4217, Securing FTP with TLS, specifies TLS protection for FTP.
- IETF RFC 2577, FTP Security Considerations, documents security concerns.
- Which of these standards and regulation hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Real-world use
Recalled without web access and unsourced; every item is a lead to verify.
- Uploading and downloading files on managed servers.
- Distributing files through anonymous public archives.
- Moving files in scheduled enterprise data-exchange workflows.
- Transferring files to and from equipment with embedded FTP clients or servers.
- Which of these real-world use hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Typical measurements
Recalled without web access and unsourced; every item is a lead to verify.
- File-transfer throughput - No protocol-defined typical range; depends on network capacity, latency, storage, and implementation. - bytes per second
- Which of these typical measurements hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Failure modes and hazards
Recalled without web access and unsourced; every item is a lead to verify.
- Unprotected FTP exposes passwords, commands, and transferred contents to interception or modification.
- Separate data connections can fail because of firewalls, NAT configuration, or incorrectly advertised passive-mode addresses.
- Overly permissive anonymous access or server permissions can expose files or permit unauthorized uploads.
- Interrupted transfers can leave partial files; restart support and safe publication of completed files depend on implementation and workflow.
- ASCII transfer mode can alter binary files through text representation conversion.
- Which of these failure modes and hazards hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Recalled without web access and unsourced; every item is a lead to verify.
- FTPS - FTPS applies TLS security to FTP while retaining its control and data connection architecture.
- SSH File Transfer Protocol (SFTP) - SFTP is a distinct file-access and transfer protocol normally carried over SSH; it does not use FTP commands or connection architecture.
- Trivial File Transfer Protocol (TFTP) - TFTP is a simpler, separate protocol using UDP and lacks FTP's authenticated control session.
- Hypertext Transfer Protocol (HTTP) - HTTP transfers resource representations through request-response exchanges and does not use FTP's separate control and data connections.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of File Transfer Protocol this model covers, and on what evidence? provenance
What the second pass must settle
- Does the existing Vercy catalogue already contain an authoritative FTP model that this registry entry should reference?
- Which FTP specifications and extension documents should define the model's supported conformance profiles?
- Should legacy transfer modes, record structures and third-party server-to-server transfers be represented in the core model or optional layers?
- Which implementation-specific pathname, listing, timestamp and restart behaviours require explicit interoperability profiles?
- What deployment policy should govern anonymous access, unprotected sessions, TLS requirements and acceptable transfer-verification evidence?