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.
If there's a problem with the draft -- for instance, that the FROM sort
is useless from a client standpoint or that the CC sort will never be
used by a real-world client -- then it should be fixed before reaching
RFC status. If the resulting RFC is not protocol- or algorithm-
equivalent to revision 19 of the SORT draft, then this would not be the
first time that an extension's CAPABILITY string would have to change at
the time of publication.
I don't think that "But that doesn't match the behavior of a previous
version of the draft" is a useful argument at Last Call time.
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.
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.
The use of "Re:" is a MAY in RFC2822. And this algorithm is Outlook's
reaction to the fact that a wide variety of clients (not just Outlook)
use a reply subject prefix other than "Re:". In the draft you mention
that you don't have a good solution to this issue, and I was just noting
one possible solution.
- The sort criteria for FROM, TO, and CC are based only on the
local-part of the first address in the header. So
<larry(_at_)oracle(_dot_)com>
and <larry(_at_)google(_dot_)com> 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?
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.
Even in the intra-enterprise case, sorting by addr-mailbox(_at_)addr-host is
no worse and often better than sorting only by addr-mailbox. And using
the full address is clearly superior in the Internet email case.
- The vast majority of mail clients display the decoded addr-name in
the "From" column, falling back to addr-mailbox(_at_)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.
Sorting the addr-name opens a HUGE can of worms.
Not sorting by the display name makes the sort useless from a client
perspective. The benefit of the SORT extension is that it permits
clients to optimize bandwidth and to push the sort overhead to the
server; the trade-off is that they are forced to use the server's sort
criteria.
Your argument seems to be that if we can't make address-based sorts
perfect, then there's no point in trying to improve them. But I feel
that it's better to completely drop the address sorts rather than
publishing an RFC in which they're useless.
- 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?
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.
I've given a straightforward algorithm that would solve the problem, and
I don't see how there's a practicality issue involved.
And if you really think that TO sorting is sufficiently rare that
addressing it isn't worthwhile, then I'd say that the cost-benefit
proposition doesn't warrant keeping TO sorts in the RFC.
- 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.
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.
Groups are defined in RFC2822:
group = display-name ":" [mailbox-list / CFWS] ";"
[CFWS]
In the SORT draft, a group in the first position of a sortable address
header field counts as the sort field for the message. I'm suggesting
that this may not be a good idea.
- 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.
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.
The implementation burden of including the capability is negligible TO
YOU. That is not necessarily the case for other future server and
client implementors of SORT. Under that logic, you could argue that
SORT should include sorting on the Message-ID header. Or on the
X-Priority header. Or any other header, for that matter.
In reality, the SORT extension should include only sorts that are (a)
usable by most clients and (b) needed by most clients. Everything else
ought to be excised. The existing FROM sort is so incompatible with
real client behavior that it fails (a); the CC sort (and possibly also
the TO sort) fails (b). And I think that it'd be negligent not to
address this before publication.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf