[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tim Polk's DISCUSS on draft-ietf-imapext-i18n-15.txt
On Tue Mar 4 19:30:02 2008, Pete Resnick wrote:
On 3/4/08 at 9:41 AM -0800, Ned Freed wrote:
Tim Polk have noticed the following issue with the COMPARATOR
response:
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.
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.
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.
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 don't care which, but I vaguely prefer excluding it from the list -
it's noise anyway, since it's mandated to be supported.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade