Subject: Re: [ftpext] RFC Errata for consideration

From: Anthony Bryan <[email-masked]>
Date: Tue, 3 Aug 2010 18:29:31 -0400

On Fri, Jul 30, 2010 at 3:43 PM, William F. Maton <[email-masked]> wrote:
>
>        If this WG gains traction, would RFC errata (such as the ones I came
> across for RFC 3659) also be dealt with as part of a charter?

while on the subject of errata, I've come across a few in RFC 959 that
I'll be posting for verification & discussion with the group. most are
editorial though.

here's one:

RFC 959

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Establishing
         Data Connections.

Errata
The representation types defined in FTP are described in Section 3.1,
Data Representation and Storage, or more specifically 3.1.1, Data
Types. They don't seem to be described in 3.2, Establishing Data
Connections.

also, RFC 1123 contains a number of updates to RFC 959 (& others).
(presumably, "Updates: XXXX" wasn't in use in 1989?) should this be
reported as errata to RFC 1123?

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: "William F. Maton" <[email-masked]>
Date: Tue, 3 Aug 2010 18:51:05 -0400 (EDT)

On Tue, 3 Aug 2010, Anthony Bryan wrote:

[snip]
> Types. They don't seem to be described in 3.2, Establishing Data

Good catch.

> reported as errata to RFC 1123?

My suspicion is that RFC 1123's errata discussion of RFC 959 should be 
reported under the new system against RFC 959, if only to capture that 
errata more easily.  On the other hand, not knowing enough about the 
mechanics about handling documents of that vintage, I'd wonder if the ADs 
could tell us if this sets a bad precedent of some kind.  (i.e., review 
every RFC in that light and start going off and using the errata reporting 
for every nit).

Then again, this could open up the discussion for creating an expanded RFC 
959bis ... !

Personally if RFC 1123 shows us some errata (and I admit to have never 
come across that RFC) in RFC 959, perhaps it's best to out it for folks 
really only looking at RFC 959.

I wonder if a survey of RFCs that 'touch' RFC 959 in some way isn't in 
order?

wfms

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 5 Aug 2010 14:48:34 -0400

>> Types. They don't seem to be described in 3.2, Establishing Data

thanks! another...

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, FTP
      Service Commands, and Miscellaneous Commands.

Errata:
There does not appear to be a section on Miscellaneous Commands,
although SITE and NOOP are listed as "Miscellaneous Commands" in
Section 5.4, Sequencing of Commands and Replies. SITE and NOOP are
described in 4.1.3, FTP Service Commands.

> every RFC in that light and start going off and using the errata reporting

I'm hoping someone who knows more about the policy will provide some guidance...

> Personally if RFC 1123 shows us some errata (and I admit to have never come
> across that RFC) in RFC 959, perhaps it's best to out it for folks really
> only looking at RFC 959.
>

yep, RFC 959's "Updated by: 2228, 2640, 2773, 3659, 5797" obviously
only mentions a couple.

RFC 1123 doesn't come up on a search for "FTP" on the RFC editor site
( http://www.rfc-editor.org/rfcsearch.html ). is it authoritative?
that is, does it update/supersede RFC 959? I brought it up because I
might as well apply the changes to the RFC 959bis I'd been working on

here are the RFCs that I found that could be added to RFC 959's
Appendix III "RFCs on FTP" (aka a list of all FTP RFCs).

RFC 959 "File Transfer Protocol"
RFC 1123 "Requirements for Internet Hosts -- Application and Support"
RFC 1415 "FTP-FTAM Gateway Specification"
RFC 1545 "FTP Operation Over Big Address Records (FOOBAR)"
RFC 1579 "Firewall-Friendly FTP"
RFC 1635 "How to Use Anonymous FTP"
RFC 1639 "FTP Operation Over Big Address Records (FOOBAR)"
RFC 2228 "FTP Security Extensions"
RFC 2389 "Feature negotiation mechanism for the File Transfer Protocol"
RFC 2428 "FTP Extensions for IPv6 and NATs"
RFC 2577 "FTP Security Considerations"
RFC 2585 "Internet X.509 Public Key Infrastructure Operational
Protocols: FTP and HTTP"
RFC 2640 "Internationalization of the File Transfer Protocol"
RFC 2773 "Encryption using KEA and SKIPJACK"
RFC 3659 "Extensions to FTP"
RFC 4217 "Securing FTP with TLS"
RFC 4823 "FTP Transport for Secure Peer-to-Peer Business Data
Interchange over the Internet"
RFC 5797 "FTP Command and Extension Registry"

---

From: "William F. Maton" <[email-masked]>
Date: Thu, 5 Aug 2010 15:54:17 -0400 (EDT)

> I'm hoping someone who knows more about the policy will provide some 

+1

> Appendix III "RFCs on FTP" (aka a list of all FTP RFCs).

Now the interesting question to ask is this:  GIven the listing of RFCs, 
which ones have actually been adopted for use versus partially versus 
ignored?  For that, we'd need more implementor participants I think, plus 
a survey of archives from the old ftpext to determine that.

wfms

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 5 Aug 2010 17:31:45 -0400

On Thu, Aug 5, 2010 at 3:54 PM, William F. Maton <[email-masked]> wrote:
> ignored?  For that, we'd need more implementor participants I think, plus a
> survey of archives from the old ftpext to determine that.

I know people from curl, FileZilla, IIS, SmartFTP, Serv-U/FTP Voyager,
and others are on this list.

I've contacted others too. who else do we need to engage?
-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: "William F. Maton" <[email-masked]>
Date: Thu, 5 Aug 2010 17:38:28 -0400 (EDT)

> I've contacted others too. who else do we need to engage?

I have contacted a couple of draft authors from the past to invite their 
interest as well.  We'll see if the mob gels into a working group or it 
flies madly off in all directions.

But I think that if the willingness isn't there to create a consolidation 
of 959 et al, then perhaps it will be a catalyst to generate new work and 
review other FTP work.

wfms

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 26 Aug 2010 15:53:11 -0400

>>> Types. They don't seem to be described in 3.2, Establishing Data

here are the other 3 errata I've reported on FTP RFCs lately. these
are all nitpicky editorial & not important, but I think these older
documents are worth reviewing by anyone who has time.

http://www.rfc-editor.org/errata_search.php?rfc=959&eid=2410

RFC0959, "File Transfer Protocol", October 1985

Source of RFC: Legacy
Errata ID: 2410

Status: Verified
Type: Editorial

Reported By: Anthony Bryan
Date Reported: 2010-08-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-08-03
Section Appendix III says:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 776, BBN, December 1980.

It should say:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 775, BBN, December 1980.

Notes:

Typo.
RFC 775 "Directory Oriented FTP Commands"
RFC 776 "Assigned Numbers"
---
http://www.rfc-editor.org/errata_search.php?rfc=1123&eid=2464

RFC1123, "Requirements for Internet Hosts - Application and Support",
October 1989

Source of RFC: Legacy
Errata ID: 2464

Status: Reported
Type: Editorial

Reported By: Anthony Bryan
Date Reported: 2010-08-15
Section 4.1.2.6 says:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 43 omits
                 them).
It should say:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 45 omits
                 them).
Notes:

In RFC 959, Figure 3 is actually on page 45, not page 43.
---
http://www.rfc-editor.org/errata_search.php?rfc=3659&eid=2496

RFC3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)
Errata ID: 2496

Status: Reported
Type: Editorial

Reported By: Anthony Bryan
Date Reported: 2010-08-21
Throughout the document, when it says:

 3.2
...
Various 4xy replies are also possible in appropriate circumstances.

4.2
...
Various 4xy replies are also possible in appropriate circumstances.

7.2.1
   Many of the 4xy and 5xy responses defined in section 4.2 of STD 9,
   RFC 959 [3] are possible in response to the MLST and MLSD commands.
...
   Other replies (530, 553, 503, 504, and any of the 4xy replies) are
   also possible in appropriate circumstances.

It should say:

 3.2
...
Various 4yz replies are also possible in appropriate circumstances.

4.2
...
Various 4yz replies are also possible in appropriate circumstances.

7.2.1
   Many of the 4yz and 5yz responses defined in section 4.2 of STD 9,
   RFC 959 [3] are possible in response to the MLST and MLSD commands.
...
   Other replies (530, 553, 503, 504, and any of the 4yz replies) are
   also possible in appropriate circumstances.

Notes:

RFC 959, Section 4.2 refers to these reply codes as 4yz and 5yz,
instead of 4xy and 5xy.

---

From: "William F. Maton" <[email-masked]>
Date: Thu, 26 Aug 2010 16:59:03 -0400 (EDT)

> documents are worth reviewing by anyone who has time.

Thanks.  Interestingly enough I have been swimming around some of the FTP 
code I have around here and found this little gem:

/* Note: a response of 425 is not mentioned as a possible response to the
  * PASV command in RFC959. However, it has been blessed as a legitimate
  * response by Jon Postel in a telephone conversation with Rick Adams on 25
  * Jan 89. */

Ah, the good ol' days. :-)

wfms