Re: draft-gahrns-imap-language-01

["Mike Gahrns" <[e-mail]>]

Hi Alexey,

*** Comments within.

P.S.  I will have very limited access to e-mail the next 2.5 weeks, so I
will be slow in responding to any comments.



> Hi Mike,
>
> Here is some comments about the last draft:
>
>    1). If server supports both LANGUAGE and NAMESPACE it MUST return
NAMESPACE
> response:
> I would rather replace MUST with SHOULD, because when you describe
TRANSLATION, you
> says that
> TRANSLATION response SHOULD be sent. So if TRANSLATION response couldn't
be sent and
> NAMESPACE hasn't been changed - why send NAMESPACE response at all?
*** To make it a MUST was a request I receivedd on the previous draft.  The
rational was that it made it slightly easier for clients if they knew to
always expect a NAMESPACE response (if the server supports NAMESPACE).  I
don't have strong feelings here, either way, but tend to agree that always
sending the response could make things simpler.



>
>    2). LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
>       ; A client should not issue the optional extension parameter
>       ; unless a server has indicated in its capabilities that it
>       ; supports that extension
>
> I can't imagine any case when you want to use LANGUAGE command without
specifying
> language_tag. If somebody really wants this capability, I suggest to
create new
> command. So, my proposition is
>
> LANGUAGE_Command = "LANGUAGE" [SP <language_tag> [*EXTENSION] ]
*** In earlier discussions, it was thought that being able to enumerate the
languages available on the server would be helpful.  I agree, if at only for
diagnosis purposes.

>
>    3). EXTENSION = SP "(" string SP "(" string *(SP string)")" ")"
>
> I suspect that first parameter in the list is LANGUAGE extension name. I
prefer to
> mention that.
**** this is correct and I good suggestion I will incorporate into a future
revision

>
>    4). Primary language: Accordingly to Alvestrand RFC language tag is not
always
> hierarchical. This means that you can't always assume that x-y-z is
sublanguage of x-y.
> This means that server should have some additional knowledge about
languages it
> supports.
*** Can you suggest some text to address this?

>
>    5). Does TRANSLATION NAMESPACE extension eliminates the need to change
namespace
> prefixes?
*** Yes, that is the idea.  (this would allow for things like preserving
urls across messages, and leave it up to the client to translate namespaces
if necessary)

> I would suggest adding something like "SHOULD NOT change namespace prefix"
*** I can add this.



>
>
> Alexey
>