Re: draft-gahrns-imap-language-01

[Alexey Melnikov <[e-mail]>]

On Mon, 4 Oct 1999 08:07:44 -0700 Mike Gahrns <[e-mail]> 
wrote:

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

I don't mind, but draft should state that explicitely.
Without this comment "MUST" doesn't make sense.
  
> >    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.

I meant other case: Does something like "LANGUAGE (extension1 data1)" 
make sense? What is the semantics of this command.



> >    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?

Yes, I will.
---------------
Alexey Melnikov
Software Developer    phone: [phone] x 357
MessagingDirect Ltd.  fax  : [phone]

mailto:[e-mail]
http://www.MessagingDirect.com

* This e-mail message was sent with Execmail V5.0 *