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

[Dave Thaler <[e-mail]>]

One more comment...

[...]
> > 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.

Of course, in theory, neither of the above *should* be a problem 
if implementations deal with text correctly.  I guess the main point
is about RFC compliance and levels of testing.

I wouldn't want to apparently violate RFC 2640 without the 
FTPEXT group's consent, so that would be the question to the FTPEXT list.

-Dave