headers
Dan Karp | 3 Mar 2008 08:07
Favicon

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


Let's step back for a moment.

The purpose of sorting in mail clients is so that users can find
messages they're looking for.

After sorting on INTERNALDATE, the user skips down the "Received" column
to the range that their target messages fall in.  And, voila!  The
messages are there.

After sorting on SUBJECT, the user skips through the results to the set
of messages with the correct normalized subject.  This works because the
user mentally normalizes the Subject header in the same way that the
SORT extension does.  (The transform's easy to do, and years of mail
client use have trained them to do this; they're not looking under 'R'
for "re: Your Brains".)  And, voila!  They find the messages.

But sorting on FROM?  That's where things break down for the draft.

I took a look at 7 different mail clients: Gmail, mutt, Outlook Express,
PC-Pine, Thunderbird, Yahoo! Mail, and Zimbra.  In every single one of
these clients, there is a list of mail messages.  And in that list,
every client has a "From" column.  And every one of those "From" columns
contains the RFC2822 display-name of the From header of the relevant
message, or the RFC2822 addr-spec if there's no display-name.  Every
single one.

Gmail ("search, not sort") doesn't allow you to sort on "From".  But
every other client offers a "From" sort.  And every client *but* PC-Pine
does it exactly the same way: A straight text sort on the data displayed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 3 Mar 2008 08:53
Favicon

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


On Sun, 2 Mar 2008, Dan Karp wrote:
> Once the draft makes it to Proposed Standard, getting a second draft out
> with a variant version of these sorts becomes exponentially harder.

When there is both a de facto standard that has existed for over 10 years, 
and a completely incompatible de jure standard created because some guy 
didn't like the de facto standard, then getting any standard becomes 
impossible.

The SORT specification is infinitely extensible.  The original keys are 
there, and remain there forever.  However, nothing prevents the creation 
of FROM2, FROM.PLUS, ZIMBRAFROM, etc. as extensions to the keys.  That is, 
all new forms of SORT would be a superset.

The only thing that a client need concern itself about with a server is if 
the server implements (at least) the SORT level it desires.  If the client 
just cares about the original, 10+ year old, keys, then any server SORT 
will work, because all SORT is a superset of the original.

Should you get your way, there would be now two incompatible sets of keys. 
There would be the set that has been around for more than a decade, and 
the new incompatible set that *subsets* the original set instead of 
*supersets* it.

Clients would have to know which set is implemented by the server.  If the 
server implements the wrong set, then the client will have to do all the 
work in the client.  The end result is sufficient fear, uncertainty, and 
doubt that nobody will use server-based SORT at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 3 Mar 2008 11:40
Favicon

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


Dan:

The draft can't be changed any more.

But there's good news. Like you, I have a database, and I've implemented 
SORT. It took less than a day. A part of those hours was wasted time, 
because as you point out, only Mark's client wants the kind of address 
sorting which the draft offers. But it was less than a day. Wasting 
part of a day isn't really something to get excited about. Worse things 
happen every month.

Arnt
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 3 Mar 2008 12:22
Favicon

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


The IESG 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
>  
>
Hi Mark,
I've just reread section 7 of -19 and found some relatively minor things 
that need fixing:

> 7. Internationalization Considerations
>
>     As stated in the introduction, the server SHOULD support the
>     [IMAP-I18N] COMPARATOR extension and follow its rules to perform
>     collations in the SORT and THREAD extensions.

As per your recent suggestion in the IMAPEXT WG, the COMPARATOR 
extension was renamed to I18NLEVEL=2.
The last sentence in section 1 needs to be updated as well.

>     If the server does not support COMPARATOR, strings MUST be collated
>     according to the i;unicode-casemap collation described in
>     [UNICASEMAP].

I think you also mean that support for at least I18NLEVEL=1 is REQUIREd.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 3 Mar 2008 16:03
Favicon

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


Hi Dan,

--On March 2, 2008 11:07:50 PM -0800 Dan Karp <dkarp <at> zimbra.com> wrote:

> The purpose of sorting in mail clients is so that users can find
> messages they're looking for.

Actually you need to look at your use cases in more detail because a lot of 
times searching is a much better solution than sorting. e.g. the case of 
trying to find email from a particular person - a search is much better. 
Yes you do have to do a little more work to setup the search (type 
something in) rather than the single click sorting requires, but on large 
mailboxes you will usually see what you want immediately without having to 
scroll through the sorted list looking for what you want.

For the most part I question why anyone would really want to sort on any of 
the text fields. The only sort I have found useful is sort by size - and 
then only to help in culling large messages when my quota-limited mailboxes 
get full. The rest of the time I either use no sort, or threading, or view 
filtering (view only the results of a search). View filtering can often be 
done with a single click (e.g. option-click on the from address of a 
message currently in view causes the view to show only those messages with 
that address). This is far superior to sorting. At least that works well 
for me. Others may have different ways of processes their email where 
sorting may make more sense.

--

-- 
Cyrus Daboo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Cridland | 3 Mar 2008 17:14

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

