On Wed, Feb 27, 2008 at 10:26:44AM -0800,
Mark Crispin [EMAIL PROTECTED] wrote
a message of 162 lines which said:
The actual correct collation, assuming(!) surname-first collation and
Latin character ordering(!!), is:
...
due to where the surname is located in various cultures.
Is it a
Hi Dan,
--On March 2, 2008 11:07:50 PM -0800 Dan Karp [EMAIL PROTECTED] 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
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
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'
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
Stephane Bortzmeyer writes:
On Wed, Feb 27, 2008 at 10:26:44AM -0800,
Mark Crispin [EMAIL PROTECTED] wrote a message of 162 lines which said:
The actual correct collation, assuming(!) surname-first collation
and Latin character ordering(!!), is:
...
due to where the surname is located
On Tue, 4 Mar 2008, Stephane Bortzmeyer wrote:
The actual correct collation, assuming(!) surname-first collation and
Latin character ordering(!!), is:
due to where the surname is located in various cultures.
Is it a good idea to sort on the ordering of the sender's culture? If
the ordering is
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
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
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
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
On Mon Mar 3 15:03:20 2008, Cyrus Daboo wrote:
--On March 2, 2008 11:07:50 PM -0800 Dan Karp [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED]
wrote:
The purpose of sorting in mail clients is so that users can find
messages they're looking for.
Actually
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
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
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
Hi Mark,
--On February 27, 2008 10:26:44 AM -0800 Mark Crispin [EMAIL PROTECTED]
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
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
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
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
On Wed, 2008-02-27 at 11:58 -0800, Dan Karp 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
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
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
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
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
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
26 matches
Mail list logo
