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

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




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

Now, if this corner case does exist the cleanest solution would be to have
two separate responses. But that might break existing implementations. 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.

				Ned