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

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

On 21 dec 2010, at 19:11, Dave Thaler wrote:

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

> I think the options for an FTP64 are

> a) always reject LANG command with an error-response (RFC 2640 section 4.2)
>    In this solution, I think it should process the FEAT response and remove
>    the fact that the LANG command is supported, or it may break certain
>    clients that may expect it to succeed when the FEAT says it will.

I don't like this, because it's too tricky. I don't know of any implementations that support RFC 2640, and if those are not tested against this solution can easily create subtle bugs.

> b) reject the LANG command with an error-response whenever the FTP64
>    cannot generate text in the specified language.   In this solution,
>    I think it should process the FEAT response and remove any language
>    tags that it doesn't support, and remove the fact that the LANG command
>    is supported if the list becomes empty.

See above.

> c) appear to violate the section 4.1 MUST and generate text in a language
>    other than what the client expects.   This is what the draft currently implies
>    and I think this is broken.

I don't think there is any solution that conforms to the spirit of RFC 2640: that would be to provide text in the negotiated language. Rejecting language negotiation may be correct protocol-wise, but it really doens't help the user to get the text from the server in a non-desired language just because the ALG can't generate responses in that language.

I'm going to ask on the ftpext list to see if anyone knows about RFC 2640 implementations. If not, then the most prudent course of action would be to move RFC 2640 to historic, IMO.