Internet Message Access Protocol - SORT and THREAD Extensions
draft-ietf-imapext-sort-20

Revised IANA Last Call comments:

Along with adding "THREAD" and "SORT" to the IMAP4 Capabilities registry, IANA will create the following registry at http://www.iana.org/TBD:

Registry Name: IMAP Threading Algorithms
Reference: [RFC-ietf-imapext-sort-20.txt]
Registration Procedures: Standards Track or IESG-Approved Experimental RFC

Algorithm Reference
---------------- ---------
ORDEREDSUBJECT [RFC-ietf-imapext-sort-20.txt]
REFERENCES [RFC-ietf-imapext-sort-20.txt]

[Ballot discuss]
Discuss-discuss: The email from IANA on March 4 ("[IANA #144588] Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard") only seems to deal with the first paragraph of the IANA considerations section. I'm wondering if IANA has missed the request to create a new registry for threading algorithms in the second paragraph?

(That may be, because the text that defines the desired new registry is very short, and doesn't define its structure in very much detail.)

[Ballot comment]
I have reviewed changes between -18 and -20.

Suggested improvement for AUTH48 or any earlier revision:

Add a reference to STD 63 (RFC3629) for UTF-8.

[Ballot comment]
I could not parse the paragraphs that describe the UID SORT and UID THREAD commands.
Specifically, the second sentence in each paragraph seems contradictory.  From the SORT
command text:

      There is also a UID SORT command which returns unique identifiers
      instead of message sequence numbers.  Note that there are separate
      searching criteria for message sequence numbers and UIDs; thus the
      arguments to UID SORT are interpreted the same as in SORT.  This
      is analogous to the behavior of UID SEARCH, as opposed to UID
      COPY, UID FETCH, or UID STORE.

The first clause of the second sentence states that the criteria are different,
but the second clause says therefore the arguments are interpreted the same.
I think this can be fixed with an RFC Editor note.

I also suggest moving the UID SORT and UID THREAD text to their own sections, as
they would have appeared if they were part of the base specification.  This would
be consistent with the format of the rest of the document.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "IMAP4 Capabilities Registry" registry located at
http://www.iana.org/assignments/imap4-capabilities

Capability Name | Reference
------------------------+-----------------
THREAD | [RFC-ietf-imapext-sort-19.txt]
SORT | [RFC-ietf-imapext-sort-19.txt]

[Ballot comment]
This needs an edit to change en;ascii-casemap back to i;ascii-casemap
since that change occurred in RFC 4790.  Also the reference to "Internet
Appplication Protocol Collation Registry" is now RFC 4790.

Two simple/optional improvements:
Add a normative reference to STD 63 (RFC3629) for UTF-8.
Instead of allowing any 8-bit in BLOBCHAR and NONWSP, reference the rules in RFC 3629 for well-formed UTF-8 (UTF8-2, UTF8-3, UTF8-4).

In retrospect, I think it was a mistake to hold up this document waiting
for all of the IMAP i18n work to finish and to the extent I contributed
to that delay, that was a mistake I will endeavor not to repeat.  The
specification is already deployed and interoperates.  Both sort and
thread provide significant value to i18n consumers even with support
for only i;ascii-casemap (i.e. sort by date and thread by references)
and there's nothing in the spec which precludes a future extension
from switching collations.  IMHO, the reference to IMAP-I18N should be
changed to an informative reference to get this published sooner.

[Ballot comment]
This needs an edit to change en;ascii-casemap back to i;ascii-casemap since that change occurred in RFC 4790.  Also the reference to "Internet Appplication Protocol Collation Registry" is now RFC 4790.

In retrospect, I think it was a mistake to hold up this document waiting for all of the IMAP i18n work to finish and to the extent I contributed to that delay, that was a mistake I will endeavor not to repeat.  The specification is already deployed and interoperates.  Both sort and thread provide significant value to i18n consumers even with support for only i;ascii-casemap (i.e. sort by date and thread by references) and there's nothing in the spec which precludes a future extension from switching collations.  IMHO, the reference to IMAP-I18N should be changed to an informative reference.

[Ballot discuss]
The IANA Considerations section should not include a URL to the registry,
as the URL is temporary.

Write the IANA instructions: enter THREAD and SORT capabilities,
start the SORT algorithms registry with the following rules, these new
entries, with these fields.

Best thing:  include a table for the new registry that looks just like what you
want to see in the new registry.

[Ballot discuss]
The IANA Considerations section should not include a URL to the registry,
as the URL is temporary.

Write the IANA instructions: enter THREAD and SORT capabilities,
start the SORT algorithms registry with the following rules, these new
entries, with these fields.

Best thing:  include a table for the new registry that looks just like what you
want to see in the new registry.

[Ballot comment]
I am assuming that my DISCUSS is contained in Ted's discuss.
As Ted describes, this doc needs [IMAP-I18N]. I even believe
it needs it as a normative reference. But that [IMAP-I18N]
has expired. If I understand it correct. that [IMAP-I18N]
would handle the stringprep consideration, which I think are
required for any SORTing of UTF-8, no?

[Ballot discuss]
This document should follow the advice from RFC 2234:
        NOTE:    It is strongly advised to use grouping
                  notation, rather than to rely on proper reading of
                  "bare" alternations, when alternatives consist of
                  multiple rule names or literals.

thread-list    = "(" thread-members / thread-nested ")"

means 'either "(" concatenated with thread-members, or thread-nested concatenated with ")"'.  I suspect they want

thread-list = "(" (thread-members / thread-nested) ")"

Also, a very minor issue:

subj-base      = NONWSP *([*WSP] NONWSP)

[*WSP] is redundant; * already permits zero.

[Ballot discuss]
This document has a normative reference to:

[IMAP-I18N]          Newman, C. "Internet Message Access Protocol
                        Internationalization", Work in Progress.

Indeed, this document punts some of the hardest work to that reference:

  Strings in charsets other than US-ASCII and UTF-8 must be converted
  to UTF-8 prior to any comparisons.  String comparisons used in SORT
  and THREAD collations are performed as described in [IMAP-I18N].

[IMA-I18N] has not yet been revised and is not available for review;
without that, I do not believe this work can be effectively considered.
In my previous deferral, I noted that I hoped that the chair would be able to get the
editor to produce a new document.  I've tried to contact both author and
chair, but without success (almost certainly a timing issue, but a problem
none the less).

I also believe this document has some other problems; this text for example:

Non-English translations of "Re" or "Fw"/"Fwd" are not specified for
  removal in the base subject extraction process.  By specifying that
  only the English forms of the prefixes are used, it becomes a simple
  display time task to localize the prefix language for the user.  If,
  on the other hand, prefixes in multiple languages are permitted, the
  result is a geometrically complex, and ultimately unimplementable,
  task.  In order to improve the ability to support non-English display
  in Internet mail clients, only the English form of these prefixes
  should be transmitted in Internet mail messages.

seems to be saying that the Re:/Fwd are not removed for anything other
than English because it is more effective for the client to localize the
prefix language.  That requires, though, that the local client understand
the prefixes in all of the potential languages of the *senders*, rather
than simply recognizing that their own localization is "FOO".  It's a major
problem, as the text notes, but punting it to the client doesn't help.

This line:

In order to improve the ability to support non-English display
  in Internet mail clients, only the English form of these prefixes
  should be transmitted in Internet mail messages.

in particular seems way out of the bounds of this document's writ;
it isn't a 2119 SHOULD, but I'm not sure that this document has
had the kind of review that would make this a reasonable conclusion.

This documents defines two threading algorithms, ORDEREDSUBJECT and REFERENCES,
and the IANA considerations section makes it sound like there's a registry for
threading algorithms with these as the two initial entries. However, this
document doesn't actually define such a registry. I see two possibilities here:
There are only two threading algorithms, end of story, no registry needed and
hence the text about this in the IANA considerations section needs to be
removed (unlikely), or else this document creates a new registry for threading
algorithms with these two as the initial entries. If it is the latter there
needs to be text added to define the registry and explain what the registration
procedures are (RFC required, first come first serve, etc.).

In the "Sent Date" section, the procedure implied by "adjusted by time zone"
needs to be spelled out in a little more detail lest we end up with some
"creative" interpretations and corresponding implementations. It might also
make sense to discuss how to handle a date field with an invalid time zone
specification.

In the discussion of the charset argument for SORT and THREAD, reference is
made to the charset argument to SEARCH defined in the base specification,
but this document doesn't actually come out and specify that the semantics
of SORT and THREAD's charset argument are the same as that for SEARCH's. I
suggest adding a sentence along the lines of "The charset argument indicates
the [CHARSET] of the strings that appear in the {sort|thread} criteria." to
the relevant sections. The [CHARSET] reference would also need to be added
to the normative references.

The section containing the ABNF needs to state that it employs ABNF productions
defined in RFC 3501.

In the ABNF, change "; CHARSET argument to MUST be registered with IANA" to
read "; CHARSET values MUST be registered with IANA"

The RFC Editor views abstracts as essentially separate from the
document propoer. As such, it is usually necessary to have both
an Abstract describing the document as a whole very tersely and a separate
introduction to the specification that describes its purpose in a bit
more detail.

The paragraph on MUST/SHOULD/MAY/etc. conventions needs to be moved to a
section of its own separate from the abstract.

The paragraph discussing capability announcment of the SORT and THREAD
extensions also needs to be moved to a separate section.

This document doesn't contain either the copyright or the IPR
boilerplate required by RFC 2026.

The section numbering in this document is, well, strange. Most sections
aren't numbered, but then near the end up pops a section 12 and appendix
A. I understand the desire to want to use section numbers to align
the command and response material with RFC 3501, but I don't think
this obviates the need for the rest of the document to have sensible
section numbers. Here's an alternate suggestion: For the sections
intended to be "inserted" into RFFC 3501, preface the section numbers
with "BASE." or something similar. Then number the various other
sections  of this document normally.