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

[Iljitsch van Beijnum <[e-mail]>]

[CC to ftpext, please prune as desired when following up]

On 22 dec 2010, at 1:32, Dave Thaler wrote:

> To your later question, Microsoft's IIS does support RFC 2640
> in its FTP server.  Microsoft's current FTP clients, on the other hand, do not
> support RFC 2640.

And so does ProFTPD.

I quickly checked maybe a dozen FTP sites. A few of them supported LANG, although none any languages other than English, one UTF8 but not LANG, one LANG but not FEAT (which is in non-conformance to RFC 2640). So I guess a quick deprecation is off the table.

After reading RFC 2640 a bit more closely, it turns out that it actually allows CR/LFs in filenames, but those are escaped using a null character. This probably warrants a warning in the FTP64 document, as ALG implementers may not be aware of this and of course a null character has special meaning in languages such as C.

Back to the original problem.

Ideally, the ALG would observe the LANG negotiation and then send text in the desired language. However, there is no way to make sure that the ALG supports all the languages that clients and servers may support, so even if the ALG makes this attempt, there will be cases when it can't provide text in the desired language.

When that happens, there are two choices:

1. block the LANG negotiation and use the default language

2. ignore the LANG negotiation and use the default language

The advantage of 1 is consistency. However, this is more complex to implement and despite some evidence of LANG support I fear that actual use of this feature is too low to see good real-world testing, so there is a significant risk of bugs that won't come to light until the ALG is widely deployed. Another downside is that the user is now deprived of text in the desired language for text sent by the server that isn't touched by the ALG. Most notably, this would be the greetings. With failed LANG negotiation, users probably also wouldn't be able to use UTF-8 user names, passwords or path names.

The advantage of 2 is implementation simplicity and that the majority of the text is still in the desired language. However, some server responses will be in the ALG's (default) language rather than in the negotiated language. (But informed users can still see what's going on from the numeric response, the text is merely additional information.)

I propose the following:

- provide some explanation of the issue in the document
- ALGs MUST support UTF-8 and the CR0LF thing
- ALGs MAY monitor the LANG negotiation and adjust their language accordingly (with no opinion about what happens when the ALG supports the user desired language but the server doesn't)
- if the ALG doesn't monitor the LANG negotiation or doesn't support the negotiated language, it uses its default language

Thoughts?