Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2008 13:45:16 -0500

Hi Mark,

--On February 27, 2008 10:26:44 AM -0800 Mark Crispin <[email-masked]> 
wrote:

> The proposed changes in the comments below create significiant
> incompatibilities with multiple interoperable client and server
> implementations that have been in production use and widely distributed
> worldwide for several years.
>
> The result of making any of these changes would be instability and
> inconsistency between implementations, creating an environment in which
> nobody can use these extensions because there is no reliable behavior.
>
> This document and its protocol are not new.  Both have been around for
> many years, and their publication was delayed unreasonably, due to (what
> is now generally recognized to have been) a false belief that
> internationalization had to be solved first.
>
> Any of these changes would add further multi-year delay to this protocol
> and specification.  Some of these involve considerable complexity which
> will require long discussion to hammer down.
>
> I recommend that these issues be punted to future work in new standards.

+1 - as written both SORT and THREAD can be easily extended with new 
behaviors as needed.

The current document describes what has been deployed to date. Whilst there 
has been much chatter in the past about defining new e.g. thread methods, 
nothing has come from any of that. So either people are happy with what is 
there now, or no one really cares that much about either of these because 
most clients in use do offline sort/thread anyhow.

-- 
Cyrus Daboo

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dan Karp <[email-masked]>
Date: Wed, 27 Feb 2008 09:12:50 -0800 (PST)

> The IESG is considering the following document again now that 
> important dependencies are ready:
> 
> - 'INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS'
>    <draft-ietf-imapext-sort-19.txt> as a Proposed Standard

Outlook (and some other clients) has an alternative solution to the
problem of localized followup/reply prefixes during the base subject
extraction process.  I believe it treats *any* string of 1 to 3 letter
characters followed by a colon as an ignorable prefix.  This may result
in too many false positives, but it's an alternative that you may want
to consider.

Also, the proposed sorting rules for the address fields (FROM, TO, and
CC) are in general worse than the rules that most clients currently use
for sorting on these headers:

  - The sort criteria for FROM, TO, and CC are based only on the
local-part of the first address in the header.  So <[email-masked]>
and <[email-masked]> sort together, which seems really wrong.  Is
there a compelling reason not to combine the addr-mailbox with the
addr-host when generating the sort key?

  - The vast majority of mail clients display the decoded addr-name in
the "From" column, falling back to addr-mailbox@addr-host if addr-name
is NIL or blank.  It's these strings that need to be in sorted order.
If the server-side FROM sort results in the client displaying a "From"
column that's not sorted, the server-side sort isn't useful.

  - Multi-recipient messages are very common, and there is no semantic
meaning to the order of recipients in the To and cc headers.  Messages
sent to "<A>, <B>" and those sent to "<B>, <A>" should really sort
together since they have the same set of recipients.  Would it be
acceptable to parse the relevant header, determine which address sorts
"highest", and always use that address as the sort key for the message?

  - Likewise, we should give serious consideration to completely
ignoring groups when determining a message's sort key.  While a
fully-qualified address means the same thing from one message to
another, the membership of a group can easily change from one message to
the next.

  - I don't think I've ever seen a client that displays a "cc" column in
the UI.  In fact, I can't come up with a remotely plausible use case for
when a user would want to sort on CC.  Unless there's a real reason for
including CC sorting, it should be dropped from the draft.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Crispin <[email-masked]>
Date: Wed, 27 Feb 2008 10:26:44 -0800 (PST)

Further comments interspersed below.

> in too many false positives, but it's an alternative that you may want

It does indeed result in false positives, and is arguably a kludge aimed 
more at Outlook's non-compliant alternatives to "re:" (which *is* defined 
as the One True Reply Prefix in RFC 2822) than the forward prefix problem.

I don't see unambiguous benefit of instituting this incompatible change, 
there is cost with new false positives and instability/unreliability of 
behavior between implementations.

I certainly do not want to redefine IETF standards as "follow whatever 
Microsoft [or other big vendor] does."  Outlook generates non-compliant 
"localized reply prefixes" based upon a false notion that "re:" is an 
abbreviation for the English word "reply".  This is a bug that should be 
fixed in Outlook.

> for sorting on these headers:

"worse" is a matter of opinion.  Reasonable people may disagree and 
may consider what "most clients" do to be "worse".

> addr-host when generating the sort key?

Although the rule in SORT was created in the days of a much smaller 
Internet community, it remains a better choice intra-enterprise where 
userids map to a single person but host ids can be all over the place.

Now, one may argue that intra-enterprise email should have a single host 
id, but that is not the reality.

Again, this would be an incompatible change that may benefit some, will 
cost others, and will create instability and unreliability.

> column that's not sorted, the server-side sort isn't useful.

Sorting the addr-name opens a HUGE can of worms.

Given the names "Bandou Mitsugoro", "Mark Crispin", "Nishimura Aiko", 
"Pedro Castro Gomez", and "Mao Zedong", a stupid sort will collate these 
as:
 	Bandou Mitsugoro
 	Mao Zedong
 	Mark R. Crispin
 	Nishimura Aiko
 	Pedro Castro Gomez
and a falsely-clever sort will collate these as:
 	Nishimura Aiko
 	Mark R. Crispin
 	Pedro Castro Gomez
 	Bandou Mitsugoro
 	Mao Zedong
Both of these are totally wrong.

The actual correct collation, assuming(!) surname-first collation and 
Latin character ordering(!!), is:
 	Bandou Mitsugoro
 	Pedro Castro Gomez
 	Mark R. Crispin
 	Mao Zedong
 	Nishimura Aiko
due to where the surname is located in various cultures.

And even that is making multiple unwarranted assumptions.  The addr-name 
may not even be a name that has a surname e.g., a corporate name.  Latin 
character ordering may not be correct either; in Japanese "Bandou" will 
collate before "Nishimura", but "Tanaka" will collate before either of 
these.

This is why this was punted to be a sort of the addr-mailbox.  Once again, 
changing this now would be an incompatible change that may benefit some, 
will cost others, and will create instability and unreliability.

> "highest", and always use that address as the sort key for the message?

Doing something like this was punted due to practicality's sake; and I 
don't see this changing.

In practice, To sorts are rare.  What little use they get is with mailing 
lists.

Once again, changing this now would be an incompatible change that may 
benefit some, will cost others, and will create instability and 
unreliability.

> another, the membership of a group can easily change from one message to

This idea is definitely something that should be punted to future work. 
Among other things, it begs the question of "what is a group" and how an 
IMAP server is supposed to determine that.

> including CC sorting, it should be dropped from the draft.

I agree that cc sorts are extremely rare.  Nonetheless, the implementation 
burden of including the capability is neglibible; and removing this may 
cause a negative impact to something that uses it now.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf