[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tim Polk's DISCUSS on draft-ietf-imapext-i18n-15.txt


Ned Freed wrote:


Tim Polk have noticed the following issue with the COMPARATOR response:
>The LANGUAGE response is ambiguous for the corner case where the LANGUAGE 
>extension
>is supported but only the i-default langauge is supported.
>Specifically, Section 3.3 states:
>
>    A LANGUAGE response with a list containing a single language tag
>    indicates that the server is now using that language.  A LANGUAGE
> response with a list containing multiple language tags indicates the > server is communicating a list of available languages to the client, 
>    and no change in the active language has been made.
>
>However, for the corner case the server's list of langauges is just i-default. 
>
>Adding a requirements that "IMAP servers that support this extension MUST >support at least one langauge in addition to i-default" would correct this by >avoiding the corner case. (Just an observation, I'm not set on any particular 
>solution.)
>
So we can follow's Tim suggestion. Alternatively we can have 2 separate
responses to distinguish 2 cases. Which alternative is preferred by the WG?
Maybe I'm not reading the draft properly, but I'm not convinced this corner case exists. There are two cases: A LANGUAGE command with an argument and a 
LANGUAGE command without an argument. The former always gets a response
consisting of the single language that was selected (or an error) while the 
latter always gets a response specifying what languages are available.
In particular, I don't see a way for the LANGUAGE command with an argument 
to return the available language list.
You are correct regarding LANGUAGE responses in response to various forms of the LANGUAGE command. However the LANGUAGE response is an untagged response and in theory can be returned by the server in response to any other command. So there is still an issue of identifying the exact meaning of the response if it is sent in unexpected context.
Now, if this corner case does exist the cleanest solution would be to have 
two separate responses.


Right.


But that might break existing implementations.


Indeed.
After reading all responses on this subject I still tend to think that Tim's proposal is the best one: I can't see any good reason why a server would implement LANGUAGE command and only support i-default, as this is pointless.
But other fixes are possib;e: The obvious one would be to eliminate the case 
where a LANGUAGE command with an argument returns a list of available
languages.