> 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@xxxxxxxxxx>
> > and <larry@xxxxxxxxxx> 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@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@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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf