-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathdraft-bryan-ftpbis-00.html
More file actions
9900 lines (8500 loc) · 397 KB
/
draft-bryan-ftpbis-00.html
File metadata and controls
9900 lines (8500 loc) · 397 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>File Transfer Protocol (FTP)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="File Transfer Protocol (FTP)">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">A. Bryan, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">February 3, 2011</td></tr>
<tr><td class="header">Obsoletes: <a href='http://tools.ietf.org/html/rfc775'>775</a>, <a href='http://tools.ietf.org/html/rfc959'>959</a>, <a href='http://tools.ietf.org/html/rfc1639'>1639</a></td><td class="header"> </td></tr>
<tr><td class="header">(if approved)</td><td class="header"> </td></tr>
<tr><td class="header">Updates: <a href='http://tools.ietf.org/html/rfc1123'>1123</a> (if approved)</td><td class="header"> </td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header"> </td></tr>
<tr><td class="header">Expires: August 7, 2011</td><td class="header"> </td></tr>
</table></td></tr></table>
<h1><br />File Transfer Protocol (FTP)<br />draft-bryan-ftpbis-00</h1>
<h3>Abstract</h3>
<p>This current edition of the FTP specification is intended to
correct some minor documentation errors, incorporate and harmonize differences between RFCs, and to improve the
explanation of some protocol features.
Note that this specification is compatible with the previous edition.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on August 7, 2011.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#sec-1">1.</a>
Introduction<br />
<a href="#sec-2">2.</a>
Document Conventions and Overview<br />
<a href="#sec-2.1">2.1.</a>
Basic Tokens<br />
<a href="#sec-2.2">2.2.</a>
Pathnames<br />
<a href="#sec-2.2.1">2.2.1.</a>
Pathname Syntax<br />
<a href="#sec-2.2.2">2.2.2.</a>
Wildcarding<br />
<a href="#sec-2.3">2.3.</a>
Times<br />
<a href="#sec-2.4">2.4.</a>
Server Replies<br />
<a href="#sec-2.5">2.5.</a>
Interpreting Examples<br />
<a href="#sec-2.6">2.6.</a>
History<br />
<a href="#sec-2.7">2.7.</a>
Terminology<br />
<a href="#sec-2.8">2.8.</a>
The FTP Model<br />
<a href="#sec-3">3.</a>
Data Transfer Functions<br />
<a href="#sec-3.1">3.1.</a>
Data Representation and Storage<br />
<a href="#sec-3.1.1">3.1.1.</a>
Data Types<br />
<a href="#sec-3.1.2">3.1.2.</a>
Data Structures<br />
<a href="#sec-3.2">3.2.</a>
Establishing Data Connections<br />
<a href="#sec-3.3">3.3.</a>
Data Connection Management<br />
<a href="#sec-3.4">3.4.</a>
Transmission Modes<br />
<a href="#sec-3.4.1">3.4.1.</a>
Stream Mode<br />
<a href="#sec-3.4.2">3.4.2.</a>
Block Mode<br />
<a href="#sec-3.4.3">3.4.3.</a>
Compressed Mode<br />
<a href="#sec-3.5">3.5.</a>
Error Recovery and Restart<br />
<a href="#sec-4">4.</a>
File Transfer Functions<br />
<a href="#sec-4.1">4.1.</a>
FTP Commands<br />
<a href="#sec-4.1.1">4.1.1.</a>
Access Control Commands<br />
<a href="#sec-4.1.2">4.1.2.</a>
Transfer Parameter Commands<br />
<a href="#sec-4.1.3">4.1.3.</a>
FTP Service Commands<br />
<a href="#sec-4.1.4">4.1.4.</a>
Feature Negotiation Mechanism<br />
<a href="#sec-4.1.5">4.1.5.</a>
Extensions to FTP<br />
<a href="#anchor64">4.1.6.</a>
Other Extensions<br />
<a href="#anchor65">4.1.7.</a>
Non-standard Command Verbs<br />
<a href="#sec-4.2">4.2.</a>
FTP Replies<br />
<a href="#anchor66">4.2.1.</a>
Protected Replies from RFC 2228<br />
<a href="#sec-4.2.2">4.2.2.</a>
Reply Code By Function Groups<br />
<a href="#sec-4.2.3">4.2.3.</a>
Numeric Order List of Reply Codes<br />
<a href="#sec-5">5.</a>
Declarative Specifications<br />
<a href="#sec-5.1">5.1.</a>
Minimum Implementation<br />
<a href="#sec-5.2">5.2.</a>
Connections<br />
<a href="#sec-5.3">5.3.</a>
Commands<br />
<a href="#sec-5.3.1">5.3.1.</a>
FTP Commands<br />
<a href="#sec-5.3.2">5.3.2.</a>
FTP Command Arguments<br />
<a href="#sec-5.4">5.4.</a>
Sequencing of Commands and Replies<br />
<a href="#sec-6">6.</a>
State Diagrams<br />
<a href="#sec-7">7.</a>
Typical FTP Scenario<br />
<a href="#sec-8">8.</a>
Connection Establishment<br />
<a href="#sec-9">9.</a>
IANA Considerations<br />
<a href="#sec-10">10.</a>
Security Considerations<br />
<a href="#sec=10.1">10.1.</a>
Privacy and Passwords with Clear Text Protocols<br />
<a href="#sec-10.2">10.2.</a>
Securing FTP with TLS<br />
<a href="#anchor67">10.3.</a>
The Bounce Attack<br />
<a href="#anchor68">10.3.1.</a>
Protecting Against the Bounce Attack<br />
<a href="#anchor69">10.4.</a>
Restricted Access<br />
<a href="#anchor70">10.5.</a>
Protecting Passwords Against Brute Force Attacks<br />
<a href="#anchor71">10.6.</a>
Protecting Usernames<br />
<a href="#anchor72">10.7.</a>
Port Stealing<br />
<a href="#anchor73">10.8.</a>
Software-Base Security Problems<br />
<a href="#anchor74">10.9.</a>
Server Capabilities Exposed by FEAT<br />
<a href="#anchor75">10.10.</a>
SIZE and MLSx<br />
<a href="#anchor76">11.</a>
Authors of Included RFCs<br />
<a href="#rfc.references1">12.</a>
References<br />
<a href="#rfc.references1">12.1.</a>
Normative References<br />
<a href="#rfc.references2">12.2.</a>
Informative References<br />
<a href="#Appendix-A">Appendix A.</a>
Page Structure<br />
<a href="#Appendix-B">Appendix B.</a>
Directory Commands<br />
<a href="#Appendix-C">Appendix C.</a>
RFCs on FTP<br />
<a href="#Appendix-D">Appendix D.</a>
Acknowledgements and Contributors<br />
<a href="#Appendix-E">Appendix E.</a>
Changelog from RFC 959 and TODO<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<a name="sec-1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>
The objectives of FTP are 1) to promote sharing of files (computer
programs and/or data), 2) to encourage indirect or implicit (via
programs) use of remote computers, 3) to shield a user from
variations in file storage systems among hosts, and 4) to transfer
data reliably and efficiently. FTP, though usable directly by a user
at a terminal, is designed mainly for use by programs.
</p>
<p>
The attempt in this specification is to satisfy the diverse needs of
users of maxi-hosts, mini-hosts, personal workstations, and TACs,
with a simple, and easily implemented protocol design.
</p>
<p>
This paper assumes knowledge of the Transmission Control Protocol
(TCP) <a class='info' href='#RFC0793'>[RFC0793]<span> (</span><span class='info'>Postel, J., “Transmission Control Protocol,” September 1981.</span><span>)</span></a> and the Telnet Protocol <a class='info' href='#RFC0854'>[RFC0854]<span> (</span><span class='info'>Postel, J. and J. Reynolds, “Telnet Protocol Specification,” May 1983.</span><span>)</span></a>. These documents are contained
in the ARPA-Internet protocol handbook <a class='info' href='#IPTW'>[IPTW]<span> (</span><span class='info'>Feinler, E., “Internet Protocol Transition Workbook,” March 1982.</span><span>)</span></a>.
</p>
<p>[[ Discussion of this draft should take place on ftpext@ietf.org (or apps-discuss@ietf.org if necessary). ]]
</p>
<a name="sec-2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Document Conventions and Overview</h3>
<p>This specification describes conformance of the File Transfer Protocol (FTP).
</p>
<p>
In this section, the history, the terminology, and the FTP model are
discussed. The terms defined in this section are only those that
have special significance in FTP. Some of the terminology is very
specific to the FTP model; some readers may wish to turn to the
section on the FTP model (<a class='info' href='#sec-2.3'>Section 2.3<span> (</span><span class='info'>Times</span><span>)</span></a>) while reviewing the terminology.
</p>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a>, as scoped to those conformance targets.
</p>
<p>Syntax required is defined using the Augmented BNF defined in <a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>.
</p>
<a name="sec-2.1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Basic Tokens</h3>
<p>
This document imports the core ABNF definitions given in Appendix B
of <a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>. There definitions will be found for basic ABNF elements like
ALPHA, DIGIT, SP, etc. The following terms are added for use in this
document.
</p>
<p>
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
TCHAR = VCHAR / SP / HTAB ; visible plus white space
RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" /
"@" / "#" / "$" / "%" / "^" /
"&" / "(" / ")" / "-" / "_" /
"+" / "?" / "/" / "\" / "'" /
DQUOTE ; <"> -- double quote character (%x22)
SCHAR = RCHAR / "=" ;
</pre></div><p>
</p>
<p>
The VCHAR (from <a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>), RCHAR, SCHAR, and TCHAR types give basic
character types from varying sub-sets of the ASCII character set for
use in various commands and responses.
</p>
<p>
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
token = 1*RCHAR
</pre></div><p>
</p>
<p>
A "token" is a string whose precise meaning depends upon the context
in which it is used. In some cases it will be a value from a set of
possible values maintained elsewhere. In others it might be a string
invented by one party to an FTP conversation from whatever sources it
finds relevant.
</p>
<p>
Note that in ABNF, string literals are case insensitive. That
convention is preserved in this document, and implies that FTP
commands added by this specification have names that can be
represented in any case. That is, "MDTM" is the same as "mdtm",
"Mdtm" and "MdTm" etc. However note that ALPHA, in particular, is
case sensitive. That implies that a "token" is a case sensitive
value. That implication is correct, except where explicitly stated
to the contrary in this document, or in some other specification that
defines the values this document specifies be used in a particular
context.
</p>
<p>
</p>
<a name="sec-2.2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Pathnames</h3>
<p>
Various FTP commands take pathnames as arguments, or return pathnames
in responses. When the MLST command is supported, as indicated in
the response to the FEAT command <a class='info' href='#RFC2389'>[RFC2389]<span> (</span><span class='info'>Hethmon, P. and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,” August 1998.</span><span>)</span></a>, pathnames are to be transferred
in one of the following two formats.
</p>
<p>
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
pathname = utf-8-name / raw
utf-8-name = <a UTF-8 encoded Unicode string>
raw = <any string that is not a valid UTF-8 encoding>
</pre></div><p>
</p>
<p>
Which format is used is at the option of the user-PI or server-PI
sending the pathname. UTF-8 encodings [2] contain enough internal
structure that it is always, in practice, possible to determine
whether a UTF-8 or raw encoding has been used, in those cases where
it matters. While it is useful for the user-PI to be able to
correctly display a pathname received from the server-PI to the user,
it is far more important for the user-PI to be able to retain and
retransmit the identical pathname when required. Implementations are
advised against converting a UTF-8 pathname to a local charset that
isn't capable of representing the full Unicode character repertoire,
and then attempting to invert the charset translation later. Note
that ASCII is a subset of UTF-8. See also [1].
</p>
<p>
Unless otherwise specified, the pathname is terminated by the CRLF
that terminates the FTP command, or by the CRLF that ends a reply.
Any trailing spaces preceding that CRLF form part of the name.
Exactly one space will precede the pathname and serve as a separator
from the preceding syntax element. Any additional spaces form part
of the pathname. See <a class='info' href='#RFC2640'>[RFC2640]<span> (</span><span class='info'>Curtin, B., “Internationalization of the File Transfer Protocol,” July 1999.</span><span>)</span></a> for a fuller explanation of the character
encoding issues. All implementations supporting MLST MUST support
<a class='info' href='#RFC2640'>[RFC2640]<span> (</span><span class='info'>Curtin, B., “Internationalization of the File Transfer Protocol,” July 1999.</span><span>)</span></a>.
</p>
<p>
Note: for pathnames transferred over a data connection, there is no
way to represent a pathname containing the characters CR and LF in
sequence, and distinguish that from the end of line indication.
Hence, pathnames containing the CRLF pair of characters cannot be
transmitted over a data connection. Data connections only contain
file names transmitted from server-FTP to user-FTP as the result of
one of the directory listing commands. Files with names containing
the CRLF sequence must either have that sequence converted to some
other form, such that the other form can be recognised and be
correctly converted back to CRLF, or be omitted from the listing.
</p>
<p>
Implementations should also beware that the FTP control connection
uses Telnet NVT conventions <a class='info' href='#RFC0854'>[RFC0854]<span> (</span><span class='info'>Postel, J. and J. Reynolds, “Telnet Protocol Specification,” May 1983.</span><span>)</span></a>, and that the Telnet IAC character,
if part of a pathname sent over the control connection, MUST be
correctly escaped as defined by the Telnet protocol.
</p>
<p>
NVT also distinguishes between CR, LF, and the end of line CRLF, and
so would permit pathnames containing the pair of characters CR and LF
to be correctly transmitted. However, because such a sequence cannot
be transmitted over a data connection (as part of the result of a
LIST, NLST, or MLSD command), such pathnames are best avoided.
</p>
<p>
Implementors should also be aware that, although Telnet NVT
conventions are used over the control connections, Telnet option
negotiation MUST NOT be attempted. See <a class='info' href='#sec-5.2'>Section 5.2<span> (</span><span class='info'>Connections</span><span>)</span></a>.
</p>
<p>
</p>
<a name="sec-2.2.1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.1"></a><h3>2.2.1.
Pathname Syntax</h3>
<p>
Except where TVFS is supported (see <a class='info' href='#tvfs'>Section 4.1.5.4<span> (</span><span class='info'>A Trivial Virtual File Store (TVFS)</span><span>)</span></a>), this specification
imposes no syntax upon pathnames. Nor does it restrict the character
set from which pathnames are created. This does not imply that the
NVFS is required to make sense of all possible pathnames. Server-PIs
may restrict the syntax of valid pathnames in their NVFS in any
manner appropriate to their implementation or underlying file system.
Similarly, a server-PI may parse the pathname and assign meaning to
the components detected.
</p>
<p>
</p>
<a name="sec-2.2.2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2.2"></a><h3>2.2.2.
Wildcarding</h3>
<p>
For the commands defined in this specification, all pathnames are to
be treated literally. That is, for a pathname given as a parameter
to a command, the file whose name is identical to the pathname given
is implied. No characters from the pathname may be treated as
special or "magic", thus no pattern matching (other than for exact
equality) between the pathname given and the files present in the
NVFS of the server-FTP is permitted.
</p>
<p>
Clients that desire some form of pattern matching functionality must
obtain a listing of the relevant directory, or directories, and
implement their own file name selection procedures.
</p>
<p>
</p>
<a name="sec-2.3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Times</h3>
<p>
The syntax of a time value is:
</p>
<p>
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
time-val = 14DIGIT [ "." 1*DIGIT ]
</pre></div><p>
</p>
<p>
The leading, mandatory, fourteen digits are to be interpreted as, in
order from the leftmost, four digits giving the year, with a range of
1000--9999, two digits giving the month of the year, with a range of
01--12, two digits giving the day of the month, with a range of
01--31, two digits giving the hour of the day, with a range of
00--23, two digits giving minutes past the hour, with a range of
00--59, and finally, two digits giving seconds past the minute, with
a range of 00--60 (with 60 being used only at a leap second). Years
in the tenth century, and earlier, cannot be expressed. This is not
considered a serious defect of the protocol.
</p>
<p>
The optional digits, which are preceded by a period, give decimal
fractions of a second. These may be given to whatever precision is
appropriate to the circumstance, however implementations MUST NOT add
precision to time-vals where that precision does not exist in the
underlying value being transmitted.
</p>
<p>
Symbolically, a time-val may be viewed as
</p>
<p>
YYYYMMDDHHMMSS.sss
</p>
<p>
The "." and subsequent digits ("sss") are optional. However the "."
MUST NOT appear unless at least one following digit also appears.
</p>
<p>
Time values are always represented in UTC (GMT), and in the Gregorian
calendar regardless of what calendar may have been in use at the date
and time indicated at the location of the server-PI.
</p>
<p>
The technical differences among GMT, TAI, UTC, UT1, UT2, etc., are
not considered here. A server-FTP process should always use the same
time reference, so the times it returns will be consistent. Clients
are not expected to be time synchronized with the server, so the
possible difference in times that might be reported by the different
time standards is not considered important.
</p>
<p>
</p>
<a name="sec-2.4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.4"></a><h3>2.4.
Server Replies</h3>
<p>
<a class='info' href='#sec-4.2'>Section 4.2<span> (</span><span class='info'>FTP Replies</span><span>)</span></a> defines the format and meaning of replies by the
server-PI to FTP commands from the user-PI. Those reply conventions
are used here without change.
</p>
<p>
</p>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT
</pre></div><p>
</p>
<p>
Implementors should note that the ABNF syntax used in this document
and in other FTP related documents (but not used in <a class='info' href='#RFC0959'>[RFC0959]<span> (</span><span class='info'>Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.</span><span>)</span></a>), sometimes
shows replies using the one-line format. Unless otherwise explicitly
stated, that is not intended to imply that multi-line responses are
not permitted. Implementors should assume that, unless stated to the
contrary, any reply to any FTP command (including QUIT) may use the
multi-line format described in <a class='info' href='#sec-4.2'>Section 4.2<span> (</span><span class='info'>FTP Replies</span><span>)</span></a>.
</p>
<p>
Throughout this document, replies will be identified by the three
digit code that is their first element. Thus the term "500 reply"
means a reply from the server-PI using the three digit code "500".
</p>
<p>
</p>
<a name="sec-2.5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.5"></a><h3>2.5.
Interpreting Examples</h3>
<p>
In the examples of FTP dialogs presented in this document, lines that
begin "C> " were sent over the control connection from the user-PI to
the server-PI, lines that begin "S> " were sent over the control
connection from the server-PI to the user-PI, and each sequence of
lines that begin "D> " was sent from the server-PI to the user-PI
over a data connection created just to send those lines and closed
immediately after. No examples here show data transferred over a
data connection from the client to the server. In all cases, the
prefixes shown above, including the one space, have been added for
the purposes of this document, and are not a part of the data
exchanged between client and server.
</p>
<p>
</p>
<a name="sec-2.6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.6"></a><h3>2.6.
History</h3>
<p>
FTP has had a long evolution over the years. <a class='info' href='#Appendix-C'>Appendix C<span> (</span><span class='info'>RFCs on FTP</span><span>)</span></a> is a
chronological compilation of Request for Comments documents
relating to FTP. These include the first proposed file transfer
mechanisms in 1971 that were developed for implementation on hosts
at M.I.T. (RFC 114), plus comments and discussion in RFC 141.
</p>
<p>
RFC 172 provided a user-level oriented protocol for file transfer
between host computers (including terminal IMPs). A revision of
this as RFC 265, restated FTP for additional review, while RFC 281
suggested further changes. The use of a "Set Data Type"
transaction was proposed in RFC 294 in January 1972.
</p>
<p>
RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol
was now defined as a protocol for file transfer between HOSTs on
the ARPANET, with the primary function of FTP defined as
transfering files efficiently and reliably among hosts and
allowing the convenient use of remote file storage capabilities.
RFC 385 further commented on errors, emphasis points, and
additions to the protocol, while RFC 414 provided a status report
on the working server and user FTPs. RFC 430, issued in 1973,
(among other RFCs too numerous to mention) presented further
comments on FTP. Finally, an "official" FTP document was
published as RFC 454.
</p>
<p>
By July 1973, considerable changes from the last versions of FTP
were made, but the general structure remained the same. RFC 542
was published as a new "official" specification to reflect these
changes. However, many implementations based on the older
specification were not updated.
</p>
<p>
In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624
proposed further design changes and minor modifications. In 1975,
RFC 686 entitled, "Leaving Well Enough Alone", discussed the
differences between all of the early and later versions of FTP.
RFC 691 presented a minor revision of RFC 686, regarding the
subject of print files.
</p>
<p>
Motivated by the transition from the NCP to the TCP as the
underlying protocol, a phoenix was born out of all of the above
efforts in RFC 765 as the specification of FTP for use on TCP.
</p>
<p>In 1985, <a class='info' href='#RFC0959'>[RFC0959]<span> (</span><span class='info'>Postel, J. and J. Reynolds, “File Transfer Protocol,” October 1985.</span><span>)</span></a> added the following optional commands to FTP:
CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU
(Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD
(Print Directory), and SYST (System).
</p>
<p>
RFC 1123 "Requirements for Internet Hosts -- Application and Support"
</p>
<p>
RFC 1545 "FTP Operation Over Big Address Records (FOOBAR)"
</p>
<p>
RFC 1639 "FTP Operation Over Big Address Records (FOOBAR)"
</p>
<p>
RFC 2389 "Feature negotiation mechanism for the File Transfer Protocol"
</p>
<p>
RFC 2228 "FTP Security Extensions" AUTH, ADAT, PROT, PBSZ, CCC, MIC, CONF, ENC
</p>
<p>
RFC 2428 "FTP Extensions for IPv6 and NATs" EPRT, EPSV
</p>
<p>
RFC 2577 "FTP Security Considerations"
</p>
<p>
RFC 2640 "Internationalization of the File Transfer Protocol" and LANG command.
</p>
<p>
RFC 2773 "Encryption using KEA and SKIPJACK"
</p>
<p>
RFC 3659 "Extensions to FTP" MDTM, SIZE, REST, TVFS, MLST, MLSD
</p>
<p>
RFC 4217 "Securing FTP with TLS"
</p>
<p>
RFC 5797 "FTP Command and Extension Registry"
</p>
<p>
This current edition of the FTP specification is intended to
correct some minor documentation errors, synchronize differences between RFCs, and to improve the
explanation of some protocol features.
</p>
<p>
This specification is compatible with the previous edition. A
program implemented in conformance to the previous specification
should automatically be in conformance to this specification.
</p>
<a name="sec-2.7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.7"></a><h3>2.7.
Terminology</h3>
<p>
ASCII
</p>
<blockquote class="text">
<p>
The ASCII character set is as defined in the ARPA-Internet
Protocol Handbook. In FTP, ASCII characters are defined to be
the lower half of an eight-bit code set (i.e., the most
significant bit is zero).
</p>
</blockquote>
<p>
access controls
</p>
<blockquote class="text">
<p>
Access controls define users' access privileges to the use of a
system, and to the files in that system. Access controls are
necessary to prevent unauthorized or accidental use of files.
It is the prerogative of a server-FTP process to invoke access
controls.
</p>
</blockquote>
<p>
byte size
</p>
<blockquote class="text">
<p>
There are two byte sizes of interest in FTP: the logical byte
size of the file, and the transfer byte size used for the
transmission of the data. The transfer byte size is always 8
bits. The transfer byte size is not necessarily the byte size
in which data is to be stored in a system, nor the logical byte
size for interpretation of the structure of the data.
</p>
</blockquote>
<p>
control connection
</p>
<blockquote class="text">
<p>
The communication path between the USER-PI and SERVER-PI for
the exchange of commands and replies. This connection follows
the Telnet Protocol.
</p>
</blockquote>
<p>
data connection
</p>
<blockquote class="text">
<p>
A full duplex connection over which data is transferred, in a
specified mode and type. The data transferred may be a part of
a file, an entire file or a number of files. The path may be
between a server-DTP and a user-DTP, or between two
server-DTPs.
</p>
</blockquote>
<p>data port
</p>
<blockquote class="text">
<p>
The passive data transfer process "listens" on the data port
for a connection from the active transfer process in order to
open the data connection.
</p>
</blockquote>
<p>
DTP
</p>
<blockquote class="text">
<p>
The data transfer process establishes and manages the data
connection. The DTP can be passive or active.
</p>
</blockquote>
<p>
End-of-Line
</p>
<blockquote class="text">
<p>
The end-of-line sequence defines the separation of printing
lines. The sequence is Carriage Return, followed by Line Feed.
</p>
</blockquote>
<p>
EOF
</p>
<blockquote class="text">
<p>
The end-of-file condition that defines the end of a file being
transferred.
</p>
</blockquote>
<p>EOR
</p>
<blockquote class="text">
<p>
The end-of-record condition that defines the end of a record
being transferred.
</p>
</blockquote>
<p>error recovery
</p>
<blockquote class="text">
<p>
A procedure that allows a user to recover from certain errors
such as failure of either host system or transfer process. In
FTP, error recovery may involve restarting a file transfer at a
given checkpoint.
</p>
</blockquote>
<p>
FTP commands
</p>
<blockquote class="text">
<p>
A set of commands that comprise the control information flowing
from the user-FTP to the server-FTP process.
</p>
</blockquote>
<p>file
</p>
<blockquote class="text">
<p>
An ordered set of computer data (including programs), of
arbitrary length, uniquely identified by a pathname.
</p>
</blockquote>
<p>mode
</p>
<blockquote class="text">
<p>
The mode in which data is to be transferred via the data
connection. The mode defines the data format during transfer