On Mon Mar  3 15:03:20 2008, Cyrus Daboo wrote:
> --On March 2, 2008 11:07:50 PM -0800 Dan Karp <dkarp <at> zimbra.com>  
> wrote:
> 
>> The purpose of sorting in mail clients is so that users can find
>> messages they're looking for.
> 
> Actually you need to look at your use cases in more detail because  
> a lot of times searching is a much better solution than sorting.  
> e.g. the case of trying to find email from a particular person - a  
> search is much better. Yes you do have to do a little more work to  
> setup the search (type something in) rather than the single click  
> sorting requires, but on large mailboxes you will usually see what  
> you want immediately without having to scroll through the sorted  
> list looking for what you want.
> 
> 
I don't think Dan's saying that using SORT for searching is a good  
idea, but it's certainly what people do based on my observations,  
too. (In some clients, the sorted list is scrolled to whichever  
message was previously selected, so it's a fast way of finding other  
messages by the same person).

> For the most part I question why anyone would really want to sort  
> on any of the text fields. The only sort I have found useful is  
> sort by size - and then only to help in culling large messages when  
> my quota-limited mailboxes get full.

My client does no sorting at all, so I'm hard pressed to give any  
alternative use-cases. Generally, people seem to like sorting by date
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 3 Mar 2008 17:23
Favicon

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

Speaking as email client user:

Dave Cridland wrote:

>On Mon Mar  3 15:03:20 2008, Cyrus Daboo wrote:
>  
>
>>--On March 2, 2008 11:07:50 PM -0800 Dan Karp <dkarp <at> zimbra.com>  
>>wrote:
>>    
>>
>>>The purpose of sorting in mail clients is so that users can find
>>>messages they're looking for.
>>>      
>>>
>>Actually you need to look at your use cases in more detail because  
>>a lot of times searching is a much better solution than sorting.  
>>e.g. the case of trying to find email from a particular person - a  
>>search is much better. Yes you do have to do a little more work to  
>>setup the search (type something in) rather than the single click  
>>sorting requires, but on large mailboxes you will usually see what  
>>you want immediately without having to scroll through the sorted  
>>list looking for what you want.
>>    
>>
>I don't think Dan's saying that using SORT for searching is a good  
>idea, but it's certainly what people do based on my observations,  
>too. (In some clients, the sorted list is scrolled to whichever  
>message was previously selected, so it's a fast way of finding other  
>messages by the same person).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 3 Mar 2008 19:27
Favicon

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


I agree and will/have address[ed] these in AUTH48.

On Mon, 3 Mar 2008, Alexey Melnikov wrote:
> The IESG 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
>> 
> Hi Mark,
> I've just reread section 7 of -19 and found some relatively minor things that 
> need fixing:
>
>> 7. Internationalization Considerations
>>
>>     As stated in the introduction, the server SHOULD support the
>>     [IMAP-I18N] COMPARATOR extension and follow its rules to perform
>>     collations in the SORT and THREAD extensions.
>
> As per your recent suggestion in the IMAPEXT WG, the COMPARATOR extension was 
> renamed to I18NLEVEL=2.
> The last sentence in section 1 needs to be updated as well.
>
>>     If the server does not support COMPARATOR, strings MUST be collated
>>     according to the i;unicode-casemap collation described in
>>     [UNICASEMAP].
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 3 Mar 2008 19:44
Favicon

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


On Mon, 3 Mar 2008, Alexey Melnikov wrote:
>> (In some 
>> clients, the sorted list is scrolled to whichever  message was previously 
>> selected, so it's a fast way of finding other  messages by the same 
>> person).
> Yea, I do this frequently in Thunderbird.

As do I.

Note that an address sort that collates all "mrc" messages together is 
more likely to do the right thing that one that collates by name and has 
to figure out that "Mark Crispin", "Mark R. Crispin", "Crispin, Mark", "M 
Crispin", "Mr. Mark Crispin", "IMAP Support", etc. are all the same.

> I frequently sort by subject, because many clients still don't support proper 
> threading (threads can become broken due to lack of the References header).

I also sort by Subject (although more commonly ORDERSUBJECT threading than 
direct SUBJECT sorting) in cases where the thread tree has become so 
complex that it has lost value.  A classic example is when a new thread is 
started by replying to a message in a thread that has little or no 
relationship to the thread.  Think USENET.

> I also sort by IMAP flags (i.e. I want to see all important messages), size 
> and rarely by date.

Usually for flags I would do a filter rather than a SORT, but it seems 
reasonable to me to add such a thing in the first round of extensions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 3 Mar 2008 20:06
Favicon

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


On Mon, 3 Mar 2008, Dave Cridland wrote:
> Still, though, the presence of useless SORT keys would only be a significant 
> problem if they were especially difficult to implement, and the large 
> deployments of SORT indicate that they're not. Even if it's only PINE, that's 
> still a pretty vast number of users who may be relying on this behaviour.

+1.

It amazes me that this is even questioned, much less that the entire 
ietf <at> ietf.org list has been dragged into the fray.  This discussion 
belongs either in ietf-imapext, or if an appeal is to be lodged it should 
be made with the IESG.

-- 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.
Permalink | Reply | 0 comments |

Gmane