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

[Barry Leiba <barryleiba.mailing.lists at gmail.com>]

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.

----------------------------

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.

----------------------------

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.

----------------------------

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.

----------------------------

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.

----------------------------

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.

----------------------------

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.

----------------------------

pg 8/9

There seems to be a conflict between these two paragraphs:

   Server implementations also SHOULD up-convert all MIME body headers,
   SHOULD up-convert or remove the deprecated (and misused) name
   parameter [RFC1341] on Content-Type and MUST up-convert the Content-
   Disposition filename parameter.  These parameters can be encoded
   using the standard MIME parameter encoding [RFC2231] mechanism, or
   via non-standard use of MIME header encoding [RFC2047] in quoted
   strings.

   The IMAP server MUST NOT perform up-conversion of headers and content
   of multipart/signed, as well as Original-Recipient and Return-Path.

Isn't it possible to have a subpart of a multipart/signed message that
has a Content-Disposition header with a "filename" parameter?  If so,
the first graph says you MUST up-convert it, and the second says you
MUST NOT.

Also, I'd prefer putting the parameter names in quotes: "name"
parameter ... "filename" parameter.

----------------------------

pg 9

OLD
   7-bit downgrading to help comply with the standards are discussed in
   Downgrading mechanism for Internationalized eMail Address (IMA)
   [RFC5504].
NEW
   7-bit downgrading to help comply with the standards are discussed in
   "Downgrading Mechanism for Email Address Internationalization"
   [RFC5504].

----------------------------

I note for the record that the reference to the obsolete RFC 1341 is
intentional.  I wonder, though, whether it really ought to be
normative.  Hm.

----------------------------

That's it...
Barry