Internet Message Access Protocol - SORT and THREAD Extensions
Note: This ballot was opened for revision 14 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
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 http://www.alvestrand.no/ietf/gen/reviews
Jari Arkko No Objection
( Steven Bellovin ) No Objection
( Ron Bonica ) No Objection
( Ross Callon ) 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
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.
( Dan Romascanu ) No Objection
( Mark Townsley ) No Objection
( David Ward ) No Objection
( Margaret Wasserman ) 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?