Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07

[Pete Resnick <presnick at qualcomm.com>]

On 9/1/09 at 10:36 PM +0100, Alexey Melnikov wrote:

> Black_David at emc.com wrote:
>
> > - The header upconversion behavior specification for non-UTF-8
> > 	mailstores appears to be incomplete.
> > - The recommendation to support MIME header upconversion for
> > 	"Other widely deployed MIME charsets" strikes me as
> > 	too vague to be useful guidance to implementers.

I'll leave these as they are without further instruction.

> > Section 3.1, next to last paragraph needs a couple of RFC 2119
> > keywords:
> >
> >   Mailbox
> >   names must comply with the Net-Unicode Definition (section 2 of
> > MUST >-->^^^^
> >
> >   [RFC5198]) with the specific exception that they may not contain
> > MUST NOT >----------------------------------------->^^^^^^^
> >
> >   control characters (0000-001F, 0080-009F), delete (007F), line
> >   separator (2028) or paragraph separator (2029).
>
> Agreed. I've entered these as RFC Editor notes.

Fixed.

> > Section 7 recommends that all IMAP clients be modified to display a
> > clear error when the server advertises UTF8=ONLY.  What's the
> > expected behavior of existing, unmodified clients?
>
> Such clients will not be using the UTF8 parameter to SELECT/EXAMINE 
> (mailbox opening) commands, so they will fail to do anything useful. 
> But this is to be expected.

No change.

> > Nits/editorial comments:
> >
> > Section 2 ought to introduce what's being added to the protocol.
> > Adaptations of the first two sentences in Section 10 (IANA
> > Considerations) would suffice.

Done.

> > While not strictly a security consideration, it would be useful for
> > section 11 to point out the potential for user confusion caused by
> > SEARCH command match strings that have different UTF-8 representations
> > but display identically or similarly (strings that look like they
> > should match don't).

(*mumble*) This seems to me a job for RFC 3629, not this document. 
(And, BTW, it does so.)

> >  ** There is 1 instance of too long lines in the document

I'll find that.

> >  == The document seems to lack the recommended RFC 2119 boilerplate

Huh? It's in there. Or is this document so old that it doesn't use 
the precise recommended wording? I'll leave that for the RFC Editor.

> > idnits 2.11.12 found a few things (I've deleted a couple of
> > obviously incorrect "Missing Reference:" warnings):
> >
> >  Checking nits according to http://www.ietf.org/ID-Checklist.html: 
> > == Unused Reference: 'RFC2045' is defined on line 475, but no 
> > explicit
> >     reference was found in the text
>
> Not sure if this one is needed or not.

Added a reference.

> >  == Unused Reference: 'RFC2183' is defined on line 486, but no explicit
> >     reference was found in the text
> I've entered an RFC Editor note that updates the document to 
> reference this RFC.

Added.

> >  ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521)
> According to authors this reference is intentional.

It is.

Thanks David (and Alexey).

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102