Internet Message Access Protocol - SORT and THREAD Extensions
RFC 5256

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

Lars Eggert (was Discuss) No Objection

(Ted Hardie; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2004-03-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Chris Newman; former steering group member) Yes

Yes (2008-03-26)
No email
send info
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.

(Lisa Dusseault; former steering group member) Yes

Yes ()
No email
send info

(Ned Freed; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Scott Hollenbeck; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Allison Mankin; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-03-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

(Bill Fenner; former steering group member) (was Discuss, No Objection) No Objection

No Objection ()
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection ()
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Ward; former steering group member) No Objection

No Objection ()
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-03-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed for GEN-ART by Mark Allman.
Reviews at http://www.alvestrand.no/ietf/gen/reviews

(Jari Arkko; former steering group member) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ()
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection ()
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Steven Bellovin; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Thomas Narten; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2008-03-26)
No email
send info
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.