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

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[e-mail]]
> Sent: Wednesday, December 22, 2010 3:41 AM
> To: Dave Thaler
> Cc: [e-mail]; Behave WG; [e-mail]
> Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
> 
> [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

Yes for LANG (as opposed to the FEAT exchange), those are the same as I 
described in my email.

> 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 last sentence is not correct.   The LANG command only controls the language
of the server's text responses.  It has no effect on the ability for the client
(or server) to use UTF-8 user names, passwords, or path names.

But yes, the advantage is consistency, and the disadvantage is that you're
limited to languages supported by both the server and the ALG.

> 
> 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.)

To repeat my earlier point, the disadvantages are
1) Text from the ALG may render as garbage (even overwriting the numeric response,
   making it impossible for the user to see what's going on... remember some languages
   are bidirectional so this isn't just about the backspace character)
2) Some clients might even crash or have other unexpected behavior, since
    2 appears to violate RFC 2640 and hence could easily have untested behavior.

To me, the above disadvantages are strong arguments against 2.

> 
> 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)

Personally, I think the above MAY needs to be a MUST.

> - if the ALG doesn't monitor the LANG negotiation or doesn't support the
> negotiated language, it uses its default language
> 
> Thoughts?

-Dave