headers
Dan Karp | 3 Apr 2007 06:31
Favicon

Re: Expert Review: annotatemore (like WGLC)

> http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt

Comments interspersed btween snippets of the draft:

   Changes from -10 to -11:
   7.   Added match type and collation identifier to the LIST-EXTENDED
        selection option.
   8.   Made support for IMAP-I18N a requirement.

   Text comparisons may be done as part of the GETMETADATA or LIST-
   EXTENDED commands.  As a result, support for the COMPARATOR
   [I-D.ietf-imapext-i18n] extension is REQUIRED.

GETMETADATA doesn't actually do text comparisons, right?  The BNF
doesn't seem to tie in the "matchtype" or "collation" productions.

But more to the point, I believe that the intention was that METADATA
should be a simple, baseline extenstion that will be required by a wide
range of other extensions.  If that's the case, *PLEASE* reconsider the
wisdom of adding the LT, LE, GT, and GE matchers (and thus the
COMPARATOR requirement) to this draft.  It doesn't apear to be core
functionality for METADATA, and since COMPARATOR appears nontrivial to
implement this may not only prevent server authors from implementing
METADATA but also keep us from impelenting any future extension that
requires METADATA.

   A user can only set and retrieve private or shared annotations on a
   mailbox which exists and is returned to them via a LIST or LSUB
   command, irrespective of whether they have read or write access to
   the actual message content of the mailbox.  If the client attempts to
(Continue reading)

Permalink | Reply | 68 comments |
headers
Barry Leiba | 6 Apr 2007 20:38
Picon
Favicon

Re: friends of imap dinner tonight


A little late here, but...

> It was a pleasant dinner.

I'm sure it was, and I'm sorry to've missed it.  Perhaps in future, we 
should make sure that the friends of IMAP and the friends of DKIM 
coordinate, so those of us who have lots of friends can do both.

:-)

Barry
Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 9 Apr 2007 08:50
Favicon

Re: Deprecate IMAP IDLE?

Eric Burger writes:
> Because of this, it was proposed that IMAP NOTIFY would supercede IMAP 
> IDLE, leading to its deprecation.
>
> What do we think of this? As chair, my only care is whether we say it 
> obsoletes RFC 2177 or not.

I think obsoleting 2177 is out of scope for Lemonade. All Lemonade 
can/should do is say things in profile-bis.

Arnt

_______________________________________________
lemonade mailing list
lemonade <at> ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 9 Apr 2007 21:07
Favicon

Re: [lemonade] Expert Review: annotatemore (like WGLC)


Dan Karp wrote:

>>http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-11.txt
>>    
>>
>Comments interspersed btween snippets of the draft:
>  
>
Hi Dan,

>   Changes from -10 to -11:
>   7.   Added match type and collation identifier to the LIST-EXTENDED
>        selection option.
>   8.   Made support for IMAP-I18N a requirement.
>
>   Text comparisons may be done as part of the GETMETADATA or LIST-
>   EXTENDED commands.  As a result, support for the COMPARATOR
>   [I-D.ietf-imapext-i18n] extension is REQUIRED.
>
>GETMETADATA doesn't actually do text comparisons, right?  The BNF
>doesn't seem to tie in the "matchtype" or "collation" productions.
>  
>
Check the <list-select-metadata>, it references both.

>But more to the point, I believe that the intention was that METADATA
>should be a simple, baseline extenstion that will be required by a wide
>range of other extensions.  If that's the case, *PLEASE* reconsider the
>wisdom of adding the LT, LE, GT, and GE matchers (and thus the
(Continue reading)

Permalink | Reply | 62 comments |
headers
Kjetil Torgrim Homme | 11 Apr 2007 07:27
Picon
Picon

SORT on addresses


I came across some grumblings on the info-cyrus mailing list about the
behaviour of SORT with respect to FROM and TO.

[Rob Mueller]:
> It's defined by the IMAP sort extension.
> 
> http://tools.ietf.org/html/draft-ietf-imapext-sort-19
> 
>          FROM
>             [IMAP] addr-mailbox of the first "From" address.
> 
>          TO
>             [IMAP] addr-mailbox of the first "To" address.
> 
> So it really only sorts by the localpart of the email address, not
> even the domain is included, something that's annoyed our users as
> well since you basically end up with UID sorting for the localparts
> that are the same but different domains. That's the "standard"
> though... *sigh*

I was surprised to see this explanation of the behaviour, so I had to
look it up (addr-mailbox being local-part wasn't obvious to me), and
tried to find the justification for it in the archives.

way back in 2004-11-09, Dave Cridland wrote about the mismatch between
SEARCH and SORT (SEARCH looks at the headers verbatim, SORT does
decoding first), and went on to say:

[Dave Cridland]:
(Continue reading)

Permalink | Reply | 507 comments |
headers
Mark Crispin | 12 Apr 2007 03:38

Re: SORT on addresses


On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote:
> it seems to me that this behaviour is mostly useful in "old-skool"
> environments, where username <at> host was common.  e.g., I could be
> kjetilho <at> tag.uio.no, kjetilho <at> hal.uio.no or kjetilho <at> bilbo.uio.no
> depending on which workstation I was logged in that day.  I sincerely
> doubt this is widespread today.

Please be assured that it is still quite common and still very much a fact 
of life for many people.

>      * will end-users think that changing the sort key to be the
>        complete RFC2822 addr-spec (or RFC2822 group) is an improvement?
> my answer is, to the extent they notice it, an emphatic yes.

What surety is there that such is the case?  Your opinion that this is an 
"improvement" has been noted.  That does not constitute research.

>      * is it problematic that current deployments of the draft break
>        wrt compliance?
> my answer is, not really.  this is not a behavioural change which
> affects clients, it only affects the humans who use the clients.

Ahem.

A change in behavior that has been implemented and documented for over a 
decade is quite problematic.

A declaration that software which has been distributed for more than a 
decade is suddenly "non-compliant" is quite problematic.
(Continue reading)

Permalink | Reply | 507 comments |
headers
Timo Sirainen | 12 Apr 2007 10:14
Picon
Picon
Favicon

Re: SORT on addresses

On Wed, 2007-04-11 at 18:38 -0700, Mark Crispin wrote:
> Now, with that said, I would not oppose a SORTEXT proposal that adds new 
> keys (as opposed to changing the current keys) that work as you propose.

If someone starts that, perhaps it could also include REFERENCES2?
http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-December/000322.html

Or maybe I'll just need to write a draft myself some day.
Permalink | Reply | 0 comments |
headers
Dave Cridland | 12 Apr 2007 11:03

Re: SORT on addresses


On Thu Apr 12 02:38:18 2007, Mark Crispin wrote:
> 
> On Wed, 11 Apr 2007, Kjetil Torgrim Homme wrote:
>> it seems to me that this behaviour is mostly useful in "old-skool"
>> environments, where username <at> host was common.  e.g., I could be
>> kjetilho <at> tag.uio.no, kjetilho <at> hal.uio.no or kjetilho <at> bilbo.uio.no
>> depending on which workstation I was logged in that day.  I 
>> sincerely
>> doubt this is widespread today.
> 
> Please be assured that it is still quite common and still very much 
> a fact of life for many people.
> 
> 
It is for you. Not for me, and I suspect that sorting by phrase would 
provide a much more useful method than looking at the address at all.

(For you: mrc <at>  is almost uniformly Mark Crispin, and "SORT (FROM) 
UTF-8 ..." sorts all your mails the "right" way. For me: I'm dave <at>  
for home, and dave.cridland <at>  for work. I'm pretty sure I'm not the 
only dave <at> , too. SORT (FROM) is useless for my mails as a result.)

>>      * will end-users think that changing the sort key to be the
>>        complete RFC2822 addr-spec (or RFC2822 group) is an 
>> improvement?
>> my answer is, to the extent they notice it, an emphatic yes.
> 
> What surety is there that such is the case?  Your opinion that this 
> is an "improvement" has been noted.  That does not constitute
(Continue reading)

Permalink | Reply | 22 comments |
headers
Arnt Gulbrandsen | 12 Apr 2007 12:30
Favicon

Re: SORT on addresses


Dave Cridland writes:
> I spoke to a few people in Prague about IMAP and email, and the 
> general area of searching and managing large quantities of email was 
> raised by several of them, so perhaps the time is right.

Indeed.

> So, here's a counter-proposal:
>
> We setup a mailing list, or at least agree to use an existing one, 
> invite a few UA developers and search-agent people [since we're heavy 
> on the server-side as usual], and start to figure out what's needed, 
> what's practical, and get to work on it. If we seem to be making 
> progress, we turn it into a WG if it seems to suit.
>
> The aim would be to get, or look into:
> - a set of useful SEARCH keys, SORT keys, etc.
> - multimailbox SEARCHing.
> - Inexact searching, such as SCAN provides.
> - Sorting by relevance.
> - probably other search and organizational things. (Perhaps we could 
> stretch to a re-examination of ANNOTATE, or resurrect Alexey's 
> keywords draft - not saying we should do either, but looking into 
> them might be useful).
>
> I have no clear idea if this would be considered IETF or IRTF 
> territory - I suspect it might start out informal, and become 
> formalized in one or other or both.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Murchison | 12 Apr 2007 15:16
Picon

Re: SORT on addresses


Dave Cridland wrote:

> So, here's a counter-proposal:
> 
> We setup a mailing list, or at least agree to use an existing one, 
> invite a few UA developers and search-agent people [since we're heavy on 
> the server-side as usual], and start to figure out what's needed, what's 
> practical, and get to work on it. If we seem to be making progress, we 
> turn it into a WG if it seems to suit.
> 
> The aim would be to get, or look into:
> - a set of useful SEARCH keys, SORT keys, etc.
> - multimailbox SEARCHing.
> - Inexact searching, such as SCAN provides.
> - Sorting by relevance.
> - probably other search and organizational things. (Perhaps we could 
> stretch to a re-examination of ANNOTATE, or resurrect Alexey's keywords 
> draft - not saying we should do either, but looking into them might be 
> useful).
> 
> I have no clear idea if this would be considered IETF or IRTF territory 
> - I suspect it might start out informal, and become formalized in one or 
> other or both.
> 
> Who's willing to participate in something like this?

I would be (speaking for CMU).

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane