idnits 2.17.1 draft-yevstifeyev-ftp-uri-scheme-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC959, updated by this document, for RFC5378 checks: 1985-10-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 25, 2011) is 4597 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- No information found for draft-ietf-ftpext2-hosts - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D ietf-ftpext2-hosts' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 354 (Obsoleted by RFC 542) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2368 (Obsoleted by RFC 6068) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Yevstifeyev 3 Intended Status: Standards Track September 25, 2011 4 Updates: 959, 1738, 4002 (if approved) 5 Expires: March 28, 2012 7 The 'ftp' URI Scheme 8 draft-yevstifeyev-ftp-uri-scheme-08 10 Abstract 12 This document specifies the 'ftp' Uniform Resource Identifier (URI) 13 scheme, which is used to refer to resources accessible via File 14 Transfer Protocol (FTP). It updates RFC 959, RFC 1738 and RFC 4002. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and Conventions . . . . . . . . . . . . . . . . . . 3 56 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 3 57 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Interpreting Examples . . . . . . . . . . . . . . . . . . . 4 60 2.5. Miscellaneous Conventions . . . . . . . . . . . . . . . . . 4 61 3. URI Scheme Specification . . . . . . . . . . . . . . . . . . . 5 62 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 6 64 3.2.1. The and Parts . . . . . . . . . . . . . . 7 65 3.2.2. The Part . . . . . . . . . . . . . . . . . . 7 66 3.2.3. The Part . . . . . . . . . . . . . . . . . . 9 67 3.2.3.1. The Part . . . . . . . . . . . . . 10 68 3.2.4. Queries and Fragment Identifiers . . . . . . . . . . . 11 69 3.2.4.1. Queries . . . . . . . . . . . . . . . . . . . . . . 11 70 3.2.4.2. Fragment Identifiers . . . . . . . . . . . . . . . 11 71 3.3. Encoding Considerations . . . . . . . . . . . . . . . . . . 12 72 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Examples of 'ftp' IRIs and Internationalized URIs . . . . . 16 74 5. Security and Privacy Considerations . . . . . . . . . . . . . . 17 75 6. Internationalization Considerations . . . . . . . . . . . . . . 18 76 6.1. UCS Characters in 'ftp' URIs . . . . . . . . . . . . . . . 18 77 6.2. 'ftp' IRIs . . . . . . . . . . . . . . . . . . . . . . . . 18 78 6.3. Handling 'ftp' URIs with UCS Characters and 'ftp' IRIs . . 19 79 6.3.1. Internationalized Part in 'ftp' URIs and 80 Part in 'ftp' IRIs . . . . . . . . . . . . . . 19 81 6.3.2. Internationalized Part in 'ftp' URIs and 82 in 'ftp' IRIs . . . . . . . . . . . . . . . 19 83 6.4. Internationalization of Actual Data Interchange . . . . . . 20 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 85 7.1. The 'ftp' URI Scheme . . . . . . . . . . . . . . . . . . . 20 86 7.2. The 'ftps' URI Scheme . . . . . . . . . . . . . . . . . . . 20 87 7.3. Maintaining ftp.uri.arpa Domain . . . . . . . . . . . . . . 21 88 7.4. 'd' FTP TYPE Parameter . . . . . . . . . . . . . . . . . . 21 89 7.5. Changes to 'fp:ftp' Enumservice Registration Template . . . 21 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 93 Appendix A. 'ftp' URIs and Other Protocols . . . . . . . . . . . . 26 94 A.1. Dynamic Delegation Discovery System (DDDS) and 'ftp' URIs . 26 95 A.2. ENUM and 'ftp' URIs . . . . . . . . . . . . . . . . . . . . 27 96 Appendix B. Previous Syntax Definitions . . . . . . . . . . . . . 27 97 B.1. RFC 1630 . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 B.2. RFC 1738 . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 Appendix C. List of Changes since RFC 1738 . . . . . . . . . . . . 30 100 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 101 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 103 1. Introduction 105 File Transfer Protocol (FTP) is a standard network protocol used to 106 copy a file from one host to another over a TCP-based network. It 107 has had a very long history; the protocol is rooted in the early 108 1970s, the times of ARPANET, with the first specification being RFC 109 354 [RFC0354]; the most current FTP specification is RFC 959 110 [RFC0959]. RFC 1123 [RFC1123] made a number of changes to FTP 111 specification. 113 The 'ftp' Uniform Resource Identifier (URI) scheme, used for 114 referencing resources accessible via FTP, has been deployed. It was 115 first mentioned in RFC 1630 [RFC1630] - pre-Standard Track RFC on 116 URIs. Later, RFC 1738 [RFC1738], Section 3.2 specified this scheme, 117 as well as many others, on IETF Standards Track. This document 118 extracts the definition of the 'ftp' URI scheme from this document to 119 retain it on Standard Track if and when RFC 1738 is moved to Historic 120 status [RFC2026][HISTORIC] as well as makes several changes to suit 121 current scheme usage. (With the first respect it belongs to a series 122 of similar documents like RFC 2368 [RFC2368], which is now obsoleted 123 by RFC 6068 [RFC6068], RFC 4248 [RFC4248], RFC 4266 [RFC4266], and 124 RFC 5538 [RFC5538]; RFC 4156 [RFC4156] and RFC 4157 [RFC4157] also 125 extracted definition of 'wais' and 'prospero' schemes from RFC 1738 126 but have no relation to Standards Track, since the aforementioned 127 schemes are historical.) It updates RFC 959, RFC 1738 and RFC 4002 128 (for motivation of the latter, see Appendix A.2). 130 Generic URI syntax is described in RFC 3986 [RFC3986]; registration 131 procedures for new URI schemes - in RFC 4395 [RFC4395]. 133 2. Terminology and Conventions 135 2.1. Conformance Criteria 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in RFC 140 2119 [RFC2119]. 142 2.2. Terminology 144 In this document, the terms "client" and "server" are used in the 145 meaning of "user-FTP process" and "server-FTP process", respectively, 146 which are defined in Section 2.2 of RFC 959 [RFC0959]. The terms 147 "FTP command" (referred to as "command" within this document), "user- 148 PI", "server-PI", "user-DTP", "server-DTP", "control connection", 149 "data connection", "reply" and "user" are used with the meaning 150 defined in the same document. Sections 3.3 and 6 make use of terms 151 described in RFC 6365 [RFC6365]. Terms related to DDDS used in 152 Appendix A, especially those which occur capitalized, are described 153 in RFC 3402 [RFC3402]. IDNA-related terminology is derived from RFC 154 5890 [RFC5890]. 156 In this document "ASCII" refers to the American Standard Code for 157 Information Interchange, character set defined in ANSI Standard X3.4 158 [ASCII]; definition of Net-ASCII found in Appendix B of RFC 5198 159 [RFC5198] may be considered to be equivalent. 161 In this document "EBCIDIC" refers to the Extended Binary Coded 162 Decimal Interchange Code, a proprietary character set of IBM 163 Corporation defined at 164 and 165 doubled in RFC 183 [RFC0183]. 167 2.3. Formal Syntax 169 This document uses the Augmented Backus-Naur Form (ABNF) [RFC5234] 170 for description of formal syntax. The , , , 171 , and rules are imported from RFC 3986 172 [RFC3986] and rule - from RFC 5234 [RFC5234]. 174 2.4. Interpreting Examples 176 In the examples of FTP dialogs presented in this document, lines that 177 begin "C> " were sent over the control connection from the user-PI to 178 the server-PI, and lines that begin "S> " were sent over the control 179 connection from the server-PI to the user-PI. In all cases, the 180 prefixes shown above, including the one space, have been added for 181 the purposes of this document, and are not a part of the data 182 exchanged between client and server. Within such dialogs text 183 enclosed in angle brackets ("<" and ">", ASCII characters 0x3C and 184 0x3E, respectively), unless clearly mentioned in such dialog, is not 185 an actual part of FTP exchange but rather describes actions taken by 186 parties of exchange or provides general comment. 188 2.5. Miscellaneous Conventions 190 The construction "ASCII character 0xHH", where "HH" represents 2 191 hexadecimal digits, is equivalent to RFC 20 [RFC0020] construction 192 "ASCII X'HH'" and denotes ASCII character which has been assigned the 193 ASCII code HH. For example, ASCII character 0x5E refers to the "^" 194 (caret) and ASCII character 0x7B refers to "{" (left curly bracket). 196 The constructions described in Sections 3 and 4 of RFC 5137 [RFC5137] 197 are used in this document to point and escape Unicode characters, 198 respectively. 200 3. URI Scheme Specification 202 3.1. URI Scheme Syntax 204 The syntax of 'ftp' URI is described in rule below. 206 ftp-uri = "ftp:" ftp-hier-part 207 ftp-hier-part = "//" [ userinfo "@" ] host [ ":" port ] 208 [ ftp-path ] 210 userinfo = user [ ":" pass ] 211 user = 1*usp-char 212 pass = *usp-char 213 usp-char = unreserved / pct-encoded / sub-delims 215 ftp-path = [ cwd-part ] "/" last-segment [ typecode-part ] 216 cwd-part = *( "/" cwd ) 217 cwd = segment-nsc 218 last-segment = segment-nsc 219 segment-nsc = *pchar-nsc 220 pchar-nsc = unreserved / pct-encoded / sub-delims-nsc / ":" 221 / "@" 222 sub-delims-nsc = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / 223 / "," / "=" 224 ; RFC 3986 excluding semicolon (";") 225 ; character (ASCII character 0x3B) 226 typecode-part = ";type=" typecode 227 typecode = "a" / "e" / "i" / "u" / "d" / typecode-ext 228 typecode-ext = ALPHA 230 RFC 3986 deprecated the use of "user:pass" format of the 231 part of URIs. However, for some historical reasons, the benefits of 232 the use of such construction for denoting the user information in the 233 'ftp' URIs are valuable enough to overlook this issue; see Section 234 3.2.2 of this document. 236 When is present, it should be noted that is 237 always present, too; it may be null, though. For instance, the URIs 238 and have null s while has the 240 equal to "big.xls". 242 At strict syntactical level, may be defined as follows: 244 ftp-path =/ *( "/" cwd ) [ typecode-part ] 246 However, for the purpose of better understanding the algorithm of its 247 handling given in Section 3.2.3, the definition found in the 248 beginning of this section is used. 250 Please note that while processing the 'ftp' URI those characters 251 which appear percent-encoded, MUST be decoded for the purpose of 252 handling the URI, including the actual FTP exchange; see Section 3.3 253 for more information. 255 The semantics of each part are defined in Section 3.2. 257 3.2. URI Scheme Semantics 259 The 'ftp' URI specifies a resource (a file or a directory listing) on 260 the definite FTP server. 262 The application resolving the 'ftp' URI SHALL use the following 263 algorithm: 265 (1) establish the Transmission Control Protocol (TCP) [RFC0793] 266 connection to the server identified by the on the port 267 identified by the (or 21, if not supplied in the 'ftp' 268 URI); 270 (2) perform an attempt to identify the host it is trying to access 271 using the HOST command [I-D ietf-ftpext2-hosts], as described in 272 Section 3.2.1; 274 (3) authenticate itself to the server; 276 (4) request a list of supported features from server using FEAT 277 command [RFC2389]; if feature negotiation mechanism is not 278 supported by the server, act if the FEAT command has not been 279 sent (this step is RECOMMENDED but not required); and 281 (5) perform a series of commands according to part. 283 Please note that the client MAY also perform other steps during this 284 algorithm, such as requesting the server information using SYST 285 command [RFC0959] or select a language of interchange using LANG 286 command [RFC2640]. However, performing the steps of this algorithm 287 is REQUIRED, modulo step 4, which is RECOMMENDED. 289 Handling error replies received during processing the URI, unless 290 clearly stated in this document, is implementation-specific. 292 Since 'ftp' URI does not denote the transmission mode which is to be 293 used, the stream mode, which is described in Section 3.4.1 of RFC 959 294 [RFC0959], MUST always be used. 296 'ftp' URIs cannot be used for other operations, such as uploading or 297 removing a file on a server. 299 Note: The 'ftp' URI scheme supports FTP over TCP only; such 300 derivations as FTP over User Datagram Protocol (UDP) [RFC0768] or 301 Stream Control Transmission Protocol (SCTP) [RFC4960], as known to 302 be deployed, are not supported by it. 304 Note: The 'ftp' and the 'file' URI are not the same, even though 305 they both may refer to the resource on the local host. 307 More detailed description of each URI's parts' semantics is below. 309 3.2.1. The and Parts 311 The part, which is required, specifies the server which a 312 connection is to be established to. The part, which is 313 optional, denotes the TCP port for establishing such connection. 315 If the part with the preceding colon (":") character (ASCII 316 character 0x3A) is omitted, the port SHALL default to 21, as 317 registered in [IANA-PORTREG]. 319 Upon establishing a successful TCP connection, the client MUST first 320 try to identify the host it is trying to access using the HOST 321 command [I-D ietf-ftpext2-hosts]. It is performed by sending this 322 command with the part of the URI as an argument. 324 If either 500 or 502 reply is received in response (which identify 325 that the HOST command is unrecognized or unimplemented, 326 respectively), the client SHALL act as if a HOST command had not been 327 sent and continue processing the URI. If either 501 or 504 reply is 328 received (which identify that the supplied hostname is syntactically 329 invalid or it is unavailable, respectively), the client's behavior 330 depends on how does the server react. If, in accordance with Section 331 3.3 of RFC nnnn [I-D ietf-ftpext2-hosts], the server chooses to 332 terminate the connection, the client SHALL notify the user and take 333 no further actions. Otherwise, if the server does not terminate the 334 connection, the client SHALL act as if a HOST command had not been 335 sent and continue processing the URI. 337 3.2.2. The Part 338 The part, which is optional, consists of the and 339 the parts. The part, which is required within 340 , denotes the user name; the part, which is optional 341 within , - the password. The user name and the password 342 are delimited by the colon (":") character (ASCII character 0x3A). 344 There are three cases of handling the part. The first 345 implies that the 'ftp' URI provides entire user credentials (a user 346 name and a password). In this case, upon establishing successful TCP 347 connection to the server specified in the URI the client SHALL use 348 supplied user name with the USER command; if the server requests the 349 password via sending the 331 reply, one supplied in the URI MUST 350 first be used. 352 The second case covers the situation when the only user name is 353 supplied. Under such circumstances, the client SHALL first use it in 354 the USER command; if the server requests the password via sending the 355 331 reply, the client MUST either find applicable password to use in 356 USER command (e.g. request one from the user) or fail by terminating 357 the connection with QUIT command. 359 The third case is when the whole part is omitted in the 360 URI. In this case upon establishing the connection the "anonymous 361 FTP" [RFC1635] SHALL first be used; it implies use of the following 362 credentials: 364 (1) the user name "anonymous", and 366 (2) the password "guest" or that which is an email address [RFC5322]. 368 Note: Current FTP implementations mostly pay no attention to the 369 password supplied with the "anonymous" user name. Thus clients 370 SHOULD NOT supply real email addresses, due to the security 371 reasons, but SHOULD rather supply either randomly-generated or non- 372 existing email addresses under such circumstances. See also 373 Section 5. (For instance, Mozilla Firefox sends the email address 374 "mozilla@example.com" under such circumstances.) 376 However, the authentication which implies use of part of 377 the URI might be unsuccessful (ie. the server might fail to 378 authenticate the user), which is indicated by receiving the 530 reply 379 in response to either USER or PASS command. In this case, the client 380 MUST either find applicable credentials to authenticate itself or 381 fail by terminating the connection with QUIT command. If the former 382 if chosen, and the server does not accept the credentials, the loop 383 is repeated. 385 The 'ftp' URI does not provide a way to denote account information, 386 used with ACCT command. Thus, if the server requests it for 387 authentication (via sending 332 reply to a successful PASS command) 388 or it is required for performing other command (which is denoted by 389 either 332 or 532 server reply received upon sending such command), 390 handling of a URI SHALL be suspended, and the client MUST either find 391 applicable account information to use with ACCT command or fail by 392 terminating the connection with QUIT command. If the former if 393 chosen, and the server does not accept the supplied token, the loop 394 is repeated. 396 The part is not intended to define information which 397 should be used if the authentication is performed using the AUTH 398 command or other mechanism spelled out in RFC 2228 [RFC2228]; see 399 Section 5 of this document. 401 3.2.3. The Part 403 The part, which is optional, denotes the resource (a file 404 or a directory listing) on the server specified by . For 405 better understanding the algorithm below, the ABNF definition of 406 is copied here: 408 ftp-path = [ cwd-part ] "/" last-segment [ typecode-part ] 409 cwd-part = *( "/" cwd ) 410 cwd = segment-nsc 411 last-segment = segment-nsc 412 segment-nsc = 413 typecode-part = ";type=" typecode 414 typecode = "a" / "e" / "i" / "u" / "d" / typecode-ext 415 typecode-ext = ALPHA 417 Please note that when is omitted, for the purpose of 418 processing the URI it MUST be considered to be "/" and SHOULD be 419 changed to "/" when normalizing the URI. 421 The part SHALL be processed using the following algorithm: 423 (1) if the is present, each of parts are 424 consistently supplied as arguments to the CWD (change working 425 directory) FTP command; 427 Note: Any null parts, allowed per aforementioned syntax, 428 MUST NOT cause sending CWD commands, since they might be 429 erroneously interpreted by some FTP servers. 431 (2) if the is present and is either "a", 432 "e", "i" or "u", perform the TYPE command with the as 433 an argument; 435 (3) whatever the path is, arrange the data connection to the server 436 using an appropriate method, as per those facilities of server 437 discovered with FEAT command [RFC2389] (eg. PORT, PASV 438 [RFC0959], EPRT or EPSV [RFC2428] command; using LPRT and LPSV 439 [RFC1639] commands, which were designated as historical by RFC 440 5797 [RFC5797], is strongly discouraged); 442 (4a) if is null (whatever is), retrieve the 443 listing of current directory using appropriate method, as per 444 those facilities of server discovered with FEAT command 445 [RFC2389] (eg. LIST, NLST [RFC0959] or MLSD [RFC3659] command); 447 Note: If and are omitted and is null, refers to the default directory on the 449 for the logged user; in this case directory listings are to 450 be retrieved directly after establishing data connection, skipping 451 steps (1) and (2) above. 453 (4b) if the is present and the is equal to 454 "d", specifies the directory; in this case 455 retrieve listing of the directory specified by 456 (or the current directory, if is null) using the 457 appropriate method (see above); 459 (4c) in the case described in (2) refers to a file; 460 retrieve this file using appropriate method (using RETR command 461 is RECOMMENDED); 463 (4d) otherwise, may refer either to a file or a 464 directory listing; perform both subsequent attempts to access 465 the file and a directory listing; order of such attempts is non- 466 substantial. 468 Note: Some client may involve additional heuristic algorithms to 469 determine what does the refer to, such as checking 470 its format to see whether is matches the "." 471 format. This document allows them to do in such way. 473 Please note that the client MAY also perform other steps during this 474 algorithm, such as retrieving file size using SIZE command or 475 modification time using MSTM command [RFC3659]. However, performing 476 the steps of this algorithm is REQUIRED. 478 Handling error replies caused by processing the is 479 implementation-specific. 481 3.2.3.1. The Part 482 The part specifies the data type of 483 and the parameter of FTP TYPE command to be applied to such data. 484 Refer to Section 1.3 of [I-D ietf-ftpext2-typeu] for discussion of 485 TYPE history. 487 Currently, there are five options of : "a", "e", "i", which 488 are specified in RFC 959 and stand for ASCII, EBCDIC text, "raw" 489 (binary) data, "u", which is specified in RFC mmmm [I-D ietf-ftpext2- 490 typeu] and stands for Net-Unicode [RFC5198] text, and "d", which is 491 not an actual typecode but rather a "pseudo-typecode" to identify 492 that the is a directory. (The 'd' TYPE parameter is 493 hereby reserved; see Section 7.4.) 495 The production provides a possibility to accommodate 496 new typecodes in the 'ftp' URI. Therefore, when a new FTP data type 497 is defined, its specification MUST define its relationship with the 498 'ftp' URI. When the refers to the type code which is not 499 yet defined, the client SHOULD ignore it. (For instance, the 'xtp' 500 FTP TYPE parameter was eventually proposed [RFC0683] during early 501 stages of FTP development. Currently, hardly somebody knows about 502 the existence of this data type parameter; also, it is not a valid 503 and the URI like is to be 504 treated as .) 506 3.2.4. Queries and Fragment Identifiers 508 3.2.4.1. Queries 510 This document does not specify the query component to be used in 511 'ftp' URIs. Clients SHOULD ignore it, if present. Correspondingly, 512 any question mark ("?") characters (ASCII character 0x3F), as they 513 are not allowed within URIs for any reason other that denoting the 514 query component by RFC 3986, MUST be percent-encoded within 'ftp' 515 URIs. 517 3.2.4.2. Fragment Identifiers 519 According to RFC 3986, the specification of a definite URI scheme 520 must not define the fragment identifiers in the corresponding scheme 521 syntax, as they depend on the media type of a resource identified by 522 such URI. Correspondingly, fragment identifier are allowed in any 523 URI. 525 The number sign ("#") characters (ASCII character 0x23), if used for 526 the reason other than to delimit the fragment identifier SHALL be 527 percent-encoded. 529 If present in 'ftp' URI, fragment identifier is put after the (and , if present), forming an URI like 531 . Handling the fragment 532 identifier is solely up to the client. 534 See Section 4 for an example of an URI with fragment identifier. 536 3.3. Encoding Considerations 538 The parts of 'ftp' URIs may contain characters from ASCII character 539 set which are allowed in the corresponding parts. Those characters 540 which are excluded from the allowed characters for a particular part 541 SHALL be encoded within this part. 543 'ftp' URIs MAY contain characters from Universal Character Set (UCS) 544 [UCS] in and part, as discussed in Section 6. 545 Further internationalization of 'ftp' URIs is discussed ibidem. 547 As mentioned before, the characters in ASCII range which appear 548 percent-encoded in the URI, MUST be decoded in the actual FTP 549 exchange. This means that when sending data over FTP control 550 connection per Section 3.2 of this document percent-encoded 551 characters SHALL be replaced with their ASCII equivalents. However, 552 those percent-encoded octets which are outside of ASCII range SHALL 553 be transmitted as the corresponding octets. For instance, "%2F", if 554 occurs in the , will be replaced with "/", ASCII character 0x2F, 555 and "%E7", if occurs ibidem, will be transmitted as octet when 556 sending as an argument to CWD command. 558 4. Examples 560 This section provides several examples of 'ftp' URIs and their valid 561 handling per this document. Within it, DNS names reserved by RFC 562 2606 [RFC2606] and IPv4 addresses reserved by RFC 5737 [RFC5737] are 563 used. 565 The URI 567 569 may result in the following data exchange: 571 572 S> 220 ExampleFTP Server ready 573 C> HOST example.com 574 S> 220 Host accepted 575 C> USER anonymous 576 S> 331 Anonymous permitted; supply email as password 577 C> PASS bad-guy@example.com 578 S> 230 Logged in 579 C> CWD /somedir 580 S> 250 Directory changed 581 C> PASV 582 S> 227 Entering Passive Mode (192,0,2,12,52,453) 583 C> NLST seconddir 584 S> 150 Here comes the directory listing 585 587 S> 226 Directory listing sent 589 The URI 591 593 may result in the following data exchange: 595 596 S> 220 CoolFTP Server Ready 597 C> HOST 203.0.113.42 598 S> 220 Host OK 599 C> USER fellow 600 S> 331 Specify password 601 C> PASS bad-guy 602 S> 230 Congrats! Logged in 603 C> CWD /etc 604 S> 250 Directory changed 605 C> PASV 606 S> 227 Passive entered (203,0,113,42,61,853) 607 is a directory to the client's mind> 608 C> LIST motd 609 S> 550 No such directory 610 refers to a file> 611 C> RETR motd 612 S> 150 Transfer starts... 613 614 S> 226 File is sent 615 617 Such URI is different from one with equal to "/etc/motd" 618 or "//etc/motd", since both such URI will result in sending "CWD etc" 619 instead of . 621 The following example illustrates the situation when supplied 622 credentials are invalid. Thus, the URI 624 626 may result in the following: 628 629 S> 220 GigaSoft FTP - welcome 630 C> HOST example.net 631 S> 220 Why not :-) 632 C> USER user1 633 S> 331 Mention password 634 C> PASS invalid-pass 635 S> 530 Invalid credentials 636 637 639 C> USER right-user 640 S> 331 Mention password 641 C> PASS right-pass 642 S> 230 right-user is a cool guy 643 C> FEAT 644 S> 211-Here the listing comes 645 S> AUTH TLS 646 S> TYPE a;u 647 S> MLST 648 S> 211 End 649 C> PASV 650 S> 227 Passive opened on (198,51,100,41,55,623) 651 C> MLSD 652 S> 150 Here comes the directory listing 653 655 S> 226 Directory listing sent 657 The following URI contains percent-encoded "?" and "#" characters and 658 fragment identifier to illustrate their valid handling. The URI: 660 662 may result in the following data exchange: 664 665 S> 220 Hello 666 C> HOST example.org 667 S> 220 OK 668 C> USER anonymous 669 S> 230 No pass required 670 C> CWD ?foo 671 S> 250 Directory changed 672 C> CWD #bar 673 S> 250 Directory changed 674 C> TYPE a 675 S> 200 Accepted 676 C> PORT 198,51,100,2,65,123 677 S> 200 Accepted 678 refers to a file to the client's mind> 679 C> RETR file.txt 680 S> 150 Start transmission 681 683 S> 226 File sent 684 685 688 The last example illustrates the complicated URI where a number of 689 issues should be considered. Such issues include the server refusing 690 to accept host name with HOST command, invalid user credentials, 691 inability to support the "u" TYPE parameter and the absence of "bad- 692 file.doc". The URI: 694 696 may result in the following data interchange: 698 699 S> 220 Yevstifeyev FTP ready 700 C> HOST example.org 701 S> 504 Unknown host 702 703 C> USER oh-no 704 S> 331 Supply password 705 706 707 C> PASS some-pass 708 S> 530 Invalid credentials 709 710 712 C> USER cool-man 713 S> 331 Supply password 714 C> PASS cool-pass 715 S> 230 Authenticated 716 C> CWD foo 717 S> 250 foo is an active directory 718 C> CWD bar 719 S> 250 foo/bar is an active directory 720 C> CWD foobar 721 S> 250 foo/bar/foobar is an active directory 722 C> TYPE u 723 S> 504 U TYPE not supported 724 C> PORT 192,0,2,14,64,695 725 S> 200 Accepted 726 C> RETR bad-file.doc 727 S> 550 No such file :-( 728 730 4.1. Examples of 'ftp' IRIs and Internationalized URIs 732 This section provides several examples of handling 'ftp' IRIs and 733 internationalized URIs, as defined in Section 6. 735 The IRI, which contains U+2603 SNOWMAN character in the as 736 one of s and U+0109 LATIN SMALL LETTER C WITH CIRCUMFLEX 737 character in the , 739 741 may result in the following data exchange: 743 744 in the IRI> 745 S> 200 Hi, man! 746 C> HOST xn--at-0la.example.com 747 S> 220 That's OK. 748 C> USER anonymous 749 S> 331 Supply password 750 C> PASS foo@example.org 751 S> 230 Logged in 752 C> FEAT 753 S> 211-Features listing goes now 754 S> MLST 755 S> UTF8 756 S> NAT6 757 S> 211 End 758 C> CWD weather 759 S> 250 Working directory changed 760 C> CWD {e2.98.83} 761 763 S> 250 Working directory changed 764 C> PORT 198,51,100,20,49,562 765 S> 200 Data connection aranged 766 C> RETR snow.txt 767 S> 150 Start transmission 768 769 S> 226 File sent 771 The following example illustrates 'ftp' URI with UCS characters, 772 explicitly, the U+0125 LATIN SMALL LETTER H WITH CIURCUMFLEX in the 773 and U+1D120 MUSICAL SYMBOL G CLEF OTTAVA BASSA in one of 774 s. The URI: 776 778 779 in 780 the URI, which contains UCS character> 781 S> 200 Welcome 782 C> HOST xn--ost-4sa.example.com 783 S> 220 Accepted 784 C> USER anonymous 785 S> 230 No pass required 786 C> FEAT 787 S> 211-Listing comes here 788 S> LANG EN* 789 S> TYPE a;e;u 790 S> UTF8 791 S> REST STREAM 792 S> MLST 793 S> 211 End 794 C> CWD music 795 S> 250 Directory changed 796 C> {f0.9d.84.a0} 797 799 S> 250 Directory changed 800 C> PASV 801 S> 227 Entering passive (203,0,113,16,52,458) 802 C> RETR clef.pdf 803 S> 150 Start transmission 804 805 S> 226 File sent 807 5. Security and Privacy Considerations 809 Generic security considerations for URIs are discussed in Section 7 810 of RFC 3986 [RFC3986]; for IRIs - in Section 8 of RFC 3987 [RFC3987]. 812 Security considerations for FTP are addressed in RFC 2577 [RFC2577]. 813 RFC 2228 [RFC2228] and RFC 4217 [RFC4217] provided several ways for 814 securing FTP. However, the 'ftp' URI does not allow to denote 815 whether any of these ways should be used. The 'ftps' URI scheme, 816 which denotes the resource available via FTP secured as defined in 817 RFC 4217, is known to be deployed; this document provisionally 818 registers this scheme with IANA (see Section 6.2), but specifying it 819 is out of the scope of this document. 821 Because of some security concerns RFC 3986 did deprecate the use of 822 "user:pass" format of , as stated in Section 3.1; it only 823 applies to 'ftp' URIs because of historical reasons. Obviously, 824 those URIs which contain the password "in the clear" should be kept 825 and transmitted securely (for example, using Transport Layer Security 826 (TLS) [RFC5246]). 828 The "anonymous FTP" [RFC1635] has a number of security implications, 829 too. When transmitting the email address as a password, if it is 830 required by the server, there is a risk of email address harvesting 831 by intermediary systems, a.k.a. "middle-boxes" (man-in-the-middle 832 attacks) and the ultimate server. As servers usually do not pay 833 attention to such passwords, clients are encouraged to transmit email 834 addresses which are either randomly-generated or non-existing, as 835 doubled in Section 3.2.2. 837 Security considerations for usage of Internationalized Domain Names 838 are discussed in RFC 5890 [RFC5890]. 840 6. Internationalization Considerations 842 This document discusses internationalization of 'ftp' URIs, as 843 required by RFC 2277 [RFC2277]. 845 6.1. UCS Characters in 'ftp' URIs 847 As allowed by Section 2.5 of RFC 3986, 'ftp' URIs may contain the 848 characters from Universal Character Set (UCS) [UCS]. They are only 849 allowed in and part; is not 850 internationalized. 852 In order to use such character in one of these parts, it SHALL first 853 be encoded with UTF-8 [RFC3629]. The resulting sequence of octets 854 SHALL be examined to conclude whether some octets match corresponding 855 ASCII characters. If one does, and such character is allowed in a 856 particular part of 'ftp' URI, it SHALL be presented in the URI 857 directly; otherwise, the octet SHALL be represented percent-encoded. 858 (In fact, such situation will only arise when the analyzed character 859 is ASCII character itself, as UCS includes ASCII range.) 861 6.2. 'ftp' IRIs 863 IRIs, described in RFC 3987 [RFC3987], may contain UCS characters "in 864 the raw", unlike URIs, which only allow ones which are outside of 865 ASCII range percent-encoded (see Section 4.1 above). 866 Correspondingly, the syntax of 'ftp' IRIs will be different from 867 URIs' one. 869 The changes required in URI syntax to match valid IRI is to change 870 of RFC 3986 to of RFC 3987 and of RFC 871 3986 - to of RFC 3987 in . The 872 is not internationalized. 874 'ftp' IRIs are subject to the rules of Section 3.1 of RFC 3987 with 875 respect to their mapping to 'ftp' URIs. 877 6.3. Handling 'ftp' URIs with UCS Characters and 'ftp' IRIs 879 Handling of ftp' URIs with UCS characters and 'ftp' IRIs is mostly 880 the same as discussed in Section 3.2 of this document; however, a 881 number of issues should be considered. 883 6.3.1. Internationalized Part in 'ftp' URIs and Part in 884 'ftp' IRIs 886 The part in 'ftp' URIs and part in 'ftp' IRIs may 887 contain internationalized strings, with UCS characters being percent- 888 encoded and displayed directly, respectively. 890 As Domain Name System (DNS) does not allow the UTF-8 encoded data in 891 its interchange, limiting the allowed characters range to ASCII 892 [ASCII], the usual procedure of UTF-8 transformation is insufficient 893 here. Hence, in order to make up the valid domain name for lookup 894 and further processing the algorithm for IDN lookup defined in 895 Section 5 of RFC 5891 [RFC5891] SHALL be applied. 897 The received sequence of dot-separated A-labels SHALL also be used 898 with FTP HOST command [I-D ietf-ftpext2-hosts], sent when 899 establishing FTP connection per Section 3.2.1. 901 6.3.2. Internationalized Part in 'ftp' URIs and 902 in 'ftp' IRIs 904 The and parts allow to include UCS characters 905 in FTP pathnames present in URIs and IRIs, respectively. 907 In order to successfully process an internationalized FTP pathname, a 908 client prior to its processing SHALL examine the server's response to 909 the FEAT command [RFC2389], issued upon authentication per Section 910 3.2. If one of the lines of the response is "UTF8", the server 911 supports UTF-8 encoded pathnames [RFC2640]. Otherwise, if there is 912 no such line, or the server does not support the FEAT mechanism, the 913 contrary SHALL be assumed. 915 Should it be determined that server supports UTF-8 encoded pathnames, 916 the internationalized pathname parts SHALL be encoded with UTF-8 917 [RFC3629] and then transmitted as an arguments to the corresponding 918 FTP commands as UTF-8 octets stream. 920 6.4. Internationalization of Actual Data Interchange 922 'ftp' RIs may refer to the file which contains the internationalized 923 data. When transmitting such file over data connection, it should 924 be in Net-Unicode format [RFC5198]. In order to indicate this, the 925 equal to "u" [I-D ietf-ftpext2-typeu] SHALL be set in the 926 'ftp' URI or IRI. 928 7. IANA Considerations 930 7.1. The 'ftp' URI Scheme 932 IANA is asked to update the registration of the 'ftp' URI scheme in 933 the appropriate registry [IANA-URIREG] with the reference to this 934 document using the following template, per [RFC4395]: 936 URI scheme name: ftp 938 Status: Permanent 940 URI scheme syntax: see Section 3.1 of RFC xxxx 942 URI scheme semantics: see Section 3.2 of RFC xxxx 944 URI scheme encoding considerations: see Section 3.3 of RFC xxxx 946 Protocols that use the scheme: File Transfer Protocol (FTP) 947 [RFC0959] 949 Security considerations: see Section 6 of RFC xxxx 951 Contact: IESG 953 Author/Change controller: IETF 955 References: see Section 8 of RFC xxxx 957 [RFC Editor: Please replace xxxx with assigned RFC number] 959 7.2. The 'ftps' URI Scheme 961 IANA is requested to provisionally register the 'ftps' URI scheme per 962 RFC 4395 [RFC4395] with reference for this document. Specifying this 963 scheme is out of the scope of this document; therefore the 964 registration template is not supplied. As required by Section 4 of 965 RFC 4395, the change controller for the registration is IETF 966 ; contact party is IESG . 968 7.3. Maintaining ftp.uri.arpa Domain 970 As primarily requested by [MSG-REG] per RFC 3405 [RFC3405], IANA will 971 continue maintaining the ftp.uri.arpa domain for use of DDDS with 972 'ftp' URIs (see Appendix A.1). Moreover, IANA is requested to change 973 the existing substitution expression in the NAPTR record for this 974 domain as described in Appendix A. 976 7.4. 'd' FTP TYPE Parameter 978 IANA is asked to list the 'd' FTP TYPE parameter in the corresponding 979 sub-registry established by RFC oooo [I-D ietf-ftpext2-typeu] as 980 "Reserved for use in 'ftp' URIs" with reference to this document. 982 7.5. Changes to 'fp:ftp' Enumservice Registration Template 984 IANA is asked to make the following change to 'ft:ftp' Enumservice 985 registration template, found in RFC 6118 [RFC6118]: 987 988 989 RFC 4002 referenced as 990 specification of 'ftp' URI scheme. However, the current 991 scheme documentation may be found in 992 993 994 996 is to be added after "". 998 [RFC Editor: Please replace XXXX with assigned RFC number] 1000 8. References 1002 8.1. Normative References 1004 [ASCII] American National Standards Institute (ANSI), "Coded 1005 Character Set -- 7-bit American Standard Code for 1006 Information Interchange", ANSI X3.4-1986, December 1986. 1008 [I-D ietf-ftpext2-hosts] 1009 Hethmon, P., and R. McMurray, "File Transfer Protocol HOST 1010 Command for Virtual Hosts", Work in Progress (draft-ietf- 1011 ftpext2-hosts), February 2011. 1013 [I-D ietf-ftpext2-typeu] 1014 Klensin, J., "FTP TYPE Extension for Internationalized 1015 Text", Work in Progress (draft-ietf-ftpext2-typeu), June 1016 2011. 1018 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1019 RFC 793, September 1981. 1021 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 1022 9, RFC 959, October 1985. 1024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, March 1997. 1027 [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for 1028 the File Transfer Protocol", RFC 2389, August 1998. 1030 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1031 Part Four: The Uniform Resource Identifiers (URI)", 1032 RFC 3404, October 2002. 1034 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1035 10646", STD 63, RFC 3629, November 2003. 1037 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1038 Resource Identifier (URI): Generic Syntax", STD 66, 1039 RFC 3986, January 2005. 1041 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1042 Identifiers (IRIs)", RFC 3987, January 2005. 1044 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 1045 Syntax Specifications: ABNF", STD 68, RFC 5234, January 1046 2008. 1048 [RFC5891] Klensin, J., "Internationalized Domain Names in 1049 Applications (IDNA): Protocol", RFC 5891, August 2010. 1051 8.2. Informative References 1053 [IANA-PORTREG] 1054 Internet Assigned Numbers Authority (IANA), "Port 1055 Numbers", IANA Registry, . 1057 [IANA-URIREG] 1058 Internet Assigned Numbers Authority (IANA), "Uniform 1059 Resource Identifier (URI) Schemes", IANA Registry, 1060 . 1062 [HISTORIC] The IESG, "IESG Statement on Designating RFCs as 1063 Historic", IESG Statement, June 2011, 1064 . 1067 [MSG-REG] Cotton, M., "Registration of the 'ftp' URI scheme in 1068 uri.arpa under the key ftp.uri.arpa.", Mailing List 1069 Posting, January 2003, 1070 1073 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 1074 October 1969. 1076 [RFC0183] Winett, J., "EBCDIC Codes and Their Mapping to ASCII", 1077 RFC 183, July 1971. 1079 [RFC0354] Bhushan, A., "File Transfer Protocol", RFC 354, July 1972. 1081 [RFC0683] Clements, R., "FTPSRV - Tenex extension for paged files", 1082 RFC 683, April 1975. 1084 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1085 August 1980. 1087 [RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET 1088 TEXT MESSAGES", STD 11, RFC 822, August 1982. 1090 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1091 Application and Support", STD 3, RFC 1123, October 1989. 1093 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 1094 Unifying Syntax for the Expression of Names and Addresses 1095 of Objects on the Network as used in the World-Wide Web", 1096 RFC 1630, June 1994. 1098 [RFC1635] Deutsch, P., Emtage, A., and A. Marine, "How to Use 1099 Anonymous FTP", FYI 24, RFC 1635, May 1994. 1101 [RFC1639] Piscitello, D., "FTP Operation Over Big Address Records 1102 (FOOBAR)", RFC 1639, June 1994. 1104 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 1105 Resource Locators (URL)", RFC 1738, December 1994. 1107 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1108 3", BCP 9, RFC 2026, October 1996. 1110 [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", 1111 RFC 2228, October 1997. 1113 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 1114 Languages", BCP 18, RFC 2277, January 1998. 1116 [RFC2428] Allman, M., Ostermann, S., and C. Metz, "FTP Extensions 1117 for IPv6 and NATs", RFC 2428, September 1998. 1119 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 1120 URL scheme", RFC 2368, July 1998. 1122 [RFC2577] Allman, M. and S. Ostermann, "FTP Security 1123 Considerations", RFC 2577, May 1999. 1125 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 1126 Names", BCP 32, RFC 2606, June 1999. 1128 [RFC2640] Curtin, B., "Internationalization of the File Transfer 1129 Protocol", RFC 2640, July 1999. 1131 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1132 Requirements for the Address and Routing Parameter Area 1133 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 1135 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1136 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 1138 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1139 Part Two: The Algorithm", RFC 3402, October 2002. 1141 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1142 Part Three: The Domain Name System (DNS) Database", 1143 RFC 3403, October 2002. 1145 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1146 Part Five: URI.ARPA Assignment Procedures", BCP 65, 1147 RFC 3405, October 2002. 1149 [RFC3659] Hethmon, P., "Extensions to FTP", RFC 3659, March 2007. 1151 [RFC4002] Brandner, R., Conroy, L., and R. Stastny, "IANA 1152 Registration for Enumservice 'web' and 'ft'", RFC 4002, 1153 February 2005. 1155 [RFC4156] Hoffman, P., "The wais URI Scheme", RFC 4156, August 2005. 1157 [RFC4157] Hoffman, P., "The prospero URI Scheme", RFC 4157, August 1158 2005. 1160 [RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248, October 1161 2005. 1163 [RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266, November 1164 2005. 1166 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 1167 October 2005. 1169 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1170 Registration Procedures for New URI Schemes", BCP 35, 1171 RFC 4395, February 2006. 1173 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1174 RFC 4960, September 2007. 1176 [RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters", 1177 BCP 137, RFC 5137, February 2008. 1179 [RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the 1180 text/plain Media Type", RFC 5147, April 2008. 1182 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1183 Interchange", RFC 5198, March 2008. 1185 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1186 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1188 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1189 October 2008. 1191 [RFC5538] Ellermann, F., "The 'news' and 'nntp' URI Schemes", 1192 RFC 5538, April 2010. 1194 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1195 Reserved for Documentation", RFC 5737, January 2010. 1197 [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension 1198 Registry", RFC 5797, March 2010. 1200 [RFC5890] Klensin, J., "Internationalized Domain Names for 1201 Applications (IDNA): Definitions and Document Framework", 1202 RFC 5890, August 2010. 1204 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 1205 URI Scheme", RFC 6068, October 2010. 1207 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1208 Uniform Resource Identifiers (URI) Dynamic Delegation 1209 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1210 March 2011. 1212 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 1213 Registration of Enumservices: Guide, Template, and IANA 1214 Considerations", RFC 6117, March 2011. 1216 [RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA 1217 Registrations of Enumservices", RFC 6118, March 2011. 1219 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1220 Internationalization in the IETF", BCP 166, RFC 6365, 1221 September 2011. 1223 [UCS] International Organization for Standardization (ISO), 1224 "Information technology -- Universal Coded Character Set 1225 (UCS)", ISO/IEC 10646:2011, March 2011. 1227 Appendix A. 'ftp' URIs and Other Protocols 1229 This appendix discusses relationship of 'ftp' URIs with other 1230 protocols. 1232 A.1. Dynamic Delegation Discovery System (DDDS) and 'ftp' URIs 1234 Dynamic Delegation Discovery System (DDDS) is an abstract algorithm 1235 for applying dynamically retrieved string transformation rules to an 1236 application-unique string. The comprehensive DDDS specification 1237 consists of 5 documents, which are defined in RFC 3401 [RFC3401]. 1239 RFC 3404 [RFC3404] specified a DDDS Application for resolving URIs 1240 using DDDS Algorithm defined in RFC 3402 [RFC3402]. A corresponding 1241 second-level domain has been delegated in the "arpa" zone [RFC3172] - 1242 "uri.arpa" [RFC3405] - for use with this Application. RFC 3404 1243 specified that First Well Known Rule for the aforementioned DDDS 1244 Application is to append the URI scheme name to ".uri.arpa". 1245 According to the provisions of RFC 3405 [RFC3405], the 'ftp' URI 1246 scheme was previously approved for inclusion in this zone [MSG-REG] 1247 in order to allow its resolving using DDDS. Correspondingly, the 1248 following substitution expression was recorded in the NAPTR DNS 1249 resource record [RFC3403]: 1251 !^ftp://([^:/?#]*).*$!\1!i 1253 using the syntax defined in Section 3.2 of RFC 3402. However, taking 1254 the syntax specified in this document into account, IANA is asked to 1255 record the following new substitution expression in the NAPTR record 1256 for ftp.uri.arpa domain: 1258 !^ftp://([^@/?#]*@)?([^:/?#]*).*$!\2!i 1260 This substitution expression extracts the hostname from a given URI, 1261 skipping the , and forming the next Key. Refer to RFC 3404 1262 for detailed description of DDDS Application for resolving URIs and 1263 RFC 3402 for generic DDDS Algorithm. 1265 Please note that while there is a possibility to resolve 'ftp' URIs 1266 using DDDS, not every given 'ftp' URI may be resolved using this 1267 technique. A specific "hint" is required in order to denote this; 1268 for instance, "the URI refers to the 1269 very valuable information; it is mirrored at a number of servers 1270 which are to be discovered using DDDS". 1272 A.2. ENUM and 'ftp' URIs 1274 ENUM is a way of using DDDS to map E.164 numbers to URIs. It is 1275 defined in RFC 6116 [RFC6116]. ENUM uses the concept of 1276 "Enumservices", which provide possibility to map E.164 numbers to 1277 different URIs. Registration procedures for said Enumservices are 1278 specified in RFC 6117 [RFC6117]. One of the currently registered 1279 Enumservices is 'fp:ftp', which represents the possibility to map 1280 E.164 number to 'ftp' URI. It is defined in RFC 4002 [RFC4002], 1281 which was later updated by RFC 6118 [RFC6118]. 1283 RFC 4002 referred to RFC 1738 [RFC1738], that-current 'ftp' URI 1284 scheme specification. This document updates RFC 4002 in order to 1285 represent the new scheme specification; Section 7.5 asks IANA to make 1286 corresponding change to its registration template. 1288 Appendix B. Previous Syntax Definitions 1290 This appendix copies the definition of the syntax of 'ftp' URI from 1291 previous documents which specified it, which might be of some 1292 historical interest. Within this appendix, BNF refers to the 1293 convention described in Section 2 of RFC 822 [RFC0822]. 1295 B.1. RFC 1630 1297 RFC 1630 [RFC1630] defined the syntax of 'ftp' URI with the following 1298 conventions: 1300 This is a BNF-like description of the URI syntax. at the level at 1301 which specific schemes are not considered. 1303 A vertical line "|" indicates alternatives, and [brackets] indicate 1304 optional parts. Spaces are represented by the word "space", and 1305 the vertical line character by "vline". Single letters stand for 1306 single letters. All words of more than one letter below are 1307 entities described somewhere in this description. 1309 as follows: 1311 ftpaddress f t p : / / login / path [ ftptype ] 1313 login [ user [ : password ] @ ] hostport 1315 user alphanum2 [ user ] 1316 password alphanum2 [ password ] 1318 hostport host [ : port ] 1319 host hostname | hostnumber 1320 hostname ialpha [ . hostname ] 1321 hostnumber digits . digits . digits . digits 1323 path void | segment [ / path ] 1324 segment xpalphas 1325 void 1327 ftptype A formcode | E formcode | I | L digits 1328 formcode N | T | C 1330 alphanum2 alpha | digit | - | _ | . | + 1331 alpha a | b | c | d | e | f | g | h | i | j | k | 1332 l | m | n | o | p | q | r | s | t | u | v | 1333 w | x | y | z | A | B | C | D | E | F | G | 1334 H | I | J | K | L | M | N | O | P | Q | R | 1335 S | T | U | V | W | X | Y | Z 1336 digit 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 1337 ialpha alpha [ xalphas ] 1338 xalphas xalpha [ xalphas ] 1339 xalpha alpha | digit | safe | extra | escape 1340 safe $ | - | _ | @ | . | & | + | - 1341 extra ! | * | " | ' | ( | ) | , 1342 escape % hex hex 1343 hex digit | a | b | c | d | e | f | A | B | C | 1344 D | E | F 1345 digits digit [ digits ] 1347 B.2. RFC 1738 1348 RFC 1738, which was the first Standard Track specification for many 1349 URI schemes, defined the syntax of 'ftp' URIs with the following 1350 conventions: 1352 This is a BNF-like description of the Uniform Resource Locator 1353 syntax, using the conventions of RFC822, except that "|" is used to 1354 designate alternatives, and brackets [] are used around optional or 1355 repeated elements. Briefly, literals are quoted with "", optional 1356 elements are enclosed in [brackets], and elements may be preceded 1357 with * to designate n or more repetitions of the following 1358 element; n defaults to 0. 1360 as follows: 1362 ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]] 1364 login = [ user [ ":" password ] "@" ] hostport 1365 hostport = host [ ":" port ] 1366 host = hostname | hostnumber 1367 hostname = *[ domainlabel "." ] toplabel 1368 domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] 1369 alphadigit 1370 toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit 1371 hostnumber = digits "." digits "." digits "." digits 1372 port = digits 1373 user = *[ uchar | ";" | "?" | "&" | "=" ] 1374 password = *[ uchar | ";" | "?" | "&" | "=" ] 1375 urlpath = *xchar 1377 fpath = fsegment *[ "/" fsegment ] 1378 fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ] 1380 ftptype = "A" | "I" | "D" | "a" | "i" | "d" 1382 alphadigit = alpha | digit 1383 alpha = lowalpha | hialpha 1384 lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | 1385 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | 1386 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | 1387 "y" | "z" 1388 hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | 1389 "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | 1390 "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | 1391 "Y" | "Z" 1392 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 1393 "8" | "9" 1394 digits = 1*digit 1395 uchar = unreserved | escape 1396 unreserved = alpha | digit | safe | extra 1397 safe = "$" | "-" | "_" | "." | "+" 1398 extra = "!" | "*" | "'" | "(" | ")" | "," 1399 escape = "%" hex hex 1400 hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | 1401 "a" | "b" | "c" | "d" | "e" | "f" 1402 xchar = unreserved | reserved | escape 1403 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" 1405 Appendix C. List of Changes since RFC 1738 1407 The first specification of the 'ftp' URI is RFC 1738. This appendix 1408 lists main changes since that document. 1410 Updated syntax specification to use ABNF. 1411 Specification changed to suit RFC 3986. 1412 Changes made to accommodate HOST command [I-D ietf-ftpext2-hosts]. 1413 Given more detailed description of semantics. 1414 Clarified the syntax. 1415 Given detailed algorithm of handling . 1416 Clarified client's handling null s in . 1417 Added internationalization considerations. 1418 Clarified encoding considerations. 1419 Clarified security considerations. 1420 Added provisions regarding DDDS. 1422 Appendix D. Acknowledgments 1424 The authors of RFC 1630 and RFC 1738, who worked on the initial 'ftp' 1425 URI scheme definition, included Tim Berners-Lee, Larry Masinter and 1426 Mark McCahill. Previous attempts to specify this URI scheme were 1427 undertaken by James Casey and Paul Hoffman. 1429 Considerable input to this document was provided by (in alphabetical 1430 order) John Cowan, Frank Ellermann, John Klensin, Gordon Spoelhof, 1431 and Daniel Stenberg. 1433 Author's Addresses 1435 Mykyta Yevstifeyev 1436 8 Kuzovkov St., Apt. 25 1437 Kotovsk 1438 Ukraine 1440 EMail: evnikita2@gmail.com