Internet Message Access Protocol - SORT and THREAD Extensions
RFC 5256

Note: This ballot was opened for revision 20 and is now closed.

(Ted Hardie) Discuss

Discuss (2004-03-17 for -)
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.

(Lisa Dusseault) Yes

(Ned Freed) Yes

(Scott Hollenbeck) Yes

(Chris Newman) Yes

Comment (2008-03-26)
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.

(Harald Alvestrand) No Objection

Comment (2004-03-17 for -)
Reviewed for GEN-ART by Mark Allman.
Reviews at

(Jari Arkko) No Objection

(Steven Bellovin) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Margaret Cullen) No Objection

(Lars Eggert) (was Discuss) No Objection

(Pasi Eronen) No Objection

(Bill Fenner) (was Discuss, No Objection) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2008-03-26)
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

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.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

(Magnus Westerlund) No Objection

(Bert Wijnen) No Objection

Comment (2004-03-18 for -)
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?

(Alex Zinin) No Objection