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

[Alexey Melnikov <alexey.melnikov at isode.com>]

Hi Barry,
Thank you for your review.

My comments with my individual participant hat on:

Barry Leiba wrote:

> I have a few comments in addition to SM's -- they're all editorial,
> but I think most of them are important.  On the other hand, the
> document's technically sound, and ready to go in that regard.
>
> ----------------------------
>
> Throughout:
> It's customary to use "that", rather than "which", to introduce
> restrictive clauses.  It's not *wrong* to use "which", but it reads
> badly to this editor's eye, and it invites confusion with
> non-restrictive clauses, which must use "which" (like this one).
>
> Examples:
> pg 4
> OLD
>   MUST reject octet sequences with the high bit set which fail to
> NEW
>   MUST reject octet sequences with the high bit set that fail to
>
> OLD
>   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
>   servers which support the "Mailbox International Naming Convention"
> NEW
>   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
>   servers that support the "Mailbox International Naming Convention"
>
> Etc.
I would leave this to RFC Editors. They always fix that.

> ----------------------------
>
> pg 4
>
> OLD
>   If the UTF8 capability is advertised, then utf8-quoted syntax MAY be
>   used with any IMAP argument that permits a string or an astring.
> NEW
>   If the server advertises the UTF8 capability, the client MAY use
>   utf8-quoted syntax with any IMAP argument that permits a string.
>
> The old text isn't clear about who advertises and who uses, and that
> should be made clear.  Also, "string" is the operative part of the
> definition of "astring", so the latter doesn't need to be specified
> here.  If it is, we also need to list "nstring".  Better to leave them
> both off.  Alternatively, "...permits a string (including astring and
> nstring)" would be OK.
Agreed.

> ----------------------------
>
> pg 4
>
> OLD
>   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
>   servers which support the "Mailbox International Naming Convention"
>   described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox
>   names and convert them to the appropriate internal format.
> NEW
>   All IMAP servers that advertise the UTF8 capability SHOULD accept
>   UTF-8 in mailbox names, and those that also support the "Mailbox
>   International Naming Convention" described in RFC 3501 section 5.1.3
>   MUST accept utf8-quoted mailbox names and convert them to the
>   appropriate internal format.
>
> If this change isn't correct, that means that I don't understand what
> this paragraph is trying to say, and so it should be made clearer
> anyway.
I agree with you.

> ----------------------------
>
> pg 4
>
> OLD
>   Mailbox
>   names must comply with the Net-Unicode Definition (section 2 of
>   [RFC5198]) with the specific exception that they may not contain
>   control characters (0000-001F, 0080-009F), delete (007F), line
>   separator (2028) or paragraph separator (2029).
> NEW
>   Mailbox
>   names MUST comply with the Net-Unicode Definition (section 2 of
>   [RFC5198]) with the specific exception that they MAY NOT contain
>   control characters (0000-001F, 0080-009F), delete (007F), line
>   separator (2028) or paragraph separator (2029).
>
> It looks like we should be using RFC 2119 words here.
Yes. David Black (GenArt) already spotted this.

> ----------------------------
>
> pg 4
>
> OLD
>   If an IMAP client issues a SEARCH command which uses a mixture of
>   utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the
>   IMAP server SHOULD reject the command with a BAD response (due to the
>   conflicting charset labels).
> NEW
>   An IMAP client MUST NOT issue a SEARCH command that uses a mixture of
>   utf8-quoted syntax and a SEARCH CHARSET other than UTF-8.  If an IMAP
>   server receives such a SEARCH command, it SHOULD reject the command
>   with a BAD response (due to the conflicting charset labels).
>
> Make it clear whose fault this is, and actively tell the client what
> it mayn't do.
>  
Agree.

> ----------------------------
>
> pg 5
>
> OLD
>     utf8-select-param = "UTF8"
>                                           ;; Conforms to
> <select-param> from RFC 4466
> NEW
>     utf8-select-param = "UTF8"
>        ;; Conforms to <select-param> from RFC 4466
>
> (Scrunch it up a bit...)
>
> ----------------------------
>
> pg 7
>
> OLD
>   Specifically, SELECT and EXAMINE with the UTF8 parameter will never
>   fail with a [NOT-UTF-8] response token.
> NEW
>   Specifically, SELECT and EXAMINE with the UTF8 parameter will never
>   fail with a [NOT-UTF-8] response code.
Indeed, "response code" is the proper RFC 3501 term.

> ----------------------------
>
> pg 8
>
> 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.
Agreed.

[...]