Re: [EAI] Comments on draft-ietf-eai-imap-utf8-07

[Joseph Yee <joseph.yee at gmail.com>]

Inline


On 2009-09-10, at 5:11 PM, Alexey Melnikov <alexey.melnikov at isode.com>  
wrote:

> Barry Leiba wrote:
>
> > Hi, Pete.
> Hi Barry,
>
> > > > OLD
> > > > The UTF8=ONLY capability implies the UTF8 base capability, the
> > > > UTF8=ALL capability and the UTF8=APPEND capability.  A server which
> > > > advertises UTF8=ONLY need not advertise the three implicit
> > > > capabilities.
> > > >
> > > > Oy.  This makes parsing the capability string complicated, and  
> > > > should
> > > > be earlier in the document.  It'd be good to make this clear at the
> > > > beginning, when the UTF8 capability is first mentioned.
> > > I'm not sure what you want here. Something in the "UTF8" section  
> > > that says,
> > > "See below"? Left as is for now. Fix in an RFC Editor Note if need  
> > > be.
> > When one starts reading the document, one gets to this:
> >
> > ---------------------------------------------
> > 3.  UTF8 IMAP Capability
> >
> >  The basic "UTF8" capability indicates the server supports UTF-8
> >  quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and  
> > UTF-8
> >  responses from the LIST and LSUB commands.
> > ---------------------------------------------
> >
> > It's only later, when one gets to section 7, which I quote above,  
> > that
> > one finds that it's not sufficient to look for "UTF8": one also has  
> > to
> > look for "UTF8=ONLY".  And we don't say that UTF8=ALL, UTF8=APPEND,  
> > or
> > UTF8=USER imply the base UTF8.  So if UTF8=ONLY is special, I think  
> > we
> > need to say that right up there at the start of section 3, so it's
> > clear.  Or else we say that the presence of *any* "UTF8=" capability
> > implies the base UTF8, and say *that* in section 3, so it's clear
> > right up front as to what capability string(s) need to be checked  
> > for.
> >
> > D'you see what I'm getting at?
> (As the responsible AD) After rereading various pieces of the  
> document, I agree this is not clear.
>
>
> (As a WG participant) Here is my understanding how things should work:
>
> UTF8=USER is useful by itself, so I think it should be independent  
> of all other UTF8* capabilities. For example it should be possible  
> to only support UTF8=USER (non EAI IMAP server, but which accepts  
> UTF-8 usernames/passwords), or support all other EAI functions,  
> without supporting UTF-8 username/password (e.g. a legacy  
> authentication database).
I agree with the second part and that's my understanding of the doc.   
Not sure of the first part.  Allowing UTF8 login/password but not UTF8- 
IMAP capable?  I don't think we need special capa for it, it can be  
done today...

> I think UTF8=APPEND should be independent of other UTF8*  
> capabilities. Allowing for EAI APPEND might require quite a bit of  
> extra work.
I personally think it can imply UTF8 but not any other UTF8-*. Not  
sure if you mean the same from UTF8*

> Both UTF8=ALL and UTF8=ONLY are related to UTF8 capability. We can  
> either define them as implying UTF8, or say that if one of them is  
> advertised, then UTF8 MUST also be advertised. Moreover, I think  
> UTF8=ONLY implies UTF8=ALL.
> One can also argue that UTF8=ONLY implies UTF8=APPEND. I would be Ok  
> either way, but one way or another this needs to be stated explicitly.
Section 7 of the doc makes it clear that UTF8-ONLY implies both ALL  
and APPEND.  I have not fully read -08 yet, is it not there anymore?

Thanks
Joseph

> Comments?
>
> _______________________________________________
> IMA mailing list
> IMA at ietf.org
> https://www.ietf.org/mailman/listinfo/ima