Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 3 Nov 2010 19:46:54 +0100

On 30 sep 2010, at 23:43, Dave Thaler wrote:

> The technical comment is that the text currently breaks internationalization as
> specified in RFC 2640 section 4, whereby the text part of responses can be
> UTF-8 non-English characters.  Currently several places in draft -05 either appear
> to specify the literal response (in English) or constrain the syntax to be ALPHA.
> In contrast RFC 2640 section 4 specifies %x01-%xFF instead of ALPHA.

I changed the ABNF to:

algs-command      = "ALGS" SP algs-token CRLF
algs-token        = "STATUS64" / "ENABLE64" / "DISABLE64" 

algs-response     = (ok-response / error-response) CRLF
ok-response       = "216" SP response-token [ freetext ]
response-token    = "NONE" / "EPSV" / "EPRT" / "EPSVEPRT"
error-response    = not-implemented / invalid-parameter
not-implemented   = "502" [ freetext ]
invalid-parameter = "504" [ freetext ]
freetext          = (SP *VCHAR)

So there should really only be three tokens now.

I didn't change the freetext specification for RFC 2640 compliance because I'm afraid this may break certain clients and the ALG is not in a good position to negotiate language or UTF8 support. I added this text:

<xref target="RFC2640" /> specifies the ability for clients and servers to negotiate the language used text messages between the two of them. This will typically involve the use of UTF-8 encoded characters outside the 7-bit ASCII range. Because client compatibility with RFC 2640 is unknown, ALGs need adopt a conservative position in this regard. As such, an ALG MUST NOT use any characters outside of the 7-bit ASCII range in the text that it generates. However, an ALG MUST transparently forward commands and responses containing UTF-8 encoded text when those occur.

Also:

In the sections that follow, a number of well-known response numbers are shown, along with the descriptive text that is associated with that response number. However, the text is not part of the specification of the response. As such, implementations MAY use the response text shown or they MAY show a different response text for a given response number. Requirements language only applies to the response number.

You mention the framework draft where I talk about FTP servers elsewhere on the internet. I think I'll reword to remove the explicit reference to the internet rather than to bring up the different scenarios from the framework, because in my opinion, the latter would just confuse readers that aren't already familiar with the framework document and require them to go out and read it, while there is really no need for that.