Subject: [BEHAVE] FTP64 LANG

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Jan 2011 17:29:53 +0100

I've added the following text to the FTP64 draft. If there are no complaints by Monday, I'll submit the draft.

5.1.  Language negotiation

   [RFC2640] specifies the ability for clients and servers to negotiate
   the language used between the two of them in the descriptive text
   that accompanies server response codes.  Ideally, IPv6-to-IPv4 FTP
   ALGs would support this feature, so that if a non-default language is
   negotiated by a client and a server, the ALG also transmits its text
   messages for translated responses in the negotiated language.
   However, even if the ALG supports negotiation of the feature, there
   is no way to make sure that the ALG has text strings for all possible
   languages.  So the situation where the client and server try to
   negotiate a language that the ALG doesn't support can't be avoided.
   The proper behavior for an FTP ALG in this situation may be addressed
   in a future specification, as the same issue is present in IPv4-to-
   IPv4 FTP ALGs.  For the time being, ALG implementations may employ
   one of the following strategies regarding LANG negotiation:

   1.  Monitor LANG negotiation, and send text in the negotiated
       language if text in that language is available.  If not, text is
       sent in the default language.

   2.  Not monitor LANG negotiation.  Text is sent in the default
       language.

   3.  Block LANG negotiation by translating the LANG command to a NOOP
       command, and translating the resulting 200 response into a
       response appropriate for unsupported commands, such as 500.  Text
       is sent in the default language.

   In the first two cases, if a language is negotiated, text transmitted
   by the client or the server MUST be assumed to be encoded in UTF-8
   rather than be limited to 7-bit ASCII.  An ALG that implements the
   first or second option MUST translate and/or forward commands and
   responses containing UTF-8 encoded text when those occur.  The ALG
   itself MUST NOT generate characters outside the 7-bit ASCII range
   unless it implements the first option and a language was negotiated.

   Note that [RFC2640] section 3.1 specifies new handling for spaces and
   the CR character in path names.  ALGs that don't block LANG
   negotiation SHOULD comply with the specified rules for path handling.
   Implementers should especially note that the NUL (%x00) character is
   used as an escape whenever a CR character occurs in a pathname.