datatracker.ietf.org
Sign in
Version 5.6.3, 2014-09-19
Report a bug

Internet Message Access Protocol - SORT and THREAD Extensions
RFC 5256

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

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

[Bert Wijnen]

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?

[Chris Newman]

Comment (2008-03-26 for -)

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]

Comment (2004-03-17 for -)

Reviewed for GEN-ART by Mark Allman.
Reviews at http://www.alvestrand.no/ietf/gen/reviews

[Ted Hardie]

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.

[Tim Polk]

Comment (2008-03-26 for -)

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.