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

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




Dave Cridland wrote:

On Tue Mar  4 19:30:02 2008, Pete Resnick wrote:

No, I think Tim's concern is different, but I still think there is nothing (besides perhaps a little wordsmithing) that needs to be done: Tim's concern is that if you get back a LANGUAGE response with only 1 language tag, you don't know (without saving some context about what command you issued) whether that means the server is sending back its list of available languages (which only contains 1 item) or is telling you that it is now using the language it just sent back. But I think this is a distinction without a difference: If the server only supports i-default, it is *always* using i-default and will *always* return a single language tag (of i-default).

I'm open for additional text at the end of the paragraph to clarify.

I had to think hard about this - Pete's got a good point here - I just have to disagree.

What Pete's saying is that in the case where there is only one language, which MUST be i-default, there is no semantic difference between the server saying "I only use i-default" and "I am using i-default" - whatever happens, the server is now using i-default. The trouble is that if a client wishes to kick the server into telling it what languages it supports, it instead gets a message back saying that the language has been set - I have a feeling I'd still need to involve semantics at too low a level to be comfortable with. It's painful enough with unextended SEARCH, I wouldn't want to special-case anything else.

What Ned says in another message is that there is considerable work in the server knowing it only has i-default available prior to offering the extension.

On this basis, I think I'll change my mind again - we don't mandate multiple languages, since the choice to remove additional language support from the implementation can be a deployment-stage decision. Instead, we really do need to change the syntax.

I am not convinced that this is necessary.

Maybe change one to be a response code:

C001 LANGUAGE DE
* OK [LANGUAGE DE] Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt

Or we could change the response to always carry the current language, when enumerating languages:

* LANGUAGE i-default (EN DE IT i-default)

Syntax:

language-data = "LANGUAGE" SP lang-tag-quoted [ "(" lang-tag-quoted *(SP lang-tag-quoted) ")" ]

Or, when enumerating languages, i-default MUST NOT be included:

A01 LANGUAGE
* LANGUAGE ()
A01 OK I skipped all my electives at college

And finally, we could say that if you only support i-default for some reason, then you MUST say NO to LANGUAGE.

I prefer the last alternative, as it means no syntactic changes to the LANGUAGE response for deployed servers and clients.

I don't care which, but I vaguely prefer excluding it from the list - it's noise anyway, since it's mandated to be supported.