Subject: Re: Use of IMAP SORT in Lemonade Profile Bis
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Dan Karp <[email-masked]>, Lemonade WG <[email-masked]>, Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Thu, 28 Feb 2008 08:53:21 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

On Thu, 28 Feb 2008, Alexey Melnikov wrote:
> Speaking specifically on proposed use of SORT in the Lemonade Profile Bis 
> document: just an idea (and I reserve the right to change my mind :-))
> In Lemonade Profile Bis we could define something like a new SORT-BASE 
> extension (avoid = in the capability name, as Mark pointed out that any 
> SORT=<X> implies superset of SORT functionality) that only requires 
> implementation of a subset of SORT keys that people find useful in Lemonade 
> context.

While we are it it, why doesn't Lemonade create its own non-interoperable 
subset of RFC 2822, SMTP, and IMAP?

That makes about as much sense.

-- 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.

Date: Thu, 28 Feb 2008 08:41:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS)         to Proposed Standard
Sender: [email-masked]

On Thu, 28 Feb 2008, Alexey Melnikov wrote:
> Thinking more about this: I can see that implementing sorting on CC can be 
> more IO-intensive (and possibly more CPU-intensive) than sorting on To for a 
> server that caches To header, but doesn't cache CC header.

Such a server is not a viable IMAP server.

Remember ENVELOPEs?  Cc is part of ENVELOPE.  There are clients out there 
that routinely do FETCH 1:* ENVELOPE.  SORT can not possibly be more I/O 
intensive than that.

SEARCH also has a cc key.  [SEARCH also allows arbitrary headers; yes, 
Google, that means that your server is non-compliant.]

-- 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.

Date: Thu, 28 Feb 2008 08:34:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to         Proposed Standard
Sender: [email-masked]

On Thu, 28 Feb 2008, Cyrus Daboo wrote:
> Of course the reality is a lot of web-based (PHP) webmail clients use the 
> c-client library so get SORT/THREAD "for free". I would guess that there are 
> probably more users of those type of clients than there are desktop clients 
> implementing SORT/THREAD.

Depending upon how you count, the UW client world can be anywhere from one 
client to six (soon to be seven) clients.

We have two product families: Pine and Alpine, although only Alpine 
receives any development today.

Each family has a UNIX, Windows, and Web-based client.

Web Alpine is soon to sport a completely new interface that is a major 
departure from everything that exists before.  It is not in any way 
recognizably the same as the current classic Web Alpine.

All of these clients offer full SORT/THREAD.

-- 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.

Date: Thu, 28 Feb 2008 16:30:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>, Lemonade WG <[email-masked]>
CC: Mark Crispin <[email-masked]>, Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Use of IMAP SORT in Lemonade Profile Bis
Sender: [email-masked]

Dan Karp wrote:

>So I think that it's a very good idea that "these issues be punted to
>future work in new standards," as you put it.  So I'll again put forth a
>kick-the-can-down-the-road proposal:
>
>    ... removing the FROM, TO, and CC sorts from the draft and
>    publishing it as SORT=BASE.  Then any existing server implementation
>    could advertise both SORT and SORT=BASE, indicating that they
>    support both the published RFC as well as the 3 deprecated address
>    sorts.  A subsequent draft could define SORT=FROM, with [an
>    alternative] algorithm for FROM sorting.
>  
>
Speaking specifically on proposed use of SORT in the Lemonade Profile 
Bis document: just an idea (and I reserve the right to change my mind :-))
In Lemonade Profile Bis we could define something like a new SORT-BASE 
extension (avoid = in the capability name, as Mark pointed out that any 
SORT=<X> implies superset of SORT functionality) that only requires 
implementation of a subset of SORT keys that people find useful in 
Lemonade context.

Date: Thu, 28 Feb 2008 16:12:29 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On February 28, 2008 3:29:32 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> SORT is implemented by at least two clients and at least four servers.
>>
>> SORT is implemented by at least 6 servers, as far as I know:
>> <http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.
>
> Well to be fair Dan's point is the utility of SORT for clients. So the 
> real question is how many servers AND clients support SORT/THREAD?

My comment was in response to the proposal to change behaviour of SORT 
keys at this late stage and how this would affect existing server 
implementations.

I don't have any information on number of clients using SORT, so I 
couldn't possibly comment on this.

Date: Thu, 28 Feb 2008 10:55:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to         Proposed Standard
Sender: [email-masked]

Hi Alexey,

--On February 28, 2008 3:29:32 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> SORT is implemented by at least two clients and at least four servers.
>
> SORT is implemented by at least 6 servers, as far as I know:
> <http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.

Well to be fair Dan's point is the utility of SORT for clients. So the real 
question is how many servers AND clients support SORT/THREAD?

Of course the reality is a lot of web-based (PHP) webmail clients use the 
c-client library so get SORT/THREAD "for free". I would guess that there 
are probably more users of those type of clients than there are desktop 
clients implementing SORT/THREAD.

-- 
Cyrus Daboo

Date: Thu, 28 Feb 2008 15:42:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>, Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Dan Karp wrote:

>>> - 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.
>
Thinking more about this: I can see that implementing sorting on CC can 
be more IO-intensive (and possibly more CPU-intensive) than sorting on 
To for a server that caches To header, but doesn't cache CC header.

What are the use cases for sorting on CC?

Date: Thu, 28 Feb 2008 15:29:32 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dan Karp <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 27 Feb 2008, Dan Karp wrote:
>
>>    ... removing the FROM, TO, and CC sorts from the draft and
>>    publishing it as SORT=BASE.  Then any existing server implementation
>>    could advertise both SORT and SORT=BASE, indicating that they
>>    support both the published RFC as well as the 3 deprecated address
>>    sorts.
>
> I see no reason to remove/deprecate the FROM, TO, and CC sorts.
>
> You have presented no reason other than your dislike of their 
> definition. The provision of FROM, TO, and CC sorts in no way blocks 
> future extensions that offer other forms of sorting these (and other 
> fields).
>
> I see abundant reason not to do so.
>
> SORT is implemented by at least two clients and at least four servers. 

SORT is implemented by at least 6 servers, as far as I know: 
<http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.

> All of these would have to change to support the proposed crippled 
> SORT. Worse, my client would require substantial new, special case 
> code to restore the functionality lost due to crippled SORT; and after 
> this work will have worse performance.

Date: Thu, 28 Feb 2008 14:40:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

>>  - 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;

+1. It just mean retrieving another header field and processing it in 
the same way as the To header field.

> and removing this may cause a negative impact to something that uses 
> it now.

Date: Wed, 27 Feb 2008 22:54:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Wed, 27 Feb 2008, Dan Karp wrote:
>    ... removing the FROM, TO, and CC sorts from the draft and
>    publishing it as SORT=BASE.  Then any existing server implementation
>    could advertise both SORT and SORT=BASE, indicating that they
>    support both the published RFC as well as the 3 deprecated address
>    sorts.

I see no reason to remove/deprecate the FROM, TO, and CC sorts.

You have presented no reason other than your dislike of their definition. 
The provision of FROM, TO, and CC sorts in no way blocks future extensions 
that offer other forms of sorting these (and other fields).

I see abundant reason not to do so.

SORT is implemented by at least two clients and at least four servers. 
All of these would have to change to support the proposed crippled SORT. 
Worse, my client would require substantial new, special case code to 
restore the functionality lost due to crippled SORT; and after this work 
will have worse performance.

These facilities are harmless, easy to implement as part of SORT, and have 
multiple interoperable implementations.

SORT=BASE, by subsetting SORT, violates section 1 which states that:
    A server which supports the base-level SORT extension indicates this
    with a capability name which starts with "SORT".  Future,
    upwards-compatible extensions to the SORT extension will all start
    with "SORT", indicating support for this base level.

>    A subsequent draft could define SORT=FROM, with [an
>    alternative] algorithm for FROM sorting.

I have no objection to adding new sort keys.  That has been my consistent 
position for many years.

I object strongly to removing existing sort keys.

> The point I was trying to make is that including sort criteria in the
> proposed RFC should be based on client utility, not on whether it's easy
> or hard to add them.

My client has well over a million users worldwide (we have the numbers) 
and uses SORT and THREAD as defined by this specification.

I call that utility.

> And, as you've already stated, "cc sorts are
> extremely rare" and "In practice, To sorts are rare."

The email client world is dominated, overwhelmingly, by Outlook.  I doubt 
that you mean to say that Internet email specifications should be defined 
by, and limited to, by what Outlook uses.

Notwithstanding how often To or cc sorts are used (and From sorts are 
quite commonly used), this is a functionality which has been my client for 
nearly 2 decades.  The original impetus for IMAP SORT over 10 years ago 
was to improve my client's performance by allowing large mailboxes to be 
sorted without having to download ENVELOPEs for every message in the 
mailbox.

> I understand that you don't want to break interop for clients and
> servers that have implemented draft versions of the SORT extension.  The
> SORT=BASE capability should address that issue.

That is completely unacceptable.

Besides creating a situation which is *inferior* for my client, it muddies 
the implementation waters to the point that it becomes less likely that 
any implementation will implement, much less use, SORT in any form.

It is disingenuous to use the term "draft" to describe this specification. 
This specification was approved as a Proposed Standard years ago, but was 
held up in publication because (what is now viewed as a mistake) it was 
felt that no Internet specification should deal with collation until an 
i18n framework was first put in place.

-- 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.

Date: Wed, 27 Feb 2008 16:27:55 -0600
To: Dan Karp <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS   PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 2/27/08 at 11:58 AM -0800, Dan Karp wrote:

>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.

OK, let me do a bit of a process interrupt here:

We're talking about going to Proposed Standard here, and IMO way too 
late. The current SORT *has* been implemented and looks like it may 
be considered useful by some clients. If, after publication, we find 
that it doesn't interoperate reasonably (which may include 
"independent clients don't implement this thing" or "clients can't 
get it right"), we can always go back and make changes. But the fact 
that some clients do a similar operation differently is *not* a 
reason to delay publication.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 27 Feb 2008 14:19:07 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> > But we can't publish a SORT draft in which FROM sorting is as broken
> > as it is in this draft.  We really can't.  It's worse than useless
> > in its present form, and leaving it as-is is significantly worse
> > than just omitting the FROM sort altogether.
> 
> I object to this statement and similar earlier statements.  They are
> needlessly provocative (among other things, Pine and Alpine have used
> and documented these "worse than useless" facilities for nearly 20
> years), and presume that one person's opinions are proven fact in the
> face of contrary opinion.

You're right.  Sorry about that.  I apologize for the inflammatory tone
of my previous remarks, and I'll try not to use such provocative
language going forward.

I think that a FROM sort is important, but I don't feel that many
clients at all will be able to make use of the FROM sort as specified in
revision 19 of the SORT draft.  I realize that it's probably too late in
the process to make substantive tweaks to the sorting algorithms in
SORT.  But I also realize that if a variant of the FROM sort is included
in the published SORT RFC, the probability that a more usable SORT FROM
will ever be published becomes exponentially less likely.

So I think that it's a very good idea that "these issues be punted to
future work in new standards," as you put it.  So I'll again put forth a
kick-the-can-down-the-road proposal:

    ... removing the FROM, TO, and CC sorts from the draft and
    publishing it as SORT=BASE.  Then any existing server implementation
    could advertise both SORT and SORT=BASE, indicating that they
    support both the published RFC as well as the 3 deprecated address
    sorts.  A subsequent draft could define SORT=FROM, with [an
    alternative] algorithm for FROM sorting.

> The implementation convenience in one server does not justify breaking
> a long-term framework that existing implementations depend upon.  It
> especially not removing capabilities that are used by existing
> widely-distributed client implementations.

The point I was trying to make is that including sort criteria in the
proposed RFC should be based on client utility, not on whether it's easy
or hard to add them.  And, as you've already stated, "cc sorts are
extremely rare" and "In practice, To sorts are rare."

I understand that you don't want to break interop for clients and
servers that have implemented draft versions of the SORT extension.  The
SORT=BASE capability should address that issue.

Date: Wed, 27 Feb 2008 13:51:24 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
>>> Perhaps it could be defined as non-strictly-defined
>>> way so that in different countries the sorting could be done differently
>>> based on their local rules.
>> *Shudder*
> That's how the sorting currently works in the world. Each country has
> their own local sorting rules in their phone books etc. Why should we
> force something that's different to what people have been used to?

I didn't shudder in disagreement.  I shuddered because I agree with you!

Or rather, at least to the point that localization rules *are* a critical 
component of such an effort.  The problem is that any situation in which 
l10n comes up is worth a shudder.  l10n is far more frightening than i18n 
or even m17n.

I don't believe that it can be a "non-strictly-defined way", however. 
Rather, I believe that it must be very strictly defined, with the client 
(*not* the server) deciding upon which l10n policy.  Thus, we need 
negotiation of l10n.

This, in turn, suggests that either servers have to know about lots of 
l10n rules for the world, or there needs to be some means by which a 
client can express and upload its l10n rules to the server.

Hopefully at this point you are shuddering too.  l10n is hard!  ;-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:42:02 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dan Karp <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
> I don't see a point in breaking a lot of client and server
> implementations that implement the draft in its current form. The draft
> has stayed almost the same for at least 5 years (I implemented it then
> the first time).

Thank you Timo.

>> 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.
> I think these changes should have been discussed long before reaching
> last call. The draft is over 10 years old already!

Thank you for this as well.

Not only is the draft over 10 years old, but it documents functionality 
which is far older.  Pine first offered sorting years before the SORT 
extension was first defined.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:41:14 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Dan Karp wrote:
> But we can't publish a SORT draft in which FROM sorting is as broken as
> it is in this draft.  We really can't.  It's worse than useless in its
> present form, and leaving it as-is is significantly worse than just
> omitting the FROM sort altogether.

I object to this statement and similar earlier statements.  They are 
needlessly provocative (among other things, Pine and Alpine have used and 
documented these "worse than useless" facilities for nearly 20 years), and 
presume that one person's opinions are proven fact in the face of contrary 
opinion.

Furthermore, they disregard multiple interoperable client and server 
implementations that have used the current definitions for over a 
decade.

> Apologies for not commenting sooner.  For my server, implementing
> sorting is sufficiently difficult that I'd decided to permanently skip
> the SORT draft.  But I was just informed that SORT has been made a
> prerequisite for Lemonade, and so I did my first thorough read-through
> of the draft last weekend.

Nothing requires that any client implements SORT.  If you want to define 
and implement an extended SORT, by all means start an effort to get that 
going.

The implementation convenience in one server does not justify breaking a 
long-term framework that existing implementations depend upon.  It 
especially not removing capabilities that are used by existing 
widely-distributed client implementations.

There might be some merit if there was some notable technical difficulty 
in implementing the specification on a server.  But there is not.  The 
ability to generate the IMAP ENVELOPE is required in the base 
specification and consequently all the data needed to implement FROM/TO/CC 
sorting are present.  This isn't a matter of "can not do", it is a matter 
of "not wanting to do."

Any one of us can easily come up with a long list of facilities in 
Internet specifications that we, as individuals, consider "useless" and 
thus should be removed.  However, one person's "useless" feature may be 
another's vitally-important feature.  The time to axe "useless" features 
is when they are first proposed, not when there is over a decade of use 
and deployment (in IMAP; nearly two decades in Pine).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:12:13 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> > 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 see a
> > point in breaking a lot of client and server > implementations that
> > implement the draft in its current form. The > draft has stayed
> > almost the same for at least 5 years (I implemented > it then the
> > first time).

If you change the CAPABILITY string, nothing should break.

In fact, I'd have no objections to completely removing the FROM, TO, and
CC sorts from the draft and publishing it as SORT=BASE.  Then any
existing server implementation could advertise both SORT and SORT=BASE,
indicating that they support both the published RFC as well as the 3
deprecated address sorts.  A subsequent draft could define SORT=FROM,
with a significantly less broken algorithm for FROM sorting.

But we can't publish a SORT draft in which FROM sorting is as broken as
it is in this draft.  We really can't.  It's worse than useless in its
present form, and leaving it as-is is significantly worse than just
omitting the FROM sort altogether.

> I think these changes should have been discussed long before reaching
> last call. The draft is over 10 years old already!

Apologies for not commenting sooner.  For my server, implementing
sorting is sufficiently difficult that I'd decided to permanently skip
the SORT draft.  But I was just informed that SORT has been made a
prerequisite for Lemonade, and so I did my first thorough read-through
of the draft last weekend.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 22:27:07 +0200
Sender: [email-masked]

--=-B4hxkkVDOEdjxSLSKZbc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 11:22 -0800, Mark Crispin wrote:
> On Wed, 27 Feb 2008, Timo Sirainen wrote:
> > I agree. Such standard could have:
> > - THREAD=3DREFERENCES2 which drops subject merging and changes root nod=
es
> > to be sorted by INTERNALDATE instead of sent-date.
> > - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
> > - FROM/TO/CC-ADDRNAME doing the below:
>=20
> That's why the specification was left with extension capability.  But, as=
=20
> Cyrus points out, there's been a lot of chatter but nothing much coming o=
f=20
> it.

I've implemented X-REFERENCES2, although it's not in a release version
yet. Would be nice to get it standardized.

> > Perhaps it could be defined as non-strictly-defined
> > way so that in different countries the sorting could be done differentl=
y
> > based on their local rules.
>=20
> *Shudder*

That's how the sorting currently works in the world. Each country has
their own local sorting rules in their phone books etc. Why should we
force something that's different to what people have been used to?

> > BTW. What happened to morg list? Wasn't it supposed to talk about these
> > kind of issues? It seemed to die after two weeks (or did I just get
> > unsubscribed..)
>=20
> I've never heard of morg.

It was announced on this list:
http://www.imc.org/ietf-imapext/mail-archive/msg03913.html

--=-B4hxkkVDOEdjxSLSKZbc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-B4hxkkVDOEdjxSLSKZbc--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Dan Karp <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 22:22:56 +0200
Sender: [email-masked]

--=-WM7eiMau096dk+47W2TY
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 11:58 -0800, Dan Karp wrote:
> > The proposed changes in the comments below create significiant=20
> > incompatibilities with multiple interoperable client and server=20
> > implementations that have been in production use and widely
> > distributed worldwide for several years.
> >=20
> > The result of making any of these changes would be instability and=20
> > inconsistency between implementations, creating an environment in
> > which nobody can use these extensions because there is no reliable
> > behavior.
>=20
> 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 see a point in breaking a lot of client and server
implementations that implement the draft in its current form. The draft
has stayed almost the same for at least 5 years (I implemented it then
the first time).

> 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.

I think these changes should have been discussed long before reaching
last call. The draft is over 10 years old already!

--=-WM7eiMau096dk+47W2TY
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WM7eiMau096dk+47W2TY--

Date: Wed, 27 Feb 2008 11:58:43 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> 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 <[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?
> 
> 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.

Date: Wed, 27 Feb 2008 11:22:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
> I agree. Such standard could have:
> - THREAD=REFERENCES2 which drops subject merging and changes root nodes
> to be sorted by INTERNALDATE instead of sent-date.
> - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
> - FROM/TO/CC-ADDRNAME doing the below:

That's why the specification was left with extension capability.  But, as 
Cyrus points out, there's been a lot of chatter but nothing much coming of 
it.

>> Sorting the addr-name opens a HUGE can of worms.
> I agree that there's no entirely correct way to do this, but clients
> already do this themselves so a server should be able to do it some way
> as well. I think most people would expect that it sorts in a dummy
> strcasecmp() way.

I have opinions on how such should be specified, but IMHO discussion of 
such is best done at leisure in a pub with large (and infinitely refilled) 
pitchers of beer in front of us.

The very worst place would be inside a formal meeting room at IETF with no 
beer, a time limit, and an assumption that we have to have ONE solution at 
the end.  That will quickly result in some very unhappy people, and 
presently several very angry people.

I have little doubt that the outcome would be the same either way, but in 
the former the people involved would be happy with it.

> Perhaps it could be defined as non-strictly-defined
> way so that in different countries the sorting could be done differently
> based on their local rules.

*Shudder*

> BTW. What happened to morg list? Wasn't it supposed to talk about these
> kind of issues? It seemed to die after two weeks (or did I just get
> unsubscribed..)

I've never heard of morg.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 21:05:25 +0200
Sender: [email-masked]

--=-ShGIGVlVpa1n4OfkniIE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 10:26 -0800, Mark Crispin wrote:
> I recommend that these issues be punted to future work in new standards.

I agree. Such standard could have:

 - THREAD=3DREFERENCES2 which drops subject merging and changes root nodes
to be sorted by INTERNALDATE instead of sent-date.
 - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
 - FROM/TO/CC-ADDRNAME doing the below:

> >  - 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.
>=20
> Sorting the addr-name opens a HUGE can of worms.

I agree that there's no entirely correct way to do this, but clients
already do this themselves so a server should be able to do it some way
as well. I think most people would expect that it sorts in a dummy
strcasecmp() way. Perhaps it could be defined as non-strictly-defined
way so that in different countries the sorting could be done differently
based on their local rules.

BTW. What happened to morg list? Wasn't it supposed to talk about these
kind of issues? It seemed to die after two weeks (or did I just get
unsubscribed..)

--=-ShGIGVlVpa1n4OfkniIE
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-ShGIGVlVpa1n4OfkniIE--

Date: Wed, 27 Feb 2008 13:45:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Dan Karp <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

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

Date: Wed, 27 Feb 2008 10:26:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

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.

Further comments interspersed below.

On Wed, 27 Feb 2008, Dan Karp wrote:
>
>> 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.

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.

> 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:

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

>  - 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?

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.

>  - 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.

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.

>  - 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.

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

>  - 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.

>  - 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.

-- 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.

Date: Wed, 27 Feb 2008 09:12:50 -0800 (PST)
From: Dan Karp <[email-masked]>
To: [email-masked]
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sun, 24 Feb 2008 18:57:47 +0200
Sender: [email-masked]

--=-hbvZ7OCv4h8AhHZ2yPeQ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2008-02-24 at 08:36 -0800, Mark Crispin wrote:
> > It doesn't say anything about INTERNALDATE fallbacking here, but it
> > explicitly says that sequence fallbacking is done for broken dates. So
> > based on the text:
> >
> > (4) When sorting roots:
> > - Exact Date: match -> Use sequence comparison
> > - Date: is missing -> Use INTERNALDATE
> > - Date: is broken -> Use INTERNALDATE
> >
> > (6) When sorting non-roots:
> > - Exact Date: match -> Use sequence comparison
> > - Date: is missing -> Unspecified! Does it belong to "can not be
> > parsed" category? Should it fallback to using INTERNALDATE like with
> > (4)?
> > - Date: is broken -> Use sequence comparison
> >
> > UW-IMAP implementation for (6) does:
> >
> > - Exact Date: match -> Use sequence comparison (OK)
> > - Date: is missing -> Uses INTERNALDATE
> > - Date: is broken -> Uses INTERNALDATE (wrong!)
>=20
> There was a long discussion about this.  I believe that the issue was tha=
t=20
> sequence comparison for anything other than exact date match led to an=20
> unresolvable sort.

I agree that it's better to use INTERNALDATE fallbacking for both, but
the draft's text is now clearly wrong and should be changed before
reaching RFC. So something like:

"In case of an exact match on sent date or if either of the Date:
headers used in a comparison can not be parsed, use the same rules as in
step (4)."

--=-hbvZ7OCv4h8AhHZ2yPeQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-hbvZ7OCv4h8AhHZ2yPeQ--

Date: Sun, 24 Feb 2008 08:36:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sun, 24 Feb 2008, Timo Sirainen wrote:
> "(6) Traverse the messages under the root and sort each set of
>          siblings by sent date.  Traverse the messages in such a way
>          that the "youngest" set of siblings are sorted first, and the
>          "oldest" set of siblings are sorted last (grandchildren are
>          sorted before children, etc)."
> I don't understand what the last sentence is trying to say. What does it
> matter in which order the messages are sorted? The result is the same
> anyway. Or does "first" and "last" mean the message order in the sorted
> result or the chronological sorting order?

I'll defer this question to Ken.  That's his text.

> "In the case of an exact match on
>          sent date or if either of the Date: headers used in a
>          comparison can not be parsed, use the order in which the
>          messages appear in the mailbox (that is, by sequence number) to
>          determine the order."
>
> It doesn't say anything about INTERNALDATE fallbacking here, but it
> explicitly says that sequence fallbacking is done for broken dates. So
> based on the text:
>
> (4) When sorting roots:
> - Exact Date: match -> Use sequence comparison
> - Date: is missing -> Use INTERNALDATE
> - Date: is broken -> Use INTERNALDATE
>
> (6) When sorting non-roots:
> - Exact Date: match -> Use sequence comparison
> - Date: is missing -> Unspecified! Does it belong to "can not be
> parsed" category? Should it fallback to using INTERNALDATE like with
> (4)?
> - Date: is broken -> Use sequence comparison
>
> UW-IMAP implementation for (6) does:
>
> - Exact Date: match -> Use sequence comparison (OK)
> - Date: is missing -> Uses INTERNALDATE
> - Date: is broken -> Uses INTERNALDATE (wrong!)

There was a long discussion about this.  I believe that the issue was that 
sequence comparison for anything other than exact date match led to an 
unresolvable sort.

-- 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.

Date: Sun, 24 Feb 2008 08:28:50 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

The full statement is:
             (B) Create a parent/child link between the last reference
             (or NIL if there are no references) and the current message.
             If the current message already has a parent, it is probably
             the result of a truncated References header line, so break
             the current parent/child link before creating the new
             correct one.

The first sentence is absolute; it is always done.  So, to use your 
example below:
 	Go to school.  If today is trash pickup day, take out
 	the trash before going to school.

The ambiguity exists only if the first sentence is absent.

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> "break the current parent/child link before creating the new correct
> one."
>
> What exactly does "before" mean? It's normally used when assuming that
> the rest of the sentence happens, like "take out the trash before going
> to school". What does it mean if it doesn't happen? If I don't go to
> school after all, do I still take out the trash? Or "remove the plastic
> before eating" - do I remove the plastic if I don't eat it? If I don't
> "create the new correct link" because it would loop, do I still "break
> the current parent/child link"? I don't think there's one correct way to
> read the sentence.
>
>

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sun, 24 Feb 2008 14:27:30 +0200
Sender: [email-masked]

--=-/inu2vwcKlwz6rLDsoBj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Two things here:

"(4) Sort the messages under the root (top-level siblings only)
          by sent date.  In the case of an exact match on sent date, use
          the order in which the messages appear in the mailbox (that is,
          by sequence number) to determine the order.
          [..] If the sent date can not
          be determined (a Date: header is missing or can not be parsed),
          the INTERNALDATE for that message is used as the sent date."

"(6) Traverse the messages under the root and sort each set of
          siblings by sent date.  Traverse the messages in such a way
          that the "youngest" set of siblings are sorted first, and the
          "oldest" set of siblings are sorted last (grandchildren are
          sorted before children, etc)."

I don't understand what the last sentence is trying to say. What does it
matter in which order the messages are sorted? The result is the same
anyway. Or does "first" and "last" mean the message order in the sorted
result or the chronological sorting order?

"In the case of an exact match on
          sent date or if either of the Date: headers used in a
          comparison can not be parsed, use the order in which the
          messages appear in the mailbox (that is, by sequence number) to
          determine the order."

It doesn't say anything about INTERNALDATE fallbacking here, but it
explicitly says that sequence fallbacking is done for broken dates. So
based on the text:

(4) When sorting roots:
 - Exact Date: match -> Use sequence comparison
 - Date: is missing -> Use INTERNALDATE
 - Date: is broken -> Use INTERNALDATE

(6) When sorting non-roots:
 - Exact Date: match -> Use sequence comparison
 - Date: is missing -> Unspecified! Does it belong to "can not be
parsed" category? Should it fallback to using INTERNALDATE like with
(4)?
 - Date: is broken -> Use sequence comparison

UW-IMAP implementation for (6) does:

 - Exact Date: match -> Use sequence comparison (OK)
 - Date: is missing -> Uses INTERNALDATE
 - Date: is broken -> Uses INTERNALDATE (wrong!)

--=-/inu2vwcKlwz6rLDsoBj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-/inu2vwcKlwz6rLDsoBj--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 22:59:44 +0200
Sender: [email-masked]

--=-NuKx5odKdBsH/02ApUe0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 22:41 +0200, Timo Sirainen wrote:
> This is how all servers seem to implement it, except Dovecot. I
> originally understood the text to mean:
>=20
> if not is_a_loop(msg, new_parent)
>   if msg->parent !=3D NULL
>     unlink(msg)
>   link(msg, new_parent)

"break the current parent/child link before creating the new correct
one."

What exactly does "before" mean? It's normally used when assuming that
the rest of the sentence happens, like "take out the trash before going
to school". What does it mean if it doesn't happen? If I don't go to
school after all, do I still take out the trash? Or "remove the plastic
before eating" - do I remove the plastic if I don't eat it? If I don't
"create the new correct link" because it would loop, do I still "break
the current parent/child link"? I don't think there's one correct way to
read the sentence.

--=-NuKx5odKdBsH/02ApUe0
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-NuKx5odKdBsH/02ApUe0--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 22:41:55 +0200
Sender: [email-masked]

--=-WW2VMTgyz1cN98Ig/MTN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 11:47 -0800, Mark Crispin wrote:
> On Sat, 23 Feb 2008, Mark Crispin wrote:
> > I wasn't judging whether or not it said it should be done.  In re-readi=
ng=20
> > the description, I don't see how it can be any other way though.
>=20
> In particular, UW imapd does NOT explicitly break the parent->child link=20
> if there is a loop; it just disregards it in that case.  However, implici=
t=20
> behavior from first executing the previous part of that rule is a=20
> different matter.

I suppose we're talking about the same thing. To translate the text to
pseudocode:

if msg->parent !=3D NULL
  unlink(msg)
if not is_a_loop(msg, new_parent)
  link(msg, new_parent)

This is how all servers seem to implement it, except Dovecot. I
originally understood the text to mean:

if not is_a_loop(msg, new_parent)
  if msg->parent !=3D NULL
    unlink(msg)
  link(msg, new_parent)

--=-WW2VMTgyz1cN98Ig/MTN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WW2VMTgyz1cN98Ig/MTN--

Date: Sat, 23 Feb 2008 11:47:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Mark Crispin wrote:
> I wasn't judging whether or not it said it should be done.  In re-reading 
> the description, I don't see how it can be any other way though.

In particular, UW imapd does NOT explicitly break the parent->child link 
if there is a loop; it just disregards it in that case.  However, implicit 
behavior from first executing the previous part of that rule is a 
different matter.

-- 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.

Date: Sat, 23 Feb 2008 11:43:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:
>>> Should the original parent/child link be broken if adding the new one
>>> would introduce a loop? I think this should be clarified in the text.
>> It doesn't say that that should be done; therefore it is not done.
> I think it's ambiguous. And now it's even more ambiguous because you say
> it shouldn't be broken, but your implementation breaks it.

Sorry; I meant to type "IF it doesn't say that should be done; therefore 
it is not done."

I wasn't judging whether or not it said it should be done.  In re-reading 
the description, I don't see how it can be any other way though.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:34:15 +0200
Sender: [email-masked]

--=-51S5e2UQf4WNwrnmbpWC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:

> > Should the original parent/child link be broken if adding the new one
> > would introduce a loop? I think this should be clarified in the text.
>=20
> It doesn't say that that should be done; therefore it is not done.

I think it's ambiguous. And now it's even more ambiguous because you say
it shouldn't be broken, but your implementation breaks it.

--=-51S5e2UQf4WNwrnmbpWC
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-51S5e2UQf4WNwrnmbpWC--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:32:09 +0200
Sender: [email-masked]

--=-RDc1x9P9mO3d7eJzXQFT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 21:09 +0200, Timo Sirainen wrote:
> REFERENCES -> (1) -> (B):
>=20
>              If the current message already has a parent, [..], so break
>              the current parent/child link before creating the new
>              correct one.  As in step 1.A, do not create the parent/child
>              link if creating that link would introduce a loop.
>=20
> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

I was pretty sure that it shouldn't have been broken, but looks like
UW-IMAP does break it. Also strictly reading the text I suppose that's
the correct interpretation. So Dovecot has been doing this wrong for
years.

--=-RDc1x9P9mO3d7eJzXQFT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-RDc1x9P9mO3d7eJzXQFT--

Date: Sat, 23 Feb 2008 11:29:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> But these apply to (B) part as well. Some kind of text restructuring to
> move them to (1) level would make it more logical. But I guess this
> doesn't matter all that much.

It doesn't matter, since (1)(B) results directly from (1)(A) and thus that 
decision has already been made.

> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

It doesn't say that that should be done; therefore it is not done.

It's possible to add an infinite number of "should I do this" that isn't 
stated in the document.  I don't think that we should attempt to 
exhaustively list all the things that should not be done; rather specify 
precisely what should be done.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:09:26 +0200
Sender: [email-masked]

--=-g3FaAwKHUFl2sOrbfksf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

REFERENCES -> (1) -> (A) has:

                If a message does not contain a Message-ID header line,
                or the Message-ID header line does not contain a valid
                Message ID, then assign a unique Message ID to this
                message.

                If two or more messages have the same Message ID, then
                only use that Message ID in the first (lowest sequence
                number) message, and assign a unique Message ID to each
                of the subsequent messages with a duplicate of that
                Message ID.

But these apply to (B) part as well. Some kind of text restructuring to
move them to (1) level would make it more logical. But I guess this
doesn't matter all that much.

REFERENCES -> (1) -> (B):

             If the current message already has a parent, [..], so break
             the current parent/child link before creating the new
             correct one.  As in step 1.A, do not create the parent/child
             link if creating that link would introduce a loop.

Should the original parent/child link be broken if adding the new one
would introduce a loop? I think this should be clarified in the text.

--=-g3FaAwKHUFl2sOrbfksf
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-g3FaAwKHUFl2sOrbfksf--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard 
Date: Tue, 19 Feb 2008 15:29:10 -0800 (PST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-03-04. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-19.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4540&rfc_flag=0

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 19 Feb 2008 15:29:10 -0800 (PST)
Sender: [email-masked]

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-03-04. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-19.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4540&rfc_flag=0

Date: Wed, 6 Feb 2008 17:18:03 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: [email-masked]
Subject: IETF no longer accepts free-format Internet-drafts
Organization: Networks & Distributed Computing
Sender: [email-masked]

It seems that a consequence of the IETF's new service provider, it is no 
longer possible to upload a free-format Internet-draft.  Instead of just 
emailing to [email-masked], we're now supposed to use a web page
 	https://datatracker.ietf.org/idst/upload.cgi
which enforces the idnits requirements and spews forth:
 	Pages [sic] is not in numeric format.

Bah, humbug.  Pretty formatting is the RFC Editor's job.  Requiring such 
for drafts is a waste of time.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-imapext-i18n-15.txt 
Date: Fri,  1 Feb 2008 13:30:02 -0800 (PST)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title           : Internet Message Access Protocol Internationalization
	Author(s)       : C. Newman, et al.
	Filename        : draft-ietf-imapext-i18n-15.txt
	Pages           : 19
	Date            : 2008-02-01

Internet Message Access Protocol (IMAP) version 4rev1 has basic
 support for non-ASCII characters in mailbox names and search
 substrings.  It also supports non-ASCII message headers and content
 encoded as specified by Multipurpose Internet Mail Extensions
 (MIME).  This specification defines a collection of IMAP extensions
 which improve international support including comparator negotiation
 for search, sort and thread, language negotiation for international
 error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-15.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-imapext-i18n-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-15.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-02-01132606.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Thu, 28 Feb 2008 08:53:21 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Dan Karp <[email-masked]>, Lemonade WG <[email-masked]>, Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Use of IMAP SORT in Lemonade Profile Bis
Sender: [email-masked]

On Thu, 28 Feb 2008, Alexey Melnikov wrote:
> Speaking specifically on proposed use of SORT in the Lemonade Profile Bis 
> document: just an idea (and I reserve the right to change my mind :-))
> In Lemonade Profile Bis we could define something like a new SORT-BASE 
> extension (avoid = in the capability name, as Mark pointed out that any 
> SORT=<X> implies superset of SORT functionality) that only requires 
> implementation of a subset of SORT keys that people find useful in Lemonade 
> context.

While we are it it, why doesn't Lemonade create its own non-interoperable 
subset of RFC 2822, SMTP, and IMAP?

That makes about as much sense.

-- 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.

Date: Thu, 28 Feb 2008 08:41:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS)         to Proposed Standard
Sender: [email-masked]

On Thu, 28 Feb 2008, Alexey Melnikov wrote:
> Thinking more about this: I can see that implementing sorting on CC can be 
> more IO-intensive (and possibly more CPU-intensive) than sorting on To for a 
> server that caches To header, but doesn't cache CC header.

Such a server is not a viable IMAP server.

Remember ENVELOPEs?  Cc is part of ENVELOPE.  There are clients out there 
that routinely do FETCH 1:* ENVELOPE.  SORT can not possibly be more I/O 
intensive than that.

SEARCH also has a cc key.  [SEARCH also allows arbitrary headers; yes, 
Google, that means that your server is non-compliant.]

-- 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.

Date: Thu, 28 Feb 2008 08:34:40 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to         Proposed Standard
Sender: [email-masked]

On Thu, 28 Feb 2008, Cyrus Daboo wrote:
> Of course the reality is a lot of web-based (PHP) webmail clients use the 
> c-client library so get SORT/THREAD "for free". I would guess that there are 
> probably more users of those type of clients than there are desktop clients 
> implementing SORT/THREAD.

Depending upon how you count, the UW client world can be anywhere from one 
client to six (soon to be seven) clients.

We have two product families: Pine and Alpine, although only Alpine 
receives any development today.

Each family has a UNIX, Windows, and Web-based client.

Web Alpine is soon to sport a completely new interface that is a major 
departure from everything that exists before.  It is not in any way 
recognizably the same as the current classic Web Alpine.

All of these clients offer full SORT/THREAD.

-- 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.

Date: Thu, 28 Feb 2008 16:30:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>, Lemonade WG <[email-masked]>
CC: Mark Crispin <[email-masked]>, Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Use of IMAP SORT in Lemonade Profile Bis
Sender: [email-masked]

Dan Karp wrote:

>So I think that it's a very good idea that "these issues be punted to
>future work in new standards," as you put it.  So I'll again put forth a
>kick-the-can-down-the-road proposal:
>
>    ... removing the FROM, TO, and CC sorts from the draft and
>    publishing it as SORT=BASE.  Then any existing server implementation
>    could advertise both SORT and SORT=BASE, indicating that they
>    support both the published RFC as well as the 3 deprecated address
>    sorts.  A subsequent draft could define SORT=FROM, with [an
>    alternative] algorithm for FROM sorting.
>  
>
Speaking specifically on proposed use of SORT in the Lemonade Profile 
Bis document: just an idea (and I reserve the right to change my mind :-))
In Lemonade Profile Bis we could define something like a new SORT-BASE 
extension (avoid = in the capability name, as Mark pointed out that any 
SORT=<X> implies superset of SORT functionality) that only requires 
implementation of a subset of SORT keys that people find useful in 
Lemonade context.

Date: Thu, 28 Feb 2008 16:12:29 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Mark Crispin <[email-masked]>, Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On February 28, 2008 3:29:32 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> SORT is implemented by at least two clients and at least four servers.
>>
>> SORT is implemented by at least 6 servers, as far as I know:
>> <http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.
>
> Well to be fair Dan's point is the utility of SORT for clients. So the 
> real question is how many servers AND clients support SORT/THREAD?

My comment was in response to the proposal to change behaviour of SORT 
keys at this late stage and how this would affect existing server 
implementations.

I don't have any information on number of clients using SORT, so I 
couldn't possibly comment on this.

Date: Thu, 28 Feb 2008 10:55:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort          (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to         Proposed Standard
Sender: [email-masked]

Hi Alexey,

--On February 28, 2008 3:29:32 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> SORT is implemented by at least two clients and at least four servers.
>
> SORT is implemented by at least 6 servers, as far as I know:
> <http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.

Well to be fair Dan's point is the utility of SORT for clients. So the real 
question is how many servers AND clients support SORT/THREAD?

Of course the reality is a lot of web-based (PHP) webmail clients use the 
c-client library so get SORT/THREAD "for free". I would guess that there 
are probably more users of those type of clients than there are desktop 
clients implementing SORT/THREAD.

-- 
Cyrus Daboo

Date: Thu, 28 Feb 2008 15:42:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>, Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Dan Karp wrote:

>>> - 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.
>
Thinking more about this: I can see that implementing sorting on CC can 
be more IO-intensive (and possibly more CPU-intensive) than sorting on 
To for a server that caches To header, but doesn't cache CC header.

What are the use cases for sorting on CC?

Date: Thu, 28 Feb 2008 15:29:32 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dan Karp <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 27 Feb 2008, Dan Karp wrote:
>
>>    ... removing the FROM, TO, and CC sorts from the draft and
>>    publishing it as SORT=BASE.  Then any existing server implementation
>>    could advertise both SORT and SORT=BASE, indicating that they
>>    support both the published RFC as well as the 3 deprecated address
>>    sorts.
>
> I see no reason to remove/deprecate the FROM, TO, and CC sorts.
>
> You have presented no reason other than your dislike of their 
> definition. The provision of FROM, TO, and CC sorts in no way blocks 
> future extensions that offer other forms of sorting these (and other 
> fields).
>
> I see abundant reason not to do so.
>
> SORT is implemented by at least two clients and at least four servers. 

SORT is implemented by at least 6 servers, as far as I know: 
<http://www.melnikov.ca/mel/devel/ServerReference.html> + Sun.

> All of these would have to change to support the proposed crippled 
> SORT. Worse, my client would require substantial new, special case 
> code to restore the functionality lost due to crippled SORT; and after 
> this work will have worse performance.

Date: Thu, 28 Feb 2008 14:40:22 +0000
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort  (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

>>  - 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;

+1. It just mean retrieving another header field and processing it in 
the same way as the To header field.

> and removing this may cause a negative impact to something that uses 
> it now.

Date: Wed, 27 Feb 2008 22:54:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Wed, 27 Feb 2008, Dan Karp wrote:
>    ... removing the FROM, TO, and CC sorts from the draft and
>    publishing it as SORT=BASE.  Then any existing server implementation
>    could advertise both SORT and SORT=BASE, indicating that they
>    support both the published RFC as well as the 3 deprecated address
>    sorts.

I see no reason to remove/deprecate the FROM, TO, and CC sorts.

You have presented no reason other than your dislike of their definition. 
The provision of FROM, TO, and CC sorts in no way blocks future extensions 
that offer other forms of sorting these (and other fields).

I see abundant reason not to do so.

SORT is implemented by at least two clients and at least four servers. 
All of these would have to change to support the proposed crippled SORT. 
Worse, my client would require substantial new, special case code to 
restore the functionality lost due to crippled SORT; and after this work 
will have worse performance.

These facilities are harmless, easy to implement as part of SORT, and have 
multiple interoperable implementations.

SORT=BASE, by subsetting SORT, violates section 1 which states that:
    A server which supports the base-level SORT extension indicates this
    with a capability name which starts with "SORT".  Future,
    upwards-compatible extensions to the SORT extension will all start
    with "SORT", indicating support for this base level.

>    A subsequent draft could define SORT=FROM, with [an
>    alternative] algorithm for FROM sorting.

I have no objection to adding new sort keys.  That has been my consistent 
position for many years.

I object strongly to removing existing sort keys.

> The point I was trying to make is that including sort criteria in the
> proposed RFC should be based on client utility, not on whether it's easy
> or hard to add them.

My client has well over a million users worldwide (we have the numbers) 
and uses SORT and THREAD as defined by this specification.

I call that utility.

> And, as you've already stated, "cc sorts are
> extremely rare" and "In practice, To sorts are rare."

The email client world is dominated, overwhelmingly, by Outlook.  I doubt 
that you mean to say that Internet email specifications should be defined 
by, and limited to, by what Outlook uses.

Notwithstanding how often To or cc sorts are used (and From sorts are 
quite commonly used), this is a functionality which has been my client for 
nearly 2 decades.  The original impetus for IMAP SORT over 10 years ago 
was to improve my client's performance by allowing large mailboxes to be 
sorted without having to download ENVELOPEs for every message in the 
mailbox.

> I understand that you don't want to break interop for clients and
> servers that have implemented draft versions of the SORT extension.  The
> SORT=BASE capability should address that issue.

That is completely unacceptable.

Besides creating a situation which is *inferior* for my client, it muddies 
the implementation waters to the point that it becomes less likely that 
any implementation will implement, much less use, SORT in any form.

It is disingenuous to use the term "draft" to describe this specification. 
This specification was approved as a Proposed Standard years ago, but was 
held up in publication because (what is now viewed as a mistake) it was 
felt that no Internet specification should deal with collation until an 
i18n framework was first put in place.

-- 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.

Date: Wed, 27 Feb 2008 16:27:55 -0600
To: Dan Karp <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS   PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 2/27/08 at 11:58 AM -0800, Dan Karp wrote:

>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.

OK, let me do a bit of a process interrupt here:

We're talking about going to Proposed Standard here, and IMO way too 
late. The current SORT *has* been implemented and looks like it may 
be considered useful by some clients. If, after publication, we find 
that it doesn't interoperate reasonably (which may include 
"independent clients don't implement this thing" or "clients can't 
get it right"), we can always go back and make changes. But the fact 
that some clients do a similar operation differently is *not* a 
reason to delay publication.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 27 Feb 2008 14:19:07 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> > But we can't publish a SORT draft in which FROM sorting is as broken
> > as it is in this draft.  We really can't.  It's worse than useless
> > in its present form, and leaving it as-is is significantly worse
> > than just omitting the FROM sort altogether.
> 
> I object to this statement and similar earlier statements.  They are
> needlessly provocative (among other things, Pine and Alpine have used
> and documented these "worse than useless" facilities for nearly 20
> years), and presume that one person's opinions are proven fact in the
> face of contrary opinion.

You're right.  Sorry about that.  I apologize for the inflammatory tone
of my previous remarks, and I'll try not to use such provocative
language going forward.

I think that a FROM sort is important, but I don't feel that many
clients at all will be able to make use of the FROM sort as specified in
revision 19 of the SORT draft.  I realize that it's probably too late in
the process to make substantive tweaks to the sorting algorithms in
SORT.  But I also realize that if a variant of the FROM sort is included
in the published SORT RFC, the probability that a more usable SORT FROM
will ever be published becomes exponentially less likely.

So I think that it's a very good idea that "these issues be punted to
future work in new standards," as you put it.  So I'll again put forth a
kick-the-can-down-the-road proposal:

    ... removing the FROM, TO, and CC sorts from the draft and
    publishing it as SORT=BASE.  Then any existing server implementation
    could advertise both SORT and SORT=BASE, indicating that they
    support both the published RFC as well as the 3 deprecated address
    sorts.  A subsequent draft could define SORT=FROM, with [an
    alternative] algorithm for FROM sorting.

> The implementation convenience in one server does not justify breaking
> a long-term framework that existing implementations depend upon.  It
> especially not removing capabilities that are used by existing
> widely-distributed client implementations.

The point I was trying to make is that including sort criteria in the
proposed RFC should be based on client utility, not on whether it's easy
or hard to add them.  And, as you've already stated, "cc sorts are
extremely rare" and "In practice, To sorts are rare."

I understand that you don't want to break interop for clients and
servers that have implemented draft versions of the SORT extension.  The
SORT=BASE capability should address that issue.

Date: Wed, 27 Feb 2008 13:51:24 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
>>> Perhaps it could be defined as non-strictly-defined
>>> way so that in different countries the sorting could be done differently
>>> based on their local rules.
>> *Shudder*
> That's how the sorting currently works in the world. Each country has
> their own local sorting rules in their phone books etc. Why should we
> force something that's different to what people have been used to?

I didn't shudder in disagreement.  I shuddered because I agree with you!

Or rather, at least to the point that localization rules *are* a critical 
component of such an effort.  The problem is that any situation in which 
l10n comes up is worth a shudder.  l10n is far more frightening than i18n 
or even m17n.

I don't believe that it can be a "non-strictly-defined way", however. 
Rather, I believe that it must be very strictly defined, with the client 
(*not* the server) deciding upon which l10n policy.  Thus, we need 
negotiation of l10n.

This, in turn, suggests that either servers have to know about lots of 
l10n rules for the world, or there needs to be some means by which a 
client can express and upload its l10n rules to the server.

Hopefully at this point you are shuddering too.  l10n is hard!  ;-)

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:42:02 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dan Karp <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
> I don't see a point in breaking a lot of client and server
> implementations that implement the draft in its current form. The draft
> has stayed almost the same for at least 5 years (I implemented it then
> the first time).

Thank you Timo.

>> 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.
> I think these changes should have been discussed long before reaching
> last call. The draft is over 10 years old already!

Thank you for this as well.

Not only is the draft over 10 years old, but it documents functionality 
which is far older.  Pine first offered sorting years before the SORT 
extension was first defined.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:41:14 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Organization: UW Technology
Sender: [email-masked]

On Wed, 27 Feb 2008, Dan Karp wrote:
> But we can't publish a SORT draft in which FROM sorting is as broken as
> it is in this draft.  We really can't.  It's worse than useless in its
> present form, and leaving it as-is is significantly worse than just
> omitting the FROM sort altogether.

I object to this statement and similar earlier statements.  They are 
needlessly provocative (among other things, Pine and Alpine have used and 
documented these "worse than useless" facilities for nearly 20 years), and 
presume that one person's opinions are proven fact in the face of contrary 
opinion.

Furthermore, they disregard multiple interoperable client and server 
implementations that have used the current definitions for over a 
decade.

> Apologies for not commenting sooner.  For my server, implementing
> sorting is sufficiently difficult that I'd decided to permanently skip
> the SORT draft.  But I was just informed that SORT has been made a
> prerequisite for Lemonade, and so I did my first thorough read-through
> of the draft last weekend.

Nothing requires that any client implements SORT.  If you want to define 
and implement an extended SORT, by all means start an effort to get that 
going.

The implementation convenience in one server does not justify breaking a 
long-term framework that existing implementations depend upon.  It 
especially not removing capabilities that are used by existing 
widely-distributed client implementations.

There might be some merit if there was some notable technical difficulty 
in implementing the specification on a server.  But there is not.  The 
ability to generate the IMAP ENVELOPE is required in the base 
specification and consequently all the data needed to implement FROM/TO/CC 
sorting are present.  This isn't a matter of "can not do", it is a matter 
of "not wanting to do."

Any one of us can easily come up with a long list of facilities in 
Internet specifications that we, as individuals, consider "useless" and 
thus should be removed.  However, one person's "useless" feature may be 
another's vitally-important feature.  The time to axe "useless" features 
is when they are first proposed, not when there is over a decade of use 
and deployment (in IMAP; nearly two decades in Pine).

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Wed, 27 Feb 2008 13:12:13 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> > 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 see a
> > point in breaking a lot of client and server > implementations that
> > implement the draft in its current form. The > draft has stayed
> > almost the same for at least 5 years (I implemented > it then the
> > first time).

If you change the CAPABILITY string, nothing should break.

In fact, I'd have no objections to completely removing the FROM, TO, and
CC sorts from the draft and publishing it as SORT=BASE.  Then any
existing server implementation could advertise both SORT and SORT=BASE,
indicating that they support both the published RFC as well as the 3
deprecated address sorts.  A subsequent draft could define SORT=FROM,
with a significantly less broken algorithm for FROM sorting.

But we can't publish a SORT draft in which FROM sorting is as broken as
it is in this draft.  We really can't.  It's worse than useless in its
present form, and leaving it as-is is significantly worse than just
omitting the FROM sort altogether.

> I think these changes should have been discussed long before reaching
> last call. The draft is over 10 years old already!

Apologies for not commenting sooner.  For my server, implementing
sorting is sufficiently difficult that I'd decided to permanently skip
the SORT draft.  But I was just informed that SORT has been made a
prerequisite for Lemonade, and so I did my first thorough read-through
of the draft last weekend.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 22:27:07 +0200
Sender: [email-masked]

--=-B4hxkkVDOEdjxSLSKZbc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 11:22 -0800, Mark Crispin wrote:
> On Wed, 27 Feb 2008, Timo Sirainen wrote:
> > I agree. Such standard could have:
> > - THREAD=3DREFERENCES2 which drops subject merging and changes root nod=
es
> > to be sorted by INTERNALDATE instead of sent-date.
> > - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
> > - FROM/TO/CC-ADDRNAME doing the below:
>=20
> That's why the specification was left with extension capability.  But, as=
=20
> Cyrus points out, there's been a lot of chatter but nothing much coming o=
f=20
> it.

I've implemented X-REFERENCES2, although it's not in a release version
yet. Would be nice to get it standardized.

> > Perhaps it could be defined as non-strictly-defined
> > way so that in different countries the sorting could be done differentl=
y
> > based on their local rules.
>=20
> *Shudder*

That's how the sorting currently works in the world. Each country has
their own local sorting rules in their phone books etc. Why should we
force something that's different to what people have been used to?

> > BTW. What happened to morg list? Wasn't it supposed to talk about these
> > kind of issues? It seemed to die after two weeks (or did I just get
> > unsubscribed..)
>=20
> I've never heard of morg.

It was announced on this list:
http://www.imc.org/ietf-imapext/mail-archive/msg03913.html

--=-B4hxkkVDOEdjxSLSKZbc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-B4hxkkVDOEdjxSLSKZbc--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Dan Karp <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 22:22:56 +0200
Sender: [email-masked]

--=-WM7eiMau096dk+47W2TY
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 11:58 -0800, Dan Karp wrote:
> > The proposed changes in the comments below create significiant=20
> > incompatibilities with multiple interoperable client and server=20
> > implementations that have been in production use and widely
> > distributed worldwide for several years.
> >=20
> > The result of making any of these changes would be instability and=20
> > inconsistency between implementations, creating an environment in
> > which nobody can use these extensions because there is no reliable
> > behavior.
>=20
> 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 see a point in breaking a lot of client and server
implementations that implement the draft in its current form. The draft
has stayed almost the same for at least 5 years (I implemented it then
the first time).

> 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.

I think these changes should have been discussed long before reaching
last call. The draft is over 10 years old already!

--=-WM7eiMau096dk+47W2TY
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WM7eiMau096dk+47W2TY--

Date: Wed, 27 Feb 2008 11:58:43 -0800 (PST)
From: Dan Karp <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> 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 <[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?
> 
> 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.

Date: Wed, 27 Feb 2008 11:22:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Wed, 27 Feb 2008, Timo Sirainen wrote:
> I agree. Such standard could have:
> - THREAD=REFERENCES2 which drops subject merging and changes root nodes
> to be sorted by INTERNALDATE instead of sent-date.
> - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
> - FROM/TO/CC-ADDRNAME doing the below:

That's why the specification was left with extension capability.  But, as 
Cyrus points out, there's been a lot of chatter but nothing much coming of 
it.

>> Sorting the addr-name opens a HUGE can of worms.
> I agree that there's no entirely correct way to do this, but clients
> already do this themselves so a server should be able to do it some way
> as well. I think most people would expect that it sorts in a dummy
> strcasecmp() way.

I have opinions on how such should be specified, but IMHO discussion of 
such is best done at leisure in a pub with large (and infinitely refilled) 
pitchers of beer in front of us.

The very worst place would be inside a formal meeting room at IETF with no 
beer, a time limit, and an assumption that we have to have ONE solution at 
the end.  That will quickly result in some very unhappy people, and 
presently several very angry people.

I have little doubt that the outcome would be the same either way, but in 
the former the people involved would be happy with it.

> Perhaps it could be defined as non-strictly-defined
> way so that in different countries the sorting could be done differently
> based on their local rules.

*Shudder*

> BTW. What happened to morg list? Wasn't it supposed to talk about these
> kind of issues? It seemed to die after two weeks (or did I just get
> unsubscribed..)

I've never heard of morg.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Feb 2008 21:05:25 +0200
Sender: [email-masked]

--=-ShGIGVlVpa1n4OfkniIE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-02-27 at 10:26 -0800, Mark Crispin wrote:
> I recommend that these issues be punted to future work in new standards.

I agree. Such standard could have:

 - THREAD=3DREFERENCES2 which drops subject merging and changes root nodes
to be sorted by INTERNALDATE instead of sent-date.
 - FROM-FULL, TO-FULL, CC-FULL comparing user@domain
 - FROM/TO/CC-ADDRNAME doing the below:

> >  - 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.
>=20
> Sorting the addr-name opens a HUGE can of worms.

I agree that there's no entirely correct way to do this, but clients
already do this themselves so a server should be able to do it some way
as well. I think most people would expect that it sorts in a dummy
strcasecmp() way. Perhaps it could be defined as non-strictly-defined
way so that in different countries the sorting could be done differently
based on their local rules.

BTW. What happened to morg list? Wasn't it supposed to talk about these
kind of issues? It seemed to die after two weeks (or did I just get
unsubscribed..)

--=-ShGIGVlVpa1n4OfkniIE
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-ShGIGVlVpa1n4OfkniIE--

Date: Wed, 27 Feb 2008 13:45:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Dan Karp <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

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

Date: Wed, 27 Feb 2008 10:26:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dan Karp <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

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.

Further comments interspersed below.

On Wed, 27 Feb 2008, Dan Karp wrote:
>
>> 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.

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.

> 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:

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

>  - 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?

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.

>  - 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.

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.

>  - 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.

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

>  - 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.

>  - 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.

-- 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.

Date: Wed, 27 Feb 2008 09:12:50 -0800 (PST)
From: Dan Karp <[email-masked]>
To: [email-masked]
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

> 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sun, 24 Feb 2008 18:57:47 +0200
Sender: [email-masked]

--=-hbvZ7OCv4h8AhHZ2yPeQ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2008-02-24 at 08:36 -0800, Mark Crispin wrote:
> > It doesn't say anything about INTERNALDATE fallbacking here, but it
> > explicitly says that sequence fallbacking is done for broken dates. So
> > based on the text:
> >
> > (4) When sorting roots:
> > - Exact Date: match -> Use sequence comparison
> > - Date: is missing -> Use INTERNALDATE
> > - Date: is broken -> Use INTERNALDATE
> >
> > (6) When sorting non-roots:
> > - Exact Date: match -> Use sequence comparison
> > - Date: is missing -> Unspecified! Does it belong to "can not be
> > parsed" category? Should it fallback to using INTERNALDATE like with
> > (4)?
> > - Date: is broken -> Use sequence comparison
> >
> > UW-IMAP implementation for (6) does:
> >
> > - Exact Date: match -> Use sequence comparison (OK)
> > - Date: is missing -> Uses INTERNALDATE
> > - Date: is broken -> Uses INTERNALDATE (wrong!)
>=20
> There was a long discussion about this.  I believe that the issue was tha=
t=20
> sequence comparison for anything other than exact date match led to an=20
> unresolvable sort.

I agree that it's better to use INTERNALDATE fallbacking for both, but
the draft's text is now clearly wrong and should be changed before
reaching RFC. So something like:

"In case of an exact match on sent date or if either of the Date:
headers used in a comparison can not be parsed, use the same rules as in
step (4)."

--=-hbvZ7OCv4h8AhHZ2yPeQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-hbvZ7OCv4h8AhHZ2yPeQ--

Date: Sun, 24 Feb 2008 08:36:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sun, 24 Feb 2008, Timo Sirainen wrote:
> "(6) Traverse the messages under the root and sort each set of
>          siblings by sent date.  Traverse the messages in such a way
>          that the "youngest" set of siblings are sorted first, and the
>          "oldest" set of siblings are sorted last (grandchildren are
>          sorted before children, etc)."
> I don't understand what the last sentence is trying to say. What does it
> matter in which order the messages are sorted? The result is the same
> anyway. Or does "first" and "last" mean the message order in the sorted
> result or the chronological sorting order?

I'll defer this question to Ken.  That's his text.

> "In the case of an exact match on
>          sent date or if either of the Date: headers used in a
>          comparison can not be parsed, use the order in which the
>          messages appear in the mailbox (that is, by sequence number) to
>          determine the order."
>
> It doesn't say anything about INTERNALDATE fallbacking here, but it
> explicitly says that sequence fallbacking is done for broken dates. So
> based on the text:
>
> (4) When sorting roots:
> - Exact Date: match -> Use sequence comparison
> - Date: is missing -> Use INTERNALDATE
> - Date: is broken -> Use INTERNALDATE
>
> (6) When sorting non-roots:
> - Exact Date: match -> Use sequence comparison
> - Date: is missing -> Unspecified! Does it belong to "can not be
> parsed" category? Should it fallback to using INTERNALDATE like with
> (4)?
> - Date: is broken -> Use sequence comparison
>
> UW-IMAP implementation for (6) does:
>
> - Exact Date: match -> Use sequence comparison (OK)
> - Date: is missing -> Uses INTERNALDATE
> - Date: is broken -> Uses INTERNALDATE (wrong!)

There was a long discussion about this.  I believe that the issue was that 
sequence comparison for anything other than exact date match led to an 
unresolvable sort.

-- 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.

Date: Sun, 24 Feb 2008 08:28:50 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

The full statement is:
             (B) Create a parent/child link between the last reference
             (or NIL if there are no references) and the current message.
             If the current message already has a parent, it is probably
             the result of a truncated References header line, so break
             the current parent/child link before creating the new
             correct one.

The first sentence is absolute; it is always done.  So, to use your 
example below:
 	Go to school.  If today is trash pickup day, take out
 	the trash before going to school.

The ambiguity exists only if the first sentence is absent.

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> "break the current parent/child link before creating the new correct
> one."
>
> What exactly does "before" mean? It's normally used when assuming that
> the rest of the sentence happens, like "take out the trash before going
> to school". What does it mean if it doesn't happen? If I don't go to
> school after all, do I still take out the trash? Or "remove the plastic
> before eating" - do I remove the plastic if I don't eat it? If I don't
> "create the new correct link" because it would loop, do I still "break
> the current parent/child link"? I don't think there's one correct way to
> read the sentence.
>
>

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sun, 24 Feb 2008 14:27:30 +0200
Sender: [email-masked]

--=-/inu2vwcKlwz6rLDsoBj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Two things here:

"(4) Sort the messages under the root (top-level siblings only)
          by sent date.  In the case of an exact match on sent date, use
          the order in which the messages appear in the mailbox (that is,
          by sequence number) to determine the order.
          [..] If the sent date can not
          be determined (a Date: header is missing or can not be parsed),
          the INTERNALDATE for that message is used as the sent date."

"(6) Traverse the messages under the root and sort each set of
          siblings by sent date.  Traverse the messages in such a way
          that the "youngest" set of siblings are sorted first, and the
          "oldest" set of siblings are sorted last (grandchildren are
          sorted before children, etc)."

I don't understand what the last sentence is trying to say. What does it
matter in which order the messages are sorted? The result is the same
anyway. Or does "first" and "last" mean the message order in the sorted
result or the chronological sorting order?

"In the case of an exact match on
          sent date or if either of the Date: headers used in a
          comparison can not be parsed, use the order in which the
          messages appear in the mailbox (that is, by sequence number) to
          determine the order."

It doesn't say anything about INTERNALDATE fallbacking here, but it
explicitly says that sequence fallbacking is done for broken dates. So
based on the text:

(4) When sorting roots:
 - Exact Date: match -> Use sequence comparison
 - Date: is missing -> Use INTERNALDATE
 - Date: is broken -> Use INTERNALDATE

(6) When sorting non-roots:
 - Exact Date: match -> Use sequence comparison
 - Date: is missing -> Unspecified! Does it belong to "can not be
parsed" category? Should it fallback to using INTERNALDATE like with
(4)?
 - Date: is broken -> Use sequence comparison

UW-IMAP implementation for (6) does:

 - Exact Date: match -> Use sequence comparison (OK)
 - Date: is missing -> Uses INTERNALDATE
 - Date: is broken -> Uses INTERNALDATE (wrong!)

--=-/inu2vwcKlwz6rLDsoBj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-/inu2vwcKlwz6rLDsoBj--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 22:59:44 +0200
Sender: [email-masked]

--=-NuKx5odKdBsH/02ApUe0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 22:41 +0200, Timo Sirainen wrote:
> This is how all servers seem to implement it, except Dovecot. I
> originally understood the text to mean:
>=20
> if not is_a_loop(msg, new_parent)
>   if msg->parent !=3D NULL
>     unlink(msg)
>   link(msg, new_parent)

"break the current parent/child link before creating the new correct
one."

What exactly does "before" mean? It's normally used when assuming that
the rest of the sentence happens, like "take out the trash before going
to school". What does it mean if it doesn't happen? If I don't go to
school after all, do I still take out the trash? Or "remove the plastic
before eating" - do I remove the plastic if I don't eat it? If I don't
"create the new correct link" because it would loop, do I still "break
the current parent/child link"? I don't think there's one correct way to
read the sentence.

--=-NuKx5odKdBsH/02ApUe0
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-NuKx5odKdBsH/02ApUe0--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 22:41:55 +0200
Sender: [email-masked]

--=-WW2VMTgyz1cN98Ig/MTN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 11:47 -0800, Mark Crispin wrote:
> On Sat, 23 Feb 2008, Mark Crispin wrote:
> > I wasn't judging whether or not it said it should be done.  In re-readi=
ng=20
> > the description, I don't see how it can be any other way though.
>=20
> In particular, UW imapd does NOT explicitly break the parent->child link=20
> if there is a loop; it just disregards it in that case.  However, implici=
t=20
> behavior from first executing the previous part of that rule is a=20
> different matter.

I suppose we're talking about the same thing. To translate the text to
pseudocode:

if msg->parent !=3D NULL
  unlink(msg)
if not is_a_loop(msg, new_parent)
  link(msg, new_parent)

This is how all servers seem to implement it, except Dovecot. I
originally understood the text to mean:

if not is_a_loop(msg, new_parent)
  if msg->parent !=3D NULL
    unlink(msg)
  link(msg, new_parent)

--=-WW2VMTgyz1cN98Ig/MTN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-WW2VMTgyz1cN98Ig/MTN--

Date: Sat, 23 Feb 2008 11:47:19 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Mark Crispin wrote:
> I wasn't judging whether or not it said it should be done.  In re-reading 
> the description, I don't see how it can be any other way though.

In particular, UW imapd does NOT explicitly break the parent->child link 
if there is a loop; it just disregards it in that case.  However, implicit 
behavior from first executing the previous part of that rule is a 
different matter.

-- 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.

Date: Sat, 23 Feb 2008 11:43:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:
>>> Should the original parent/child link be broken if adding the new one
>>> would introduce a loop? I think this should be clarified in the text.
>> It doesn't say that that should be done; therefore it is not done.
> I think it's ambiguous. And now it's even more ambiguous because you say
> it shouldn't be broken, but your implementation breaks it.

Sorry; I meant to type "IF it doesn't say that should be done; therefore 
it is not done."

I wasn't judging whether or not it said it should be done.  In re-reading 
the description, I don't see how it can be any other way though.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:34:15 +0200
Sender: [email-masked]

--=-51S5e2UQf4WNwrnmbpWC
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 11:29 -0800, Mark Crispin wrote:

> > Should the original parent/child link be broken if adding the new one
> > would introduce a loop? I think this should be clarified in the text.
>=20
> It doesn't say that that should be done; therefore it is not done.

I think it's ambiguous. And now it's even more ambiguous because you say
it shouldn't be broken, but your implementation breaks it.

--=-51S5e2UQf4WNwrnmbpWC
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-51S5e2UQf4WNwrnmbpWC--

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:32:09 +0200
Sender: [email-masked]

--=-RDc1x9P9mO3d7eJzXQFT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2008-02-23 at 21:09 +0200, Timo Sirainen wrote:
> REFERENCES -> (1) -> (B):
>=20
>              If the current message already has a parent, [..], so break
>              the current parent/child link before creating the new
>              correct one.  As in step 1.A, do not create the parent/child
>              link if creating that link would introduce a loop.
>=20
> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

I was pretty sure that it shouldn't have been broken, but looks like
UW-IMAP does break it. Also strictly reading the text I suppose that's
the correct interpretation. So Dovecot has been doing this wrong for
years.

--=-RDc1x9P9mO3d7eJzXQFT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-RDc1x9P9mO3d7eJzXQFT--

Date: Sat, 23 Feb 2008 11:29:43 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: ietf-imapext <[email-masked]>
Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
Sender: [email-masked]

On Sat, 23 Feb 2008, Timo Sirainen wrote:
> But these apply to (B) part as well. Some kind of text restructuring to
> move them to (1) level would make it more logical. But I guess this
> doesn't matter all that much.

It doesn't matter, since (1)(B) results directly from (1)(A) and thus that 
decision has already been made.

> Should the original parent/child link be broken if adding the new one
> would introduce a loop? I think this should be clarified in the text.

It doesn't say that that should be done; therefore it is not done.

It's possible to add an infinite number of "should I do this" that isn't 
stated in the document.  I don't think that we should attempt to 
exhaustively list all the things that should not be done; rather specify 
precisely what should be done.

-- 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.

Subject: Re: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard
From: Timo Sirainen <[email-masked]>
To: ietf-imapext <[email-masked]>
Date: Sat, 23 Feb 2008 21:09:26 +0200
Sender: [email-masked]

--=-g3FaAwKHUFl2sOrbfksf
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

REFERENCES -> (1) -> (A) has:

                If a message does not contain a Message-ID header line,
                or the Message-ID header line does not contain a valid
                Message ID, then assign a unique Message ID to this
                message.

                If two or more messages have the same Message ID, then
                only use that Message ID in the first (lowest sequence
                number) message, and assign a unique Message ID to each
                of the subsequent messages with a duplicate of that
                Message ID.

But these apply to (B) part as well. Some kind of text restructuring to
move them to (1) level would make it more logical. But I guess this
doesn't matter all that much.

REFERENCES -> (1) -> (B):

             If the current message already has a parent, [..], so break
             the current parent/child link before creating the new
             correct one.  As in step 1.A, do not create the parent/child
             link if creating that link would introduce a loop.

Should the original parent/child link be broken if adding the new one
would introduce a loop? I think this should be clarified in the text.

--=-g3FaAwKHUFl2sOrbfksf
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-g3FaAwKHUFl2sOrbfksf--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard 
Date: Tue, 19 Feb 2008 15:29:10 -0800 (PST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-03-04. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-19.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4540&rfc_flag=0

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

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-imapext-sort (INTERNET MESSAGE ACCESS  PROTOCOL - SORT AND THREAD EXTENSIONS) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Tue, 19 Feb 2008 15:29:10 -0800 (PST)
Sender: [email-masked]

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-03-04. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-19.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4540&rfc_flag=0

Date: Wed, 6 Feb 2008 17:18:03 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: IMAP Protocol Interest List <[email-masked]>, IMAP Extensions WG <[email-masked]>
cc: [email-masked]
Subject: IETF no longer accepts free-format Internet-drafts
Organization: Networks & Distributed Computing
Sender: [email-masked]

It seems that a consequence of the IETF's new service provider, it is no 
longer possible to upload a free-format Internet-draft.  Instead of just 
emailing to [email-masked], we're now supposed to use a web page
 	https://datatracker.ietf.org/idst/upload.cgi
which enforces the idnits requirements and spews forth:
 	Pages [sic] is not in numeric format.

Bah, humbug.  Pretty formatting is the RFC Editor's job.  Requiring such 
for drafts is a waste of time.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-imapext-i18n-15.txt 
Date: Fri,  1 Feb 2008 13:30:02 -0800 (PST)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title           : Internet Message Access Protocol Internationalization
	Author(s)       : C. Newman, et al.
	Filename        : draft-ietf-imapext-i18n-15.txt
	Pages           : 19
	Date            : 2008-02-01

Internet Message Access Protocol (IMAP) version 4rev1 has basic
 support for non-ASCII characters in mailbox names and search
 substrings.  It also supports non-ASCII message headers and content
 encoded as specified by Multipurpose Internet Mail Extensions
 (MIME).  This specification defines a collection of IMAP extensions
 which improve international support including comparator negotiation
 for search, sort and thread, language negotiation for international
 error text, and translations for namespace prefixes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-i18n-15.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-imapext-i18n-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-i18n-15.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-i18n-15.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-i18n-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-02-01132606.I-D\@ietf.org>

--OtherAccess--

--NextPart--