Re: [MORG] I-D Action:draft-ietf-morg-sortdisplay-02.txt

[Timo Sirainen <[e-mail]>]

On Tue, 2009-11-10 at 01:05 -0800, Chris Newman wrote:
> I checked this against the X-DISPLAY-FROM, X-DISPLAY-TO and X-DISPLAY-CC 
> extension sort keys in our server implementation.  I note two differences:
> 
> 1. We decode RFC 2047 to UTF-8.  The draft does not specify charset, so an 
> implementation which decoded 2047 to a different charset would sort 
> differently.  The algorithm in 5255 section 4.6 needs to be followed, which 
> states the decoded text MUST be converted to a charset expected by the 
> active comparator.  I believe 5255 should have said that decoding to UTF-8 
> SHOULD be used where the active comparator specifies multiple acceptable 
> charsets including UTF-8.  As it does not say that, I believe it would 
> improve interoperability if this draft said that although I wouldn't 
> consider that a blocking flaw.  RFC 4790 states that any octet-based 
> charset is acceptable for i;octet.

The draft also refers to RFC 5256, which specifies decoding to UTF-8.
But yes, explicitly mentioning UTF-8 would make it clearer.

> 2. Our implementation also strips double-quotes from around the personal 
> name field prior to comparing.  I believe RFC 3501 is unclear about whether 
> double-quotes are stripped when an RFC 2822 mailbox is parsed into an IMAP 
> envelope.  I'd like this draft to state double-quotes are stripped (or 
> un-escaped) if present.

I was somehow thinking that all of this came automatically if you parse
the address using RFC2822 tokenizer. Like the address could be:

From: "Timo" (hello world) "Sirainen" <[e-mail]>

and the resulting personal name should still be "Timo Sirainen", without
double-quotes. I guess it could be mentioned, but to me this seems kind
of like band-aid to servers that already parse addresses wrong (if there
are any such servers).