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

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Oct 2009 09:15:56 -0400

> FWIW, I also trim away some other things, which I wouldn't like to add to
> the document, e.g. outlookisms and phish vomit:
>
>    To: "[email-masked]'" <[email-masked]>
>    From: "[email-masked]" <[email-masked]>

Oh, but that can be tricky.  I agree that if the stuff in quotes is
exactly the same as the email address, you know what to do.  If it's
not, though....

It would be perfectly reasonable to have this, for example:
   From: "Barry @ home" <[email-masked]>

One could probably come up with reasonable examples of using actual
email addresses, or things that look very much like email addresses,
yet are different from the address between the <>.

The point is that I'm not sure I'd want the email programs to ignore
those bits because some clever programmer thought it would help me
out.  On the other hand, having an option to do that would certainly
be useful.  On the other hand, go try explaining that option to the
user.  On the other hand, go try explaining the automatic stuff to the
user.  And are these cases really any different, with respect to what
you'll want to show the user, and what effect it'll have?:
   From: "[email-masked]" <[email-masked]>
   From: "Bank of America Security Department" <[email-masked]>

I think the right answer to do in the "phishy/spammy" case, if you
want to do something, is to leave it alone, but flag it.

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 5 Oct 2009 15:26:02 +0200

Actually I changed my mind. What I said is just ridiculous.

It would NOT be correct for this draft to contain a specification of how 
to mangle email addresses for display. That's out of scope. What I 
actually implemented is this, and I think my code is right and my brain 
was wrong:

   1. Compute the display-name in the same way as usually
   2. If that's empty, use localpart@domain instead
   3. Sort by that, the way sort usually sorts

IMNSHO sortdisplay should say this, and skip ALL the details of how to 
turn the 822 syntax received into the actual display-name. It could ust 
say something like "in a format intended for display, rather than the 
encoding used when transmitting the message".

Arnt

---

From: Dan Karp <[email-masked]>
Date: Mon, 5 Oct 2009 07:38:10 -0700 (PDT)

> turn the 822 syntax received into the actual display-name. It could
> just  say something like "in a format intended for display, rather than
> the encoding used when transmitting the message".

The problem with this is that it probably underspecifies.  One of the
requirements of a SORT ordering is that there is a single valid value
for any given message.  This allows clients to catch the addition of a
new message and slot it into the "correct" place in the list without
having to issue a new SORT.  It's certainly not a perfect plan, as any
text-based sort ordering runs into big issues when the system hits a
malformed header or when one side can parse the charset in a 2047
encoded-word and the other can't.  But it's the rule.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 6 Oct 2009 09:53:20 +0200

Dan Karp writes:
> The problem with this is that it probably underspecifies.

Yes, I agree. But on the other hand it's close to the actual code.

> One of the requirements of a SORT ordering is that there is a single 
> valid value for any given message.

The name of this particular sort key says the key is that used for 
display, so IMO it had better be that.

> This allows clients to catch the addition of a new message and slot it 
> into the "correct" place in the list without having to issue a new 
> SORT.  It's certainly not a perfect plan, as any text-based sort 
> ordering runs into big issues when the system hits a malformed header 
> or when one side can parse the charset in a 2047 encoded-word and the 
> other can't.  But it's the rule.

I wonder if these concerns could be addressed by defining the sort key 
as equal to the addr-name sent by the server in response to 
FETCH-ENVELOPE. IIRC that's still 2047-encoded, but "like the addr-name 
you send for FETCH ENVELOPE, but 2047-decoded" is realistic and still 
simple.

Arnt

---

From: Dan Karp <[email-masked]>
Date: Tue, 6 Oct 2009 08:35:54 -0700 (PDT)

> FETCH-ENVELOPE. IIRC that's still 2047-encoded, but "like the
> addr-name you send for FETCH ENVELOPE, but 2047-decoded" is realistic
> and still simple.

This is completely reasonable, and also very much in line with the
rest of the base SORT draft.  Give me a bit of time and I'll try to
rework the draft's wording to phrase it in terms that line up with the
FETCH ENVELOPE response.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 06 Oct 2009 17:54:52 +0100

>rework the draft's wording to phrase it in terms that line up with the
I like that.

---

From: Dan Karp <[email-masked]>
Date: Sun, 18 Oct 2009 09:15:44 -0700 (PDT)

> > I wonder if these concerns could be addressed by defining the sort
> > key as equal to the addr-name sent by the server in response to
> > addr-name you send for FETCH ENVELOPE, but 2047-decoded" is
> > realistic and still simple.
> 

Revised and posted as the -02 version of the draft.  Please take a look
and let me know what you think.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 18 Oct 2009 20:44:27 +0200

> and let me know what you think.

I like it. I can tell at a glance that it matches my code, and that "at 
a glance" makes me like it.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 18 Oct 2009 21:56:59 +0200

Arnt Gulbrandsen writes:
> Dan Karp writes:
>> Revised and posted as the -02 version of the draft.  Please take a 
>> look and let me know what you think.
>
> I like it. I can tell at a glance that it matches my code, and that 
> "at a glance" makes me like it.

At a second glace, that it doesn't. "From: arnt" would be turned into 
sort key "arnt@", not "arnt". Will fix. Like even more.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 18 Oct 2009 18:40:41 -0400

> and let me know what you think.

Looks great to me. Implemented to Dovecot v1.2.7.