Subject: ANNOTATE: possible extra restriction desired
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Date: Tue, 27 Sep 2005 14:09:41 +0200
List-Id: <ietf-imapext.imc.org>

This command isn't legal, as I read the draft:

a store 1 annotation ("/comment" ("value" NIL))

Its purpose would be to delete both the shared and the private comment.

I'd like to hear that others read the draft in the same way. If there's 
any possibility that anyone might read the final RFC differently, I'd 
like a clarification. If everyone agrees that the current language is 
fine, then I'm happy as it is.

Arnt

Date: Mon, 26 Sep 2005 15:18:24 +0100
Subject: Re: ANNOTATE: substring searches on flags
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Sep 26 14:41:12 2005, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
>>> What does this do - seen for seen messages or all of them?
>>> 
>>> a search annotation "/flags/\\seen" "value" "
>> 
>> (Assuming the addition of " at the end, since otherwise it'll 
>> elicit BAD)
> 
> Typo. Sorry.
> 
> 
Yeah, I thought so, I was just being extra-super-picky. :-)

>> The search:
>> 
>> UNSEEN ANNOTATION "/flags/\\seen" "value" ""
>> 
>> will return results if the server uses "0", or will return nothing 
>> if the server uses NIL (or, the absence of that annotation.)
> 
> The way I read it, it should return all seen and all unseen 
> messages, since "" is a substring of both "0" and "1". What's that 
> about NIL, really?
> 
> 
Well, if a flag is not set, then there might not be an annotation.

> I hate /flags/*. That feature raises more questions than it's worth.
> 
> 
The only thing you can use it for is to discover whether a particular 
flag is shared or private.

>>> And for good measure, this nasty one?
>>> 
>>> b search annotation "/flags/*" "*e" ""
>> 
>> Entertaining.
>> 
>> I'd read that as not matching either of "value.priv" or 
>> "value.shared", nor, indeed, any attribute at all.
> 
> Well, it matches all of value, size, content-type and 
> content-language. Something that matches four legal arguments can't 
> very sensibly match nothing at all...
> 
> 
Ah, but "value", "size", "content-type" and "content-language" are 
themselves shorthands for "value.*", etc.

> Now I think I'll go buy my lovely wife a small present. Then, 
> perhaps, I shall have recovered enough to face testing substring 
> matches of the \seen flag's alter-ego annotation's content-type's 
> length.

Good news, you don't have to do substring matches against the string 
representation of the content-type's length, only of the value's 
length. So it's really not as bad as you thought, is it?

Dave.

Date: Mon, 26 Sep 2005 15:41:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: substring searches on flags
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
>> What does this do - seen for seen messages or all of them?
>>
>> a search annotation "/flags/\\seen" "value" "
>
> (Assuming the addition of " at the end, since otherwise it'll elicit BAD)

Typo. Sorry.

> The search:
>
> UNSEEN ANNOTATION "/flags/\\seen" "value" ""
>
> will return results if the server uses "0", or will return nothing if 
> the server uses NIL (or, the absence of that annotation.)

The way I read it, it should return all seen and all unseen messages, 
since "" is a substring of both "0" and "1". What's that about NIL, 
really?

I hate /flags/*. That feature raises more questions than it's worth.

>> And for good measure, this nasty one?
>>
>> b search annotation "/flags/*" "*e" ""
>
> Entertaining.
>
> I'd read that as not matching either of "value.priv" or 
> "value.shared", nor, indeed, any attribute at all.

Well, it matches all of value, size, content-type and content-language. 
Something that matches four legal arguments can't very sensibly match 
nothing at all...

> I also hereby raise my "Don't care" flag - as a client author, I 
> cannot see a use-case for using att-match instead of attrib syntax in 
> searches at all, and even if I did, I wouldn't be searching for 
> anything more than "*".

I implemented search annotation without att-match, and without flag 
substring matches. Otherwise this command would have me sum up all the 
lengths and look for lengths containing the digit 4:

c search annotation "/flags/*" "*" "4"

Now I think I'll go buy my lovely wife a small present. Then, perhaps, I 
shall have recovered enough to face testing substring matches of the 
\seen flag's alter-ego annotation's content-type's length.

Arnt

Date: Mon, 26 Sep 2005 13:53:07 +0100
Subject: Re: ANNOTATE: substring searches on flags
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
> What does this do - seen for seen messages or all of them?
> 
> a search annotation "/flags/\\seen" "value" "
> 
> 
(Assuming the addition of " at the end, since otherwise it'll elicit 
BAD)

Technically, this should list all messages with an annotation 
"/flags/\\seen" which has either a shared or private value. The value 
might be "0" or "1". (Incidentally, bug here in the specification, 
since it states the value might also be "NIL" - should be NIL, 
surely?)

Since the absence of a flag may be indicated with either "0", or the 
absence of the annotation, this search merely tells you which 
messages have an annotation.

The search:

UNSEEN ANNOTATION "/flags/\\seen" "value" ""

will return results if the server uses "0", or will return nothing if 
the server uses NIL (or, the absence of that annotation.)

> And for good measure, this nasty one?
> 
> b search annotation "/flags/*" "*e" ""

Entertaining.

I'd read that as not matching either of "value.priv" or 
"value.shared", nor, indeed, any attribute at all.

I also hereby raise my "Don't care" flag - as a client author, I 
cannot see a use-case for using att-match instead of attrib syntax in 
searches at all, and even if I did, I wouldn't be searching for 
anything more than "*".

Dave.

Date: Mon, 26 Sep 2005 13:27:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: substring searches on flags
Sender: [email-masked]

What does this do - seen for seen messages or all of them?

a search annotation "/flags/\\seen" "value" "

And for good measure, this nasty one?

b search annotation "/flags/*" "*e" ""

Arnt

Date: Sun, 25 Sep 2005 13:43:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE: % and * in search's att-match
Sender: [email-masked]

I keep raising things...

I don't see the point of % and * in att-match (and % is making life hard 
for me).

% and * make sense to me in entry-match, where they work like the same 
wildcards in list-mailbox. However, att-match is different. It doesn't 
have levels of hierarchy since we killed vendor attributes.

Its remaining use is "%.priv" or "*.priv", to search all attributes of 
private annotations only. I hope it won't disappoint anyone, but I 
really don't want to spend brain cells on implementing that.

Arnt

Date: Sun, 25 Sep 2005 13:31:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE fetch response: How to say there aren't any?
Sender: [email-masked]

Cyrus Daboo writes:
> As your example shows, the server simply does not send the ANNOTATION 
> fetch data item. Perhaps that is not ideal and it should return an 
> empty parenthesized list as flags? e.g.:
>
> C: a fetch 1 (flags annotations)
> S: * 1 FETCH (FLAGS () ANNOTATION())
> C: a OK I know you asked for annotations, but there aren't any, so relax, OK?
>
> I can change the syntax and add an example for that, if people agree 
> this is the best way to do it.

I think that's better, because it more closely resembles other parts of FETCH.

Arnt

Date: Sat, 24 Sep 2005 19:15:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE fetch response: How to say there aren't any?
Sender: [email-masked]

Hi,

when there aren't any annotations on a message, what should the 
ANNOTATION part of the FETCH response look like? Unlike FLAGS, the 
returned list cannot be empty.

C: a fetch 1 (flags annotations)
S: * 1 FETCH (FLAGS ())
C: a OK I know you asked for annotations, but there aren't any, so relax, OK?

Arnt

Date: Fri, 23 Sep 2005 10:37:50 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-imap-ext-abnf-04.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: Collected extensions to IMAP4 ABNF
>	Author(s)	: C. Daboo, A. Melnikov
>	Filename	: draft-melnikov-imap-ext-abnf-04.txt
>	Pages		: 0
>	Date		: 2005-9-22
>	
>Over years many documents from IMAPEXT and LEMONADE working groups,
>   as well as many individual documents have added syntactic
>   extensions to many base IMAP commands described in RFC 3501. For
>   ease of reference this document collects most of such ABNF changes
>   in one place.
>   
>   This document updates ABNF in RFC 3501 and RFC 2342.
>  
>
I've just submitted a new revision and the document is almost ready 
(almost, because there are 2 minor open issues) for LC.
I intent to do another revision shortly after the Lemonade interim, at 
which point the document should be ready for LC.

The recent changes are:

   Added ESEARCH response.
   Added search-program from IMAP URL (new draft 
draft-melnikov-rfc2192bis-00.txt now references this document)
   Removed the partition parameter from CREATE/RENAME.
   Added NAMESPACE command/response (fixed few minor ABNF errors).

Alexey

Date: Fri, 23 Sep 2005 10:36:20 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-rfc2192bis-00.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: IMAP URL Scheme
>	Author(s)	: C. Newman, A. Melnikov
>	Filename	: draft-melnikov-rfc2192bis-00.txt
>	Pages		: 19
>	Date		: 2005-9-22
>	
>     IMAP [IMAP4] is a rich protocol for accessing remote message
>     stores.  It provides an ideal mechanism for accessing public mail-
>     ing list archives as well as private and shared message stores.
>     This document defines a URL scheme for referencing objects on an
>     IMAP server.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-melnikov-rfc2192bis-00.txt
>  
>
For your convenience I list the changes below:

     Updated boilerplate, list of editor's, etc.
     Updated references.
     Updated ABNF not to use _, to use SP instead of SPACE.
     Updated example domains to use example.org.
     Fixed ABNF error in "imessagelist" non-terminal.
     Updated ABNF, due to changes in RFC 3501, IMAPABNF and RFC 3986.

Bigger issues like authentication/authorization, mailbox naming scope, 
etc. are still pending.

Alexey

Date: Thu, 22 Sep 2005 08:49:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: why does /flags/\seen exist?
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> I would suggest that those who think the above is poor reasoning

... I am well aware that I'm being a Johnny-come-lately. "Poor 
reasoning" would not justify reopening an issue, IMO, and I didn't mean 
to reopen this. Merely being curious.

Meanwhile, you might want to think about the things Dave and/or I do 
want to change, and ideally say "jolly good idea!" on the list.

Arnt

Date: Thu, 22 Sep 2005 08:40:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: why does /flags/\seen exist?
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Makes sense to me. Thanks.

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ANNOTATE: why does /flags/\seen exist? 
Date: Wed, 21 Sep 2005 22:27:36 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>I just started wondering...

When this was asked after the San Diego IETF, it was noted that without
the /flags/* annotation names, the CONDSTORE extension would need to
duplicate the MODSEQ search criterion to have a version operating on
flags.  Some also felt that an ANNOTATE aware client would prefer to
operate on flags via the annotation names for consistency.

I would suggest that those who think the above is poor reasoning should
review the mailing list archive from immediately after the San Diego
IETF instead of taking my summary as complete.

Philip Guenther

Date: Wed, 21 Sep 2005 19:22:40 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Sep 21 18:44:00 2005, Arnt Gulbrandsen wrote:
> Arnt Gulbrandsen writes:
>> Dave Cridland writes:
>>> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>>>> 1. Writing to an annotation sets all unwritten attributes to 
>>>> nil. That is, if an annotation has content-type and you set a 
>>>> new value, content-type is set to nil. (Ditto: If you set 
>>>> content-type without setting value, value is implicitly set to 
>>>> nil.)
>>> 
>>> If value is NIL, the entry does not exist.
>> 
>> As I read the current draft, the entry exists if at least one 
>> attribte is non-NUL. Anyway, what do you think about my suggestion?
> 
> There is an inconsistency.
> 
> Section 3.2.2 states that storing nil into the "value" attribute 
> deletes the annotation. However, the rest of the draft permits a 
> client to write an annotation whose value afterwards is nil.
> 
> 
I don't see that.

I don't see much clarification saying it's not possible, either.

I do note that STOREs have to be atomic, though, although there's no 
explicit mention of that, either - since STORE can fail because 
ANNOTATE TOOMANY, and that's a per message limit, with no method for 
telling the client either which message failed, nor which suceeded.

Dave.

Date: Wed, 21 Sep 2005 20:09:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: order and so on
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> What could possibly be the benefit in a client doing this?

No idea, and I don't care. My code allows it because the draft does, and 
because it was the simplest way to write the code.

I'll go with whatever the final RFC says.

Arnt

Date: Wed, 21 Sep 2005 18:54:27 +0100
Subject: Re: ANNOTATE: order and so on
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Sep 21 18:22:18 2005, Arnt Gulbrandsen wrote:
> Should it be legal to set a value several times?
> 
> 
No.

> a STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" 
> "fooplus"))?
> 
> b STORE 2 ANNOTATION ("/foo" ("value.priv" "foo") "/foo" 
> ("value.priv" "openfoo"))
> 
> (In my current code it's legal and the rightmost attribute wins.)
> 
> 
What could possibly be the benefit in a client doing this? It just 
looks to me like a bug in the client.

> I don't care whether/how this case is defined, I'm just mentioning 
> it because I think it's been overlooked so far.

Yes, I think so. I think we should copy ACAP's thinking again - you 
can only mention any entry once, and any attribute of that entry once.

So:

A01 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.shared" 
"fooshared"))

is legal, but the following are not:

A02 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo")) ("/foo" 
("value.shared" "fooshared"))
A03 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" 
"fooshared"))
A04 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo")) ("/foo" 
("value.priv" "fooshared"))

It makes it much harder to get a client bug. The reasoning in making 
A02's syntax illegal, even though it's not setting any attribute 
twice, is that it makes spotting the A04 case considerably easier. 
(Or it did for me, when I did this handling in ACAP.)

Dave.

Date: Wed, 21 Sep 2005 19:44:00 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Dave Cridland writes:
>> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>>> 1. Writing to an annotation sets all unwritten attributes to nil. 
>>> That is, if an annotation has content-type and you set a new value, 
>>> content-type is set to nil. (Ditto: If you set content-type without 
>>> setting value, value is implicitly set to nil.)
>>
>> If value is NIL, the entry does not exist.
>
> As I read the current draft, the entry exists if at least one attribte 
> is non-NUL. Anyway, what do you think about my suggestion?

There is an inconsistency.

Section 3.2.2 states that storing nil into the "value" attribute deletes 
the annotation. However, the rest of the draft permits a client to 
write an annotation whose value afterwards is nil.

a STORE 1 ANNOTATION ("/comment" ("value" NIL))
b STORE 1 ANNOTATION ("/comment" ("display-name" "mumble"))
c STORE 1 ANNOTATION ("/comment" ("value" NIL "display-name" "stumble"))

Command a deletes /comment, per section 3.2.2. Command b recreates 
/comment, with a nil value and a non-nil display-name. Command c 
deletes /comment again.

Arnt

Date: Wed, 21 Sep 2005 19:22:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: order and so on
Sender: [email-masked]

Should it be legal to set a value several times?

a STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" "fooplus"))?

b STORE 2 ANNOTATION ("/foo" ("value.priv" "foo") "/foo" ("value.priv" 
"openfoo"))

(In my current code it's legal and the rightmost attribute wins.)

I don't care whether/how this case is defined, I'm just mentioning it 
because I think it's been overlooked so far.

Arnt

Date: Wed, 21 Sep 2005 18:30:20 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: why does /flags/\seen exist?
Sender: [email-masked]

I just started wondering...

Arnt

Date: Tue, 20 Sep 2005 18:19:09 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Date: Tue, 20 Sep 2005 18:17:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> What would the comparator act on? Values whose Content-Type is 
> application/vendor.<name>.dateformat? Or would it be fuzzy and try to 
> extract dates from all text/plain annotations?

Oh. I see.

Effectively, the client would tell the the server «Use comparator foo. 
Ignore the stated content-type of /vendor/microsoft.blah. Assume it has 
the type on which that comparator operates. Search for so-and-so.» 
Right? Is that what you mean?

I could like that. It does rather make a mockery of content-type, but 
IMHO that's content-type's fault.

Arnt

Cc: Cyrus Daboo <[email-masked]>, [email-masked], Philip Guenther <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Chandler stuff (was Re: ANNOTATE: does anyone really want vendor.* attributes?)
Date: Tue, 20 Sep 2005 09:05:26 -0700
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On Sep 20, 2005, at 2:30 AM, Arnt Gulbrandsen wrote:

> Could you talk a little about the types of these?
>
> I am worried that the current type system doesn't fit the task. All of 
> these are text/plain in the current type system, but text/plain 
> doesn't permit things like a server-side search for overdue reminders.
>
> Lisa Dusseault writes:
>> The Chandler requirements: we'd certainly like to be able to annotate 
>> emails so that we could synchronize this kind of information between 
>> two Chandler clients instances:
>>  - what collections an email belongs to (our collections don't always 
>>  map to IMAP folders because of issues like belonging to multiple  
>> collections)
This would be multi-valued text.  In our model collection membership is 
a special case of having a tag.  So I can tag an email as "XMPP-WG" and 
if I have a "XMPP-WG" collection the email shows up in that collection. 
  Later if I decide that now that the XMPP WG is closed down I don't 
need quick access to that in my sidebar, I can remove the collection 
but the tag remains -- I can still recreate that collection or do a 
temporary search/filter for that tag on the emails that were originally 
tagged.  You could certainly argue that this isn't really a collection 
at all but only a tag which happens to have a quick link to a view 
filtered on that tag.

In addition to belonging to multiple collections/tags:
  - emails may belong to no collections or remain untagged
  - collections may not be contained inside collections.
  - items from other repositories (e.g. events from a CalDAV server or 
emails from a different IMAP account) may exist in the same 
collections/tags

Taken together, this is why IMAP folders aren't a good mapping for our 
organization of items. Thus we don't expect IMAP servers to provide 
quick answers to questions like "which items are in the XMPP-WG 
folder".  We'll make use of text searches where we can but fall back on 
simply synchronizing and doing local lookup/indexing.

>>  - an "archived" flag or property (for us an email may not be new, 
>> may  be read, but may or may not be archived yet out of the user's 
>> view)
Probably boolean.

>>  - a reminder on an email (e.g. read this email by Oct 2)
Probably text containing a VALARM sub-component (text from RFC2445) or 
some equivalent.  Again, since not only emails may have reminders but 
also notes, events, tasks, even documents -- the client is expected to 
manage this locally and we don't expect the IMAP server to answer 
questions like "what reminders have to go off in the next hour".  The 
client has to be able to do reminders while offline anyway.  The point 
of making this an annotation at all is synchronization: if I'm running 
Chandler on my laptop and also on my desktop, there's some way to 
create a reminder on one machine and have the other machine able to 
trigger it.  We don't have another easy way of synchronizing this kind 
of metadata.  Of course if servers don't support annotate by the time 
we get near 1.0, we'll have to come up with something else anyway.

Of course if servers could understand the syntax of this annotation and 
provide sensible searches that would be cool too.

>> - other, as-yet-unknown properties to be created by users (e.g. a 
>> "department" property with "IT" and "HR" values)
>
Probably text, and yes the /vendor/osafoundation namespace works great 
for that.

Arnt does that answer the questions?

Lisa

Date: Tue, 20 Sep 2005 17:56:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>> 1. Writing to an annotation sets all unwritten attributes to nil. 
>> That is, if an annotation has content-type and you set a new value, 
>> content-type is set to nil. (Ditto: If you set content-type without 
>> setting value, value is implicitly set to nil.)
>
> If value is NIL, the entry does not exist.

As I read the current draft, the entry exists if at least one attribte 
is non-NUL. Anyway, what do you think about my suggestion?

>> 2. We get a new attribute called "datetime" which stores a date-time 
>> in a specified syntax. IMAP date-time is fine by me, as is RFC3339 
>> syntax. Either now or later, we extend the search command to search 
>> on it.
>
> This I don't like.
>
> This can be done better by defining a comparator.

What would the comparator act on? Values whose Content-Type is 
application/vendor.<name>.dateformat? Or would it be fuzzy and try to 
extract dates from all text/plain annotations?

>> Having display-name, content-language doesn't bother me. They may be 
>> left unused, but they don't actively bother me. The search/size 
>> issue... I'm not sure. Do we need to search on the size?
>
> My problem with display-name is that the only use-case I can think of 
> is for keywords, and you can't store to flag annotations. Unless I 
> can see a use-case for it that actually works in practise, it's just 
> baggage.

Agreed. But as long as the baggage doesn't complicate implementation, I 
don't care much.

Arnt

Date: Tue, 20 Sep 2005 17:42:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> If ANNOTATE's mechanism works, I suggest staying with it.

Since I raised this: The problems I see with content-language are minor. 
If the field is unused, that's not a major problem (four bytes per 
annotation in my case, and perhaps ten lines of dead code). If we adopt 
my suggestion to set all unspecified attributes to nil when an 
annotation is written, we also don't risk content-language going out of 
sync with the annotation value.

Arnt

Date: Tue, 20 Sep 2005 08:35:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Sender: [email-masked]

On Tue, 20 Sep 2005, Dave Cridland wrote:
> Mark, you're the expert here, as I recall - what *is* the situation with 
> Plane 14 et al?

It's moving very slowly.  Part of the problem is that language 
identification turns out to be (surprise!) far more complex than anyone 
can imagine.

If ANNOTATE's mechanism works, I suggest staying with it.

-- 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: Tue, 20 Sep 2005 09:47:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Sender: [email-masked]

Hi Dave,

--On September 20, 2005 2:32:23 PM +0100 Dave Cridland <[email-masked]> 
wrote:

>> 2. We get a new attribute called "datetime" which stores a
>> date-time in a specified syntax. IMAP date-time is fine by me, as
>> is RFC3339 syntax. Either now or later, we extend the search
>> command to search on it.
>>
>>
> This I don't like.
>
> This can be done better by defining a comparator.

Agreed. In fact at one point I was working on defining a date-time 
comparator for use with SIEVE. That got a little too complicated in that 
there were use cases for comparing just the time portion, the day of the 
week etc. For IMAP we could just get by with a plain date test just as 
SEARCH does for the Date: header - that would avoid all the nastiness of 
timezones etc

-- 
Cyrus Daboo

Date: Tue, 20 Sep 2005 14:32:23 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
> 1. Writing to an annotation sets all unwritten attributes to nil. 
> That is, if an annotation has content-type and you set a new value, 
> content-type is set to nil. (Ditto: If you set content-type without 
> setting value, value is implicitly set to nil.)
> 
> 
If value is NIL, the entry does not exist.

> 2. We get a new attribute called "datetime" which stores a 
> date-time in a specified syntax. IMAP date-time is fine by me, as 
> is RFC3339 syntax. Either now or later, we extend the search 
> command to search on it.
> 
> 
This I don't like.

This can be done better by defining a comparator.

> Having display-name, content-language doesn't bother me. They may 
> be left unused, but they don't actively bother me. The search/size 
> issue... I'm not sure. Do we need to search on the size?

My problem with display-name is that the only use-case I can think of 
is for keywords, and you can't store to flag annotations. Unless I 
can see a use-case for it that actually works in practise, it's just 
baggage.

content-language seems to have been superceded by RFC2482, but I 
don't know how widespread support for Plane 14 actually is in 
practise. I found in 
imap://cyrus.andrew.cmu.edu/archive.ietf-acap;UIDVALIDITY=818895118/;uid=1722 
a decision to go with Plane 14 for at least ACAP.

Finally, no, I cannot see a use-case for searching on the string 
representation of size. I can see a use-case for searching using 
"i;ascii-numeric", but comparators aren't supported for ANNOTATION 
searches, or indeed SORTs.

Dave.

Date: Tue, 20 Sep 2005 11:54:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

I'd like to make two suggestions.

1. Writing to an annotation sets all unwritten attributes to nil. That 
is, if an annotation has content-type and you set a new value, 
content-type is set to nil. (Ditto: If you set content-type without 
setting value, value is implicitly set to nil.)

2. We get a new attribute called "datetime" which stores a date-time in 
a specified syntax. IMAP date-time is fine by me, as is RFC3339 syntax. 
Either now or later, we extend the search command to search on it.

These solve my pressing problems.

The potential for content-type confusion and mischief remains, although 
suggestion 1 helps, particularly if the draft calls attention to the 
possible problems.

Having display-name, content-language doesn't bother me. They may be 
left unused, but they don't actively bother me. The search/size 
issue... I'm not sure. Do we need to search on the size?

Arnt

Date: Tue, 20 Sep 2005 11:30:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

(Separate issue, separate message)

Lisa Dusseault writes:
> The Chandler requirements: we'd certainly like to be able to annotate 
> emails so that we could synchronize this kind of information between 
> two Chandler clients instances:
>  - what collections an email belongs to (our collections don't always 
>  map to IMAP folders because of issues like belonging to multiple 
>  collections)
>  - an "archived" flag or property (for us an email may not be new, may 
>  be read, but may or may not be archived yet out of the user's view)
>  - a reminder on an email (e.g. read this email by Oct 2)
> - other, as-yet-unknown properties to be created by users (e.g. a 
> "department" property with "IT" and "HR" values)

Could you talk a little about the types of these?

I am worried that the current type system doesn't fit the task. All of 
these are text/plain in the current type system, but text/plain doesn't 
permit things like a server-side search for overdue reminders.

Arnt

Date: Tue, 20 Sep 2005 10:29:35 +0100
Subject: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

A) Attributes.

I'd just like to review what attributes we have, and state my opinion 
on them. I can live with all of them, incidentally, I'd simply rather 
reduce the number to the bare minimum required for the use-cases we 
have.

1) value

Obviously this is required. :-)

2) size

Although many annotation stores may not have size, it seems pretty 
trivial to extract the data and measure its size on any backend. 
However, note the interesting search problem below.

3) content-type

I'm concerned that usage of content-type means extra round-trips, and 
non-conformant clients can quite easily store a value out of sync 
with the content-type. Equally, Arnt's suggestion that clients may 
well ignore the content-type totally holds.

My inclination is that RFC2046 is not expressive enough to define the 
permissable syntax of value, and where we actually require the 
ability to store multiple different types, use of multiple different 
entries should suffice.

4) content-language

I'm aware of the need for this, although I'd much prefer MLSF or 
Plane 14, either of which solves this problem better, as I understand 
things. (I understand MLSF, I haven't a clue about Plane 14.)

In any case, I do think it's going to be redundant in most cases, 
though, and I wonder whether this couldn't be moved to ANNOTATEMORE. 
If comments are likely to be mixed Chinese and Japanese, say, and no 
tagging mechnism is suitable, then content-language has to stay.

Mark, you're the expert here, as I recall - what *is* the situation 
with Plane 14 et al?

5) display-name

I'm somewhat lost on this. I do think there's a need to store a 
human-readable version of, for instance, the opaque keywords that 
some clients use, but since keywords are defined per-mailbox, it 
seems logical to define their display names per-mailbox, rather than 
per instance.

I might be missing the point totally here, but this attribute seems 
like the right idea in the wrong place. I think this ought to be 
pushed into ANNOTATEMORE.

B) Searching

We need to search "value", that much is obvious. But why do we need 
to perform substring matches for every other attribute? Do we really 
need to know which attributes have a size whose ASCII representation 
includes a digit 4?

Dave.

Date: Tue, 20 Sep 2005 11:21:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> - other, as-yet-unknown properties to be created by users (e.g. a 
> "department" property with "IT" and "HR" values)
>
> We're not opposed to writing internet-drafts if other clients are also 
> interested in reminders, archived flag or collection membership but 
> the last use case simply can't be handled by writing an 
> internet-draft to describe the properties that a user might think to 
> create.  That use case absolutely requires some namespace that's open 
> to creating arbitrary annotation names even on the fly.

I believe /vendor/osafoundation/ is sufficiently open. In general, only 
RFC-blessed annotation entry names are supposed to be used, but within 
/vendor/<IANA-registered>, anything goes. Does this match other 
people's understanding?

Arnt

Date: Mon, 19 Sep 2005 19:29:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Sender: [email-masked]

Hi Rob,

--On September 19, 2005 3:32:25 PM -0700 Rob Siemborski 
<[email-masked]> wrote:

> Getting rid of vendor attributes sounds quite sane to me.

There seems to be general consensus for this, and unless there are any 
objections I will make this change. I was going to push out a new version 
of the draft today (as promised to the WG Chairs), but I want to make this 
change and also see how the other issue (content-type etc) plays out over 
the next day or so, and then submit on Wednesday.

-- 
Cyrus Daboo

Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Date: Mon, 19 Sep 2005 15:41:49 -0700
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

Yes Rob -- thanks for the clarification.

lisa

On Sep 19, 2005, at 3:32 PM, Rob Siemborski wrote:

> On 9/19/05, Lisa Dusseault <[email-masked]> wrote:
>
>> Without the vendor space, is there any way to add attributes without
>> writing Internet-Drafts and bringing to RFC?  Because I can see 
>> several
>> software clients wanting to add custom information (reminders on
>> flagged emails, colour coding for display) without wanting to go to 
>> all
>> that trouble.  If servers supported annotations and *didn't* offer a
>> vendor space (and a way to register vendor names) then we'd see 
>> clients
>> using the normal attribute space and ignore the
>> publication/specification requirements, and that would have its own
>> eventual problems of conflicting attribute names and syntaxes.
>
> We're talking about attributes, not entries, right?
>
> There should definately be a vendor space for entries -- atleast for
> ANNOTATEMORE, vendors are already using it.
>
> I don't see a real need for a vendor space for attributes.
>
>> The Chandler requirements: we'd certainly like to be able to annotate
>> emails so that we could synchronize this kind of information between
>> two Chandler clients instances:
>>   - what collections an email belongs to (our collections don't always
>> map to IMAP folders because of issues like belonging to multiple
>> collections)
>>   - an "archived" flag or property (for us an email may not be new, 
>> may
>> be read, but may or may not be archived yet out of the user's view)
>>   - a reminder on an email (e.g. read this email by Oct 2)
>>   - other, as-yet-unknown properties to be created by users (e.g. a
>> "department" property with "IT" and "HR" values)
>
> These all sound like requirements for entries, not attributes.
>
> Getting rid of vendor attributes sounds quite sane to me.
>
> -Rob
>
> --
> Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
> Software Engineer     |                       |            650-623-6925

Date: Mon, 19 Sep 2005 15:32:25 -0700
From: Rob Siemborski <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On 9/19/05, Lisa Dusseault <[email-masked]> wrote:

> Without the vendor space, is there any way to add attributes without
> writing Internet-Drafts and bringing to RFC?  Because I can see several
> software clients wanting to add custom information (reminders on
> flagged emails, colour coding for display) without wanting to go to all
> that trouble.  If servers supported annotations and *didn't* offer a
> vendor space (and a way to register vendor names) then we'd see clients
> using the normal attribute space and ignore the
> publication/specification requirements, and that would have its own
> eventual problems of conflicting attribute names and syntaxes.

We're talking about attributes, not entries, right?

There should definately be a vendor space for entries -- atleast for
ANNOTATEMORE, vendors are already using it.

I don't see a real need for a vendor space for attributes.

> The Chandler requirements: we'd certainly like to be able to annotate
> emails so that we could synchronize this kind of information between
> two Chandler clients instances:
>   - what collections an email belongs to (our collections don't always
> map to IMAP folders because of issues like belonging to multiple
> collections)
>   - an "archived" flag or property (for us an email may not be new, may
> be read, but may or may not be archived yet out of the user's view)
>   - a reminder on an email (e.g. read this email by Oct 2)
>   - other, as-yet-unknown properties to be created by users (e.g. a
> "department" property with "IT" and "HR" values)

These all sound like requirements for entries, not attributes.

Getting rid of vendor attributes sounds quite sane to me.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Cc: Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Date: Mon, 19 Sep 2005 15:23:05 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Without the vendor space, is there any way to add attributes without 
writing Internet-Drafts and bringing to RFC?  Because I can see several 
software clients wanting to add custom information (reminders on 
flagged emails, colour coding for display) without wanting to go to all 
that trouble.  If servers supported annotations and *didn't* offer a 
vendor space (and a way to register vendor names) then we'd see clients 
using the normal attribute space and ignore the 
publication/specification requirements, and that would have its own 
eventual problems of conflicting attribute names and syntaxes.

That said, I suspect the lack of a vendor space probably wouldn't cause 
too many conflicts in practice -- I don't know anybody who uses more 
than two different email clients to access their IMAP folders (one 
desktop and one treo/palm application is the most I've seen) and only 
one of those is likely to use annotations (the PC client) in the near 
future... so collisions will in fact be rare.  Clients may have to be 
encouraged not to put annotations on emails other than in their own 
account because even the vendor space won't help if two users are using 
the same client and one wants the email to show up as blue and one as 
purple.

The Chandler requirements: we'd certainly like to be able to annotate 
emails so that we could synchronize this kind of information between 
two Chandler clients instances:
  - what collections an email belongs to (our collections don't always 
map to IMAP folders because of issues like belonging to multiple 
collections)
  - an "archived" flag or property (for us an email may not be new, may 
be read, but may or may not be archived yet out of the user's view)
  - a reminder on an email (e.g. read this email by Oct 2)
  - other, as-yet-unknown properties to be created by users (e.g. a 
"department" property with "IT" and "HR" values)

We're not opposed to writing internet-drafts if other clients are also 
interested in reminders, archived flag or collection membership but the 
last use case simply can't be handled by writing an internet-draft to 
describe the properties that a user might think to create.  That use 
case absolutely requires some namespace that's open to creating 
arbitrary annotation names even on the fly.

Lisa

On Sep 19, 2005, at 6:36 AM, Cyrus Daboo wrote:

>
> Hi Philip,
>
> --On September 18, 2005 4:00:54 PM -0700 Philip Guenther 
> <[email-masked]> wrote:
>
>>> They're painful to implement. And tricky.
>>
>> I was about to call them a holdover from ACAP and ask whether anyone
>> had used them there, but after double checking with RFC 2244 I see
>> that isn't true: ACAP doesn't provide for extensions to the set of
>> valid metadata other than revising the base spec.
>>
>> Unless someone can come up with a compelling use-case that can't
>> be handled satisfactorily by placing the data in a (parallel?) entry
>> under the /vendor/ or /<section-part>/vendor/ tree, then we should
>> probably remove vendor.* attributes.
>>
>> Did the authors have something in mind when they were defined?
>>
>
> Flexibility to add additional meta-data that a client may need for its 
> own behaviour. E.g. a client may want to show who authored a 
> particular annotation so might include a 
> 'vendor.example.com.authored_by' attribute that it manages. Of course 
> in  a multi-client environment, custom attributes are likely going to 
> be a problem.
>
> I certainly do not have any specific use cases that I would need 
> vendor attributes for right now. I know that there are a bunch of 
> clients that do a lot more with metadata than I do (e.g. OSAF's 
> Chandler client) - maybe some of those folks could speak to this?
>
> I guess we have three choices:
>
> 1) Keep vendor attributes.
> 2) Remove vendor attributes entirely.
> 3) Allow vendor attributes only on vendor entries.
>
>
> -- 
> Cyrus Daboo
>

Date: Mon, 19 Sep 2005 17:59:26 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Sep 19 16:21:02 2005, Arnt Gulbrandsen wrote:
>> Dave Cridland writes:
>>> Content-Type isn't present in ACAP, and it's never caused a problem 
>>> to me, at least.
>>
>> Could you describe some typical use in ACAP and/or ANNOTATEMORE?
>
> No. :-)

Sorry. I meant some actual use of annotations in ACAP and/or ANNOTATEMORE.

Arnt

Date: Mon, 19 Sep 2005 16:59:15 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Mon Sep 19 16:21:02 2005, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> Moreover, the content-type usually won't be enough - what's the 
>> content-type of the flags? text/plain; charset="utf-8"? Whereas 
>> really, it's much more restrictive than that.
> 
> Right.
> 
> The use-cases I can think of all seem to be 'text/plain', but 
> really something more restrictive. Date-time, numbers, booleans and 
> t/p;f=f covers the use cases I could dream up today. This worries 
> me - having a type system where all the differences are invisible 
> is not good.
> 
> 
Oh, I can think of situations where the data stored in an annotation 
might not be textual in nature.

Consider a client - or even a mailserver - which thumbnails image 
attachments, putting the thumbnail data into an annotation. Done by 
the mailserver, or a LAN-based desktop client, that's pretty 
reasonable, and possibly even useful.

But I'd expect the same image format to be used in all cases.

Now consider a case where a badly written client writes in a 
text/plain comment, but doesn't set the content-type at all. That's 
actually worse than your previous suggestion, because here, the badly 
written client messes up well-written clients.

>> Content-Type isn't present in ACAP, and it's never caused a 
>> problem to me, at least.
> 
> Could you describe some typical use in ACAP and/or ANNOTATEMORE?

No. :-)

As I say, it's not present in ACAP. The meaning of an attribute's 
value is defined by the dataset-class definition, or the base 
specification. Some attribute definitions don't fit the definition of 
text/plain, even when they are textual.

I don't know of any usage of non textual data in ANNOTATEMORE, 
either, although I've not yet implemented this, nor examined the 
deployed usage in great detail.

Dave.

Date: Mon, 19 Sep 2005 17:21:02 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> Moreover, the content-type usually won't be enough - what's the 
> content-type of the flags? text/plain; charset="utf-8"? Whereas 
> really, it's much more restrictive than that.

Right.

The use-cases I can think of all seem to be 'text/plain', but really 
something more restrictive. Date-time, numbers, booleans and t/p;f=f 
covers the use cases I could dream up today. This worries me - having a 
type system where all the differences are invisible is not good.

> Content-Type isn't present in ACAP, and it's never caused a problem to 
> me, at least.

Could you describe some typical use in ACAP and/or ANNOTATEMORE?

Arnt

Date: Mon, 19 Sep 2005 17:04:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> I know that there are a bunch of clients that do a lot more with 
> metadata than I do (e.g. OSAF's Chandler client) - maybe some of 
> those folks could speak to this?

Please.

> I guess we have three choices:
>
> 1) Keep vendor attributes.
> 2) Remove vendor attributes entirely.
> 3) Allow vendor attributes only on vendor entries.

For now I'm not implementing them, and based on what people said in 
Paris, noone else is, either. I can reconsider later, if a good 
use-case or client demand turns up.

(Btw, I don't think a feature whereby like "...authored_by" is a good 
use case. If it's a good idea, then the server should write it based on 
the client's credentials, not based on the client's say-so.)

Arnt

Date: Mon, 19 Sep 2005 16:49:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> Section 3.2.1 clearly limits what can be in the value of anything in 
> /flags hierarchy.

Sure. As long as everyone's well-behaved, there is no problem. But what 
if someone isn't well behaved? For example, what if someone sticks a 
value containing executable content into a blah.shared value?

I see three interesting cases:

1. All other clients dutifully check the type and refuse to read the 
annotation if it doesn't have the expected type.

2. At least one other client checks the type, and reacts to the value as 
that type, ie. it executes the content.

3. All other clients ignore the type, and use the value as though it 
were they type they expect instead of the type they get.

None of this makes me at all happy.

Adding more examples to show that clients should check and handle 
different types doesn't strike me as a real solution. More of a 
band-aid.

What are some use-cases for having user-specified types (as opposed to 
having the type be implied by the entry name)?

Arnt

Date: Mon, 19 Sep 2005 15:42:45 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Mon Sep 19 06:40:07 2005, Cyrus Daboo wrote:
> --On September 18, 2005 7:39:37 PM +0200 Arnt Gulbrandsen 
> <[email-masked]> wrote:
>> It seems more natural to me that the type is bound to the entry 
>> name. Or
>> will anyone really be prepared for /vendor/microsoft/blah to be an
>> image/jpeg instead of the expected text/plain?
> 
> The difference between image/jpeg and image/png may well be 
> significant. i.e. the subtype is perhaps a lot more important.
> 
> 
Yes, but that can be achieved by /vendor/microsoft/blah.png versus 
/vendor.microsoft/blah.jpeg, and the specification for such defining 
which takes precedence.

Moreover, the content-type usually won't be enough - what's the 
content-type of the flags? text/plain; charset="utf-8"? Whereas 
really, it's much more restrictive than that.

Content-Type isn't present in ACAP, and it's never caused a problem 
to me, at least.

>> (I notice that the examples in the draft all fetch the value. They 
>> don't
>> first fetch the type and check that it is the expected type.)
> 
> Maybe we should have examples with different content-types and 
> charsets on text content types.

C: A01 FETCH 1 (ANNOTATION ("/comment" "content-type"))
S: * 1 FETCH (ANNOTATION ("/comment ("content-type.shared" 
"audio/wav" "content-type.priv" "application/ms-word"))
S: A01 OK Completed

As far as I can detirmine, this would be legal with ANNOTATE as it 
stands.

Personally, I'd like to mandate /comment to be 'text/plain; 
charset="utf-8"; format="flowed"', rather than simply noting that 
it's recommended to be text/plain.

Dave.

Date: Mon, 19 Sep 2005 09:40:07 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Sender: [email-masked]

Hi Arnt,

--On September 18, 2005 7:39:37 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> It seems more natural to me that the type is bound to the entry name. Or
> will anyone really be prepared for /vendor/microsoft/blah to be an
> image/jpeg instead of the expected text/plain?

The difference between image/jpeg and image/png may well be significant. 
i.e. the subtype is perhaps a lot more important.

> Or, perhaps more immediately, who'll be prepared for /flags/\seen to be
> an image/jpeg?

Section 3.2.1 clearly limits what can be in the value of anything in /flags 
hierarchy.

> (I notice that the examples in the draft all fetch the value. They don't
> first fetch the type and check that it is the expected type.)

Maybe we should have examples with different content-types and charsets on 
text content types.

-- 
Cyrus Daboo

Date: Mon, 19 Sep 2005 09:36:12 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Sender: [email-masked]

Hi Philip,

--On September 18, 2005 4:00:54 PM -0700 Philip Guenther 
<[email-masked]> wrote:

>> They're painful to implement. And tricky.
>
> I was about to call them a holdover from ACAP and ask whether anyone
> had used them there, but after double checking with RFC 2244 I see
> that isn't true: ACAP doesn't provide for extensions to the set of
> valid metadata other than revising the base spec.
>
> Unless someone can come up with a compelling use-case that can't
> be handled satisfactorily by placing the data in a (parallel?) entry
> under the /vendor/ or /<section-part>/vendor/ tree, then we should
> probably remove vendor.* attributes.
>
> Did the authors have something in mind when they were defined?
>

Flexibility to add additional meta-data that a client may need for its own 
behaviour. E.g. a client may want to show who authored a particular 
annotation so might include a 'vendor.example.com.authored_by' attribute 
that it manages. Of course in  a multi-client environment, custom 
attributes are likely going to be a problem.

I certainly do not have any specific use cases that I would need vendor 
attributes for right now. I know that there are a bunch of clients that do 
a lot more with metadata than I do (e.g. OSAF's Chandler client) - maybe 
some of those folks could speak to this?

I guess we have three choices:

1) Keep vendor attributes.
2) Remove vendor attributes entirely.
3) Allow vendor attributes only on vendor entries.

-- 
Cyrus Daboo

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: LIST (SUBSCRIBED) "" "" 
Date: Sun, 18 Sep 2005 16:46:56 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>What does that do, then? List the subscribed mailboxes, or just return 
>the hierarchy separator?

Neither.  Per pargraph two of section 3, the empty mailbox name is not
treated specially in extended LIST commands.  So, it should only return
an untagged LIST response if the mailbox with the empty name is
subscribed.  I don't know of any servers under which the empty name can
be a valid mailbox, but servers that permit SUBSCRIBE to operate on
names that don't exist may let the client subscribe the name...

Philip Guenther

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Date: Sun, 18 Sep 2005 16:00:54 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>They're painful to implement. And tricky.

I was about to call them a holdover from ACAP and ask whether anyone
had used them there, but after double checking with RFC 2244 I see
that isn't true: ACAP doesn't provide for extensions to the set of
valid metadata other than revising the base spec.

Unless someone can come up with a compelling use-case that can't
be handled satisfactorily by placing the data in a (parallel?) entry
under the /vendor/ or /<section-part>/vendor/ tree, then we should
probably remove vendor.* attributes.

Did the authors have something in mind when they were defined?

Philip Guenther

Date: Sun, 18 Sep 2005 20:07:26 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Sun Sep 18 18:39:37 2005, Arnt Gulbrandsen wrote:
> It seems more natural to me that the type is bound to the entry 
> name. Or will anyone really be prepared for /vendor/microsoft/blah 
> to be an image/jpeg instead of the expected text/plain?
> 
> Or, perhaps more immediately, who'll be prepared for /flags/\seen 
> to be an image/jpeg?
> 
> 
Agreed. The only use-case I can think of is for discovery of what 
vendors have stuck into their own attributes, but that's hardly going 
to be helped, since if the vendors are trying to keep that hidden, 
they can simply lie.

Moreover, dropping attributes to be just value and size helps 
implementations simply back the data onto existing stores. If I were 
writing a server, I'd do exactly this - store annotations in ACAP, 
mapping annotation entries to ACAP attributes, and annotation 
attributes to ACAP metadata. I'm pretty sure this would help for 
backending onto LDAP attributes and WebDAV properties, as well.

Content-Language is the interesting one, because although humans can 
generally guess the language for most human languages quite easily 
(or at least, if they can't, the data is meaningless to them anyway), 
this isn't the case with languages using Chinese ideograms, if I 
recall the discussion from this exact problem in ACAP correctly. I 
seem to recall that Mark Crispin knew most about this subject in 
those days - I'd certainly appreciate knowing if the situation has 
changed.

My gut feel is that for annotations which are human readable, such as 
comments, local convention will effectively dictate the language to 
be used, but for public mailboxes with world-writable shared 
annotations (and I do have a use-case for this), we do need to mark 
the language somehow. My inclination would be to use an ANNOTATEMORE 
annotation on the mailbox for this, however - I think in general, all 
comments in a mailbox are likely to be in a single language.

Dave.

Date: Sun, 18 Sep 2005 19:56:26 +0100
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Sun Sep 18 18:21:59 2005, Arnt Gulbrandsen wrote:
> They're painful to implement. And tricky.

I have no use-case for anything other than value and size, actually.

Dave.

Date: Sun, 18 Sep 2005 19:39:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: annotate: why does each annotation have a type, etc?
Sender: [email-masked]

It seems more natural to me that the type is bound to the entry name. Or 
will anyone really be prepared for /vendor/microsoft/blah to be an 
image/jpeg instead of the expected text/plain?

Or, perhaps more immediately, who'll be prepared for /flags/\seen to be 
an image/jpeg?

(I notice that the examples in the draft all fetch the value. They don't 
first fetch the type and check that it is the expected type.)

Arnt

Date: Sun, 18 Sep 2005 19:21:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: does anyone really want vendor.* attributes?
Sender: [email-masked]

They're painful to implement. And tricky.

Arnt

Date: Fri, 16 Sep 2005 19:50:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: LIST (SUBSCRIBED) "" ""
Sender: [email-masked]

What does that do, then? List the subscribed mailboxes, or just return 
the hierarchy separator?

Arnt

Date: Fri, 16 Sep 2005 19:40:13 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext: remote+recursivematch
Sender: [email-masked]

Recursivematch/childinfo is much nicer to implement than matchparent 
was. I like that change.

However, now I ran into something else. If an IMAP server doesn't offer 
remote mailboxes, then (recursivematch remote) is effectively the same 
as (recursivematch), except that the former is legal and the latter 
prohibited. That doesn't make sense to me, but I don't understand what 
the real problem is.

Arnt

Date: Mon, 05 Sep 2005 14:44:13 +0100
Subject: Re: RECURSIVEMATCH and REMOTE
From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

On Sun Sep  4 23:21:20 2005, Alexey Melnikov wrote:
> Dave Cridland wrote:
>> Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks 
>> for every mailbox.
> 
> 
Ack. Not every mailbox, of course - every mailbox with any children, 
local or remote.

> There is a suggestion in the latest draft to omit redundant 
> CHILDINFO blocks (in section 3.3):
> 
>   Servers SHOULD ONLY return a non-matching mailbox name along with
>   CHILDINFO if at least one matching child is not also being 
> returned.
>   That is, servers SHOULD suppress redundant CHILDINFO responses.
> 
> But a naive implementation will do as you describe.
> 
> 
No, it's not redundant - it's just equivalent to \HasChildren 
attribute.

>> All selection options must indicate in their specification and 
>> registrations whether they operate with RECURSIVEMATCH. REMOTE 
>> indicates that it does not. Therefore, although an implementation 
>> which does not provide remote mailboxes MUST accept REMOTE, it is 
>> treated as a no-op, and a client which issues just REMOTE 
>> RECURSIVEMATCH without any other selection options is in error.
> 
> I am fine with treating REMOTE RECURSIVEMATCH on such servers as an 
> error or noop. I don't care much either way.
> 
> 
No, not just on "such servers", on all servers. On a server which 
does support remote mailboxes, "REMOTE RECURSIVEMATCH" still, 
according to the specification, returns a CHILDINFO (REMOTE) for any 
mailbox which has inferior mailboxes, whether or not any of those 
submailboxes are local or remote.

Dave.

Date: Sun, 04 Sep 2005 23:21:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>
Subject: Re: RECURSIVEMATCH and REMOTE
Sender: [email-masked]

Dave Cridland wrote:

>
> Sorry this is so late... (Explanation below)
>
> The problem:
>
> What exactly should REMOTE with RECURSIVEMATCH actually do?
>
> REMOTE - expands the selection to return both local and remote mailboxes.
>
> RECURSIVEMATCH - adds information about which mailboxes have child 
> mailboxes which match the selection.
>
> Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks for 
> every mailbox.

There is a suggestion in the latest draft to omit redundant CHILDINFO 
blocks (in section 3.3):

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

But a naive implementation will do as you describe.

> Using REMOTE SUBSCRIBED RECURSIVEMATCH is presumably trying to find
> child mailbox which are subscribed, and extending the search to 
> include remote mailboxes - not looking for child mailboxes which are 
> both remote *and* subscribed.
>
> Proposal:
>
> All selection options must indicate in their specification and 
> registrations whether they operate with RECURSIVEMATCH. REMOTE 
> indicates that it does not. Therefore, although an implementation 
> which does not provide remote mailboxes MUST accept REMOTE, it is 
> treated as a no-op, and a client which issues just REMOTE 
> RECURSIVEMATCH without any other selection options is in error.

I am fine with treating REMOTE RECURSIVEMATCH on such servers as an 
error or noop. I don't care much either way.

> Specific Text:
>
> Section 3, para 5 [Starting "A LIST selection option"], add prior to 
> last sentence:
>
> "Some selection options are not affected by RECURSIVEMATCH, this is 
> defined by their specification."
>
> Text in section 3 about REMOTE [Beginning "REMOTE - "] adds this 
> sentence at the end of the first paragraph:
>
> "The REMOTE selection option is ignored for the purposes of 
> RECURSIVEMATCH. However, use of RECURSIVEMATCH and REMOTE will search 
> child mailboxes which are remote as well."
>
> Last sentence of the REMOTE prose gets deleted.
>
> Text in section 3 about RECURSIVEMATCH changes. First pararaph changes 
> to:
>
> "RECURSIVEMATCH - this option forces the server to return information 
> about parent mailboxes which may not match the remaining selection 
> options, but have some submailboxes which match those selection 
> options which are not defined as ignored for the purposes of 
> RECURSIVEMATCH. Information about children is returned in the 
> CHILDINFO extended data item, as described in Section 3.3"
>
> Finally, add something to the IANA template to indicate whether the 
> option is ignored for the purposes of RECURSIVEMATCH.
>
> Comments?

The suggestion is fine with me.

Alexey

Date: Sat, 03 Sep 2005 00:07:56 +0100
Subject: RECURSIVEMATCH and REMOTE
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Sorry this is so late... (Explanation below)

The problem:

What exactly should REMOTE with RECURSIVEMATCH actually do?

REMOTE - expands the selection to return both local and remote 
mailboxes.

RECURSIVEMATCH - adds information about which mailboxes have child 
mailboxes which match the selection.

Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks for 
every mailbox.

Using REMOTE SUBSCRIBED RECURSIVEMATCH is presumably trying to find
child mailbox which are subscribed, and extending the search to 
include remote mailboxes - not looking for child mailboxes which are 
both remote *and* subscribed.

Proposal:

All selection options must indicate in their specification and 
registrations whether they operate with RECURSIVEMATCH. REMOTE 
indicates that it does not. Therefore, although an implementation 
which does not provide remote mailboxes MUST accept REMOTE, it is 
treated as a no-op, and a client which issues just REMOTE 
RECURSIVEMATCH without any other selection options is in error.

Specific Text:

Section 3, para 5 [Starting "A LIST selection option"], add prior to 
last sentence:

"Some selection options are not affected by RECURSIVEMATCH, this is 
defined by their specification."

Text in section 3 about REMOTE [Beginning "REMOTE - "] adds this 
sentence at the end of the first paragraph:

"The REMOTE selection option is ignored for the purposes of 
RECURSIVEMATCH. However, use of RECURSIVEMATCH and REMOTE will search 
child mailboxes which are remote as well."

Last sentence of the REMOTE prose gets deleted.

Text in section 3 about RECURSIVEMATCH changes. First pararaph 
changes to:

"RECURSIVEMATCH - this option forces the server to return information 
about parent mailboxes which may not match the remaining selection 
options, but have some submailboxes which match those selection 
options which are not defined as ignored for the purposes of 
RECURSIVEMATCH. Information about children is returned in the 
CHILDINFO extended data item, as described in Section 3.3"

Finally, add something to the IANA template to indicate whether the 
option is ignored for the purposes of RECURSIVEMATCH.

Comments?

Dave.
-- 
I thought I'd sent some stuff on this issue ages ago, but it seems 
I'd somehow ended up with the wrong email address for the list. 
Probably my typo, since although normally it would get auto captured, 
this mailing list doesn't give List-Post headers. This was somewhat 
compounded by the minor problem that I've broken the addressbook 
editor. So it was a telnet localhost 674 job to fix it.

Date: Tue, 27 Sep 2005 14:09:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: possible extra restriction desired
Sender: [email-masked]

This command isn't legal, as I read the draft:

a store 1 annotation ("/comment" ("value" NIL))

Its purpose would be to delete both the shared and the private comment.

I'd like to hear that others read the draft in the same way. If there's 
any possibility that anyone might read the final RFC differently, I'd 
like a clarification. If everyone agrees that the current language is 
fine, then I'm happy as it is.

Arnt

Date: Mon, 26 Sep 2005 15:18:24 +0100
Subject: Re: ANNOTATE: substring searches on flags
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Sep 26 14:41:12 2005, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
>>> What does this do - seen for seen messages or all of them?
>>> 
>>> a search annotation "/flags/\\seen" "value" "
>> 
>> (Assuming the addition of " at the end, since otherwise it'll 
>> elicit BAD)
> 
> Typo. Sorry.
> 
> 
Yeah, I thought so, I was just being extra-super-picky. :-)

>> The search:
>> 
>> UNSEEN ANNOTATION "/flags/\\seen" "value" ""
>> 
>> will return results if the server uses "0", or will return nothing 
>> if the server uses NIL (or, the absence of that annotation.)
> 
> The way I read it, it should return all seen and all unseen 
> messages, since "" is a substring of both "0" and "1". What's that 
> about NIL, really?
> 
> 
Well, if a flag is not set, then there might not be an annotation.

> I hate /flags/*. That feature raises more questions than it's worth.
> 
> 
The only thing you can use it for is to discover whether a particular 
flag is shared or private.

>>> And for good measure, this nasty one?
>>> 
>>> b search annotation "/flags/*" "*e" ""
>> 
>> Entertaining.
>> 
>> I'd read that as not matching either of "value.priv" or 
>> "value.shared", nor, indeed, any attribute at all.
> 
> Well, it matches all of value, size, content-type and 
> content-language. Something that matches four legal arguments can't 
> very sensibly match nothing at all...
> 
> 
Ah, but "value", "size", "content-type" and "content-language" are 
themselves shorthands for "value.*", etc.

> Now I think I'll go buy my lovely wife a small present. Then, 
> perhaps, I shall have recovered enough to face testing substring 
> matches of the \seen flag's alter-ego annotation's content-type's 
> length.

Good news, you don't have to do substring matches against the string 
representation of the content-type's length, only of the value's 
length. So it's really not as bad as you thought, is it?

Dave.

Date: Mon, 26 Sep 2005 15:41:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: substring searches on flags
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
>> What does this do - seen for seen messages or all of them?
>>
>> a search annotation "/flags/\\seen" "value" "
>
> (Assuming the addition of " at the end, since otherwise it'll elicit BAD)

Typo. Sorry.

> The search:
>
> UNSEEN ANNOTATION "/flags/\\seen" "value" ""
>
> will return results if the server uses "0", or will return nothing if 
> the server uses NIL (or, the absence of that annotation.)

The way I read it, it should return all seen and all unseen messages, 
since "" is a substring of both "0" and "1". What's that about NIL, 
really?

I hate /flags/*. That feature raises more questions than it's worth.

>> And for good measure, this nasty one?
>>
>> b search annotation "/flags/*" "*e" ""
>
> Entertaining.
>
> I'd read that as not matching either of "value.priv" or 
> "value.shared", nor, indeed, any attribute at all.

Well, it matches all of value, size, content-type and content-language. 
Something that matches four legal arguments can't very sensibly match 
nothing at all...

> I also hereby raise my "Don't care" flag - as a client author, I 
> cannot see a use-case for using att-match instead of attrib syntax in 
> searches at all, and even if I did, I wouldn't be searching for 
> anything more than "*".

I implemented search annotation without att-match, and without flag 
substring matches. Otherwise this command would have me sum up all the 
lengths and look for lengths containing the digit 4:

c search annotation "/flags/*" "*" "4"

Now I think I'll go buy my lovely wife a small present. Then, perhaps, I 
shall have recovered enough to face testing substring matches of the 
\seen flag's alter-ego annotation's content-type's length.

Arnt

Date: Mon, 26 Sep 2005 13:53:07 +0100
Subject: Re: ANNOTATE: substring searches on flags
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Mon Sep 26 12:27:22 2005, Arnt Gulbrandsen wrote:
> What does this do - seen for seen messages or all of them?
> 
> a search annotation "/flags/\\seen" "value" "
> 
> 
(Assuming the addition of " at the end, since otherwise it'll elicit 
BAD)

Technically, this should list all messages with an annotation 
"/flags/\\seen" which has either a shared or private value. The value 
might be "0" or "1". (Incidentally, bug here in the specification, 
since it states the value might also be "NIL" - should be NIL, 
surely?)

Since the absence of a flag may be indicated with either "0", or the 
absence of the annotation, this search merely tells you which 
messages have an annotation.

The search:

UNSEEN ANNOTATION "/flags/\\seen" "value" ""

will return results if the server uses "0", or will return nothing if 
the server uses NIL (or, the absence of that annotation.)

> And for good measure, this nasty one?
> 
> b search annotation "/flags/*" "*e" ""

Entertaining.

I'd read that as not matching either of "value.priv" or 
"value.shared", nor, indeed, any attribute at all.

I also hereby raise my "Don't care" flag - as a client author, I 
cannot see a use-case for using att-match instead of attrib syntax in 
searches at all, and even if I did, I wouldn't be searching for 
anything more than "*".

Dave.

Date: Mon, 26 Sep 2005 13:27:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: substring searches on flags
Sender: [email-masked]

What does this do - seen for seen messages or all of them?

a search annotation "/flags/\\seen" "value" "

And for good measure, this nasty one?

b search annotation "/flags/*" "*e" ""

Arnt

Date: Sun, 25 Sep 2005 13:43:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE: % and * in search's att-match
Sender: [email-masked]

I keep raising things...

I don't see the point of % and * in att-match (and % is making life hard 
for me).

% and * make sense to me in entry-match, where they work like the same 
wildcards in list-mailbox. However, att-match is different. It doesn't 
have levels of hierarchy since we killed vendor attributes.

Its remaining use is "%.priv" or "*.priv", to search all attributes of 
private annotations only. I hope it won't disappoint anyone, but I 
really don't want to spend brain cells on implementing that.

Arnt

Date: Sun, 25 Sep 2005 13:31:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE fetch response: How to say there aren't any?
Sender: [email-masked]

Cyrus Daboo writes:
> As your example shows, the server simply does not send the ANNOTATION 
> fetch data item. Perhaps that is not ideal and it should return an 
> empty parenthesized list as flags? e.g.:
>
> C: a fetch 1 (flags annotations)
> S: * 1 FETCH (FLAGS () ANNOTATION())
> C: a OK I know you asked for annotations, but there aren't any, so relax, OK?
>
> I can change the syntax and add an example for that, if people agree 
> this is the best way to do it.

I think that's better, because it more closely resembles other parts of FETCH.

Arnt

Date: Sat, 24 Sep 2005 19:15:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE fetch response: How to say there aren't any?
Sender: [email-masked]

Hi,

when there aren't any annotations on a message, what should the 
ANNOTATION part of the FETCH response look like? Unlike FLAGS, the 
returned list cannot be empty.

C: a fetch 1 (flags annotations)
S: * 1 FETCH (FLAGS ())
C: a OK I know you asked for annotations, but there aren't any, so relax, OK?

Arnt

Date: Fri, 23 Sep 2005 10:37:50 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-imap-ext-abnf-04.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: Collected extensions to IMAP4 ABNF
>	Author(s)	: C. Daboo, A. Melnikov
>	Filename	: draft-melnikov-imap-ext-abnf-04.txt
>	Pages		: 0
>	Date		: 2005-9-22
>	
>Over years many documents from IMAPEXT and LEMONADE working groups,
>   as well as many individual documents have added syntactic
>   extensions to many base IMAP commands described in RFC 3501. For
>   ease of reference this document collects most of such ABNF changes
>   in one place.
>   
>   This document updates ABNF in RFC 3501 and RFC 2342.
>  
>
I've just submitted a new revision and the document is almost ready 
(almost, because there are 2 minor open issues) for LC.
I intent to do another revision shortly after the Lemonade interim, at 
which point the document should be ready for LC.

The recent changes are:

   Added ESEARCH response.
   Added search-program from IMAP URL (new draft 
draft-melnikov-rfc2192bis-00.txt now references this document)
   Removed the partition parameter from CREATE/RENAME.
   Added NAMESPACE command/response (fixed few minor ABNF errors).

Alexey

Date: Fri, 23 Sep 2005 10:36:20 +0100
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-rfc2192bis-00.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: IMAP URL Scheme
>	Author(s)	: C. Newman, A. Melnikov
>	Filename	: draft-melnikov-rfc2192bis-00.txt
>	Pages		: 19
>	Date		: 2005-9-22
>	
>     IMAP [IMAP4] is a rich protocol for accessing remote message
>     stores.  It provides an ideal mechanism for accessing public mail-
>     ing list archives as well as private and shared message stores.
>     This document defines a URL scheme for referencing objects on an
>     IMAP server.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-melnikov-rfc2192bis-00.txt
>  
>
For your convenience I list the changes below:

     Updated boilerplate, list of editor's, etc.
     Updated references.
     Updated ABNF not to use _, to use SP instead of SPACE.
     Updated example domains to use example.org.
     Fixed ABNF error in "imessagelist" non-terminal.
     Updated ABNF, due to changes in RFC 3501, IMAPABNF and RFC 3986.

Bigger issues like authentication/authorization, mailbox naming scope, 
etc. are still pending.

Alexey

Date: Thu, 22 Sep 2005 08:49:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: why does /flags/\seen exist?
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> I would suggest that those who think the above is poor reasoning

... I am well aware that I'm being a Johnny-come-lately. "Poor 
reasoning" would not justify reopening an issue, IMO, and I didn't mean 
to reopen this. Merely being curious.

Meanwhile, you might want to think about the things Dave and/or I do 
want to change, and ideally say "jolly good idea!" on the list.

Arnt

Date: Thu, 22 Sep 2005 08:40:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: why does /flags/\seen exist?
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Makes sense to me. Thanks.

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ANNOTATE: why does /flags/\seen exist? 
Date: Wed, 21 Sep 2005 22:27:36 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>I just started wondering...

When this was asked after the San Diego IETF, it was noted that without
the /flags/* annotation names, the CONDSTORE extension would need to
duplicate the MODSEQ search criterion to have a version operating on
flags.  Some also felt that an ANNOTATE aware client would prefer to
operate on flags via the annotation names for consistency.

I would suggest that those who think the above is poor reasoning should
review the mailing list archive from immediately after the San Diego
IETF instead of taking my summary as complete.

Philip Guenther

Date: Wed, 21 Sep 2005 19:22:40 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Sep 21 18:44:00 2005, Arnt Gulbrandsen wrote:
> Arnt Gulbrandsen writes:
>> Dave Cridland writes:
>>> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>>>> 1. Writing to an annotation sets all unwritten attributes to 
>>>> nil. That is, if an annotation has content-type and you set a 
>>>> new value, content-type is set to nil. (Ditto: If you set 
>>>> content-type without setting value, value is implicitly set to 
>>>> nil.)
>>> 
>>> If value is NIL, the entry does not exist.
>> 
>> As I read the current draft, the entry exists if at least one 
>> attribte is non-NUL. Anyway, what do you think about my suggestion?
> 
> There is an inconsistency.
> 
> Section 3.2.2 states that storing nil into the "value" attribute 
> deletes the annotation. However, the rest of the draft permits a 
> client to write an annotation whose value afterwards is nil.
> 
> 
I don't see that.

I don't see much clarification saying it's not possible, either.

I do note that STOREs have to be atomic, though, although there's no 
explicit mention of that, either - since STORE can fail because 
ANNOTATE TOOMANY, and that's a per message limit, with no method for 
telling the client either which message failed, nor which suceeded.

Dave.

Date: Wed, 21 Sep 2005 20:09:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: order and so on
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> What could possibly be the benefit in a client doing this?

No idea, and I don't care. My code allows it because the draft does, and 
because it was the simplest way to write the code.

I'll go with whatever the final RFC says.

Arnt

Date: Wed, 21 Sep 2005 18:54:27 +0100
Subject: Re: ANNOTATE: order and so on
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Wed Sep 21 18:22:18 2005, Arnt Gulbrandsen wrote:
> Should it be legal to set a value several times?
> 
> 
No.

> a STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" 
> "fooplus"))?
> 
> b STORE 2 ANNOTATION ("/foo" ("value.priv" "foo") "/foo" 
> ("value.priv" "openfoo"))
> 
> (In my current code it's legal and the rightmost attribute wins.)
> 
> 
What could possibly be the benefit in a client doing this? It just 
looks to me like a bug in the client.

> I don't care whether/how this case is defined, I'm just mentioning 
> it because I think it's been overlooked so far.

Yes, I think so. I think we should copy ACAP's thinking again - you 
can only mention any entry once, and any attribute of that entry once.

So:

A01 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.shared" 
"fooshared"))

is legal, but the following are not:

A02 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo")) ("/foo" 
("value.shared" "fooshared"))
A03 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" 
"fooshared"))
A04 STORE 1 ANNOTATION ("/foo" ("value.priv" "foo")) ("/foo" 
("value.priv" "fooshared"))

It makes it much harder to get a client bug. The reasoning in making 
A02's syntax illegal, even though it's not setting any attribute 
twice, is that it makes spotting the A04 case considerably easier. 
(Or it did for me, when I did this handling in ACAP.)

Dave.

Date: Wed, 21 Sep 2005 19:44:00 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> Dave Cridland writes:
>> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>>> 1. Writing to an annotation sets all unwritten attributes to nil. 
>>> That is, if an annotation has content-type and you set a new value, 
>>> content-type is set to nil. (Ditto: If you set content-type without 
>>> setting value, value is implicitly set to nil.)
>>
>> If value is NIL, the entry does not exist.
>
> As I read the current draft, the entry exists if at least one attribte 
> is non-NUL. Anyway, what do you think about my suggestion?

There is an inconsistency.

Section 3.2.2 states that storing nil into the "value" attribute deletes 
the annotation. However, the rest of the draft permits a client to 
write an annotation whose value afterwards is nil.

a STORE 1 ANNOTATION ("/comment" ("value" NIL))
b STORE 1 ANNOTATION ("/comment" ("display-name" "mumble"))
c STORE 1 ANNOTATION ("/comment" ("value" NIL "display-name" "stumble"))

Command a deletes /comment, per section 3.2.2. Command b recreates 
/comment, with a nil value and a non-nil display-name. Command c 
deletes /comment again.

Arnt

Date: Wed, 21 Sep 2005 19:22:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: order and so on
Sender: [email-masked]

Should it be legal to set a value several times?

a STORE 1 ANNOTATION ("/foo" ("value.priv" "foo" "value.priv" "fooplus"))?

b STORE 2 ANNOTATION ("/foo" ("value.priv" "foo") "/foo" ("value.priv" 
"openfoo"))

(In my current code it's legal and the rightmost attribute wins.)

I don't care whether/how this case is defined, I'm just mentioning it 
because I think it's been overlooked so far.

Arnt

Date: Wed, 21 Sep 2005 18:30:20 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: why does /flags/\seen exist?
Sender: [email-masked]

I just started wondering...

Arnt

Date: Tue, 20 Sep 2005 18:19:09 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Date: Tue, 20 Sep 2005 18:17:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
> What would the comparator act on? Values whose Content-Type is 
> application/vendor.<name>.dateformat? Or would it be fuzzy and try to 
> extract dates from all text/plain annotations?

Oh. I see.

Effectively, the client would tell the the server «Use comparator foo. 
Ignore the stated content-type of /vendor/microsoft.blah. Assume it has 
the type on which that comparator operates. Search for so-and-so.» 
Right? Is that what you mean?

I could like that. It does rather make a mockery of content-type, but 
IMHO that's content-type's fault.

Arnt

Cc: Cyrus Daboo <[email-masked]>, [email-masked], Philip Guenther <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Chandler stuff (was Re: ANNOTATE: does anyone really want vendor.* attributes?)
Date: Tue, 20 Sep 2005 09:05:26 -0700
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On Sep 20, 2005, at 2:30 AM, Arnt Gulbrandsen wrote:

> Could you talk a little about the types of these?
>
> I am worried that the current type system doesn't fit the task. All of 
> these are text/plain in the current type system, but text/plain 
> doesn't permit things like a server-side search for overdue reminders.
>
> Lisa Dusseault writes:
>> The Chandler requirements: we'd certainly like to be able to annotate 
>> emails so that we could synchronize this kind of information between 
>> two Chandler clients instances:
>>  - what collections an email belongs to (our collections don't always 
>>  map to IMAP folders because of issues like belonging to multiple  
>> collections)
This would be multi-valued text.  In our model collection membership is 
a special case of having a tag.  So I can tag an email as "XMPP-WG" and 
if I have a "XMPP-WG" collection the email shows up in that collection. 
  Later if I decide that now that the XMPP WG is closed down I don't 
need quick access to that in my sidebar, I can remove the collection 
but the tag remains -- I can still recreate that collection or do a 
temporary search/filter for that tag on the emails that were originally 
tagged.  You could certainly argue that this isn't really a collection 
at all but only a tag which happens to have a quick link to a view 
filtered on that tag.

In addition to belonging to multiple collections/tags:
  - emails may belong to no collections or remain untagged
  - collections may not be contained inside collections.
  - items from other repositories (e.g. events from a CalDAV server or 
emails from a different IMAP account) may exist in the same 
collections/tags

Taken together, this is why IMAP folders aren't a good mapping for our 
organization of items. Thus we don't expect IMAP servers to provide 
quick answers to questions like "which items are in the XMPP-WG 
folder".  We'll make use of text searches where we can but fall back on 
simply synchronizing and doing local lookup/indexing.

>>  - an "archived" flag or property (for us an email may not be new, 
>> may  be read, but may or may not be archived yet out of the user's 
>> view)
Probably boolean.

>>  - a reminder on an email (e.g. read this email by Oct 2)
Probably text containing a VALARM sub-component (text from RFC2445) or 
some equivalent.  Again, since not only emails may have reminders but 
also notes, events, tasks, even documents -- the client is expected to 
manage this locally and we don't expect the IMAP server to answer 
questions like "what reminders have to go off in the next hour".  The 
client has to be able to do reminders while offline anyway.  The point 
of making this an annotation at all is synchronization: if I'm running 
Chandler on my laptop and also on my desktop, there's some way to 
create a reminder on one machine and have the other machine able to 
trigger it.  We don't have another easy way of synchronizing this kind 
of metadata.  Of course if servers don't support annotate by the time 
we get near 1.0, we'll have to come up with something else anyway.

Of course if servers could understand the syntax of this annotation and 
provide sensible searches that would be cool too.

>> - other, as-yet-unknown properties to be created by users (e.g. a 
>> "department" property with "IT" and "HR" values)
>
Probably text, and yes the /vendor/osafoundation namespace works great 
for that.

Arnt does that answer the questions?

Lisa

Date: Tue, 20 Sep 2005 17:56:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
>> 1. Writing to an annotation sets all unwritten attributes to nil. 
>> That is, if an annotation has content-type and you set a new value, 
>> content-type is set to nil. (Ditto: If you set content-type without 
>> setting value, value is implicitly set to nil.)
>
> If value is NIL, the entry does not exist.

As I read the current draft, the entry exists if at least one attribte 
is non-NUL. Anyway, what do you think about my suggestion?

>> 2. We get a new attribute called "datetime" which stores a date-time 
>> in a specified syntax. IMAP date-time is fine by me, as is RFC3339 
>> syntax. Either now or later, we extend the search command to search 
>> on it.
>
> This I don't like.
>
> This can be done better by defining a comparator.

What would the comparator act on? Values whose Content-Type is 
application/vendor.<name>.dateformat? Or would it be fuzzy and try to 
extract dates from all text/plain annotations?

>> Having display-name, content-language doesn't bother me. They may be 
>> left unused, but they don't actively bother me. The search/size 
>> issue... I'm not sure. Do we need to search on the size?
>
> My problem with display-name is that the only use-case I can think of 
> is for keywords, and you can't store to flag annotations. Unless I 
> can see a use-case for it that actually works in practise, it's just 
> baggage.

Agreed. But as long as the baggage doesn't complicate implementation, I 
don't care much.

Arnt

Date: Tue, 20 Sep 2005 17:42:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> If ANNOTATE's mechanism works, I suggest staying with it.

Since I raised this: The problems I see with content-language are minor. 
If the field is unused, that's not a major problem (four bytes per 
annotation in my case, and perhaps ten lines of dead code). If we adopt 
my suggestion to set all unspecified attributes to nil when an 
annotation is written, we also don't risk content-language going out of 
sync with the annotation value.

Arnt

Date: Tue, 20 Sep 2005 08:35:31 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Sender: [email-masked]

On Tue, 20 Sep 2005, Dave Cridland wrote:
> Mark, you're the expert here, as I recall - what *is* the situation with 
> Plane 14 et al?

It's moving very slowly.  Part of the problem is that language 
identification turns out to be (surprise!) far more complex than anyone 
can imagine.

If ANNOTATE's mechanism works, I suggest staying with it.

-- 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: Tue, 20 Sep 2005 09:47:00 -0400
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Sender: [email-masked]

Hi Dave,

--On September 20, 2005 2:32:23 PM +0100 Dave Cridland <[email-masked]> 
wrote:

>> 2. We get a new attribute called "datetime" which stores a
>> date-time in a specified syntax. IMAP date-time is fine by me, as
>> is RFC3339 syntax. Either now or later, we extend the search
>> command to search on it.
>>
>>
> This I don't like.
>
> This can be done better by defining a comparator.

Agreed. In fact at one point I was working on defining a date-time 
comparator for use with SIEVE. That got a little too complicated in that 
there were use cases for comparing just the time portion, the day of the 
week etc. For IMAP we could just get by with a plain date test just as 
SEARCH does for the Date: header - that would avoid all the nastiness of 
timezones etc

-- 
Cyrus Daboo

Date: Tue, 20 Sep 2005 14:32:23 +0100
Subject: Re: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Sep 20 10:54:32 2005, Arnt Gulbrandsen wrote:
> 1. Writing to an annotation sets all unwritten attributes to nil. 
> That is, if an annotation has content-type and you set a new value, 
> content-type is set to nil. (Ditto: If you set content-type without 
> setting value, value is implicitly set to nil.)
> 
> 
If value is NIL, the entry does not exist.

> 2. We get a new attribute called "datetime" which stores a 
> date-time in a specified syntax. IMAP date-time is fine by me, as 
> is RFC3339 syntax. Either now or later, we extend the search 
> command to search on it.
> 
> 
This I don't like.

This can be done better by defining a comparator.

> Having display-name, content-language doesn't bother me. They may 
> be left unused, but they don't actively bother me. The search/size 
> issue... I'm not sure. Do we need to search on the size?

My problem with display-name is that the only use-case I can think of 
is for keywords, and you can't store to flag annotations. Unless I 
can see a use-case for it that actually works in practise, it's just 
baggage.

content-language seems to have been superceded by RFC2482, but I 
don't know how widespread support for Plane 14 actually is in 
practise. I found in 
imap://cyrus.andrew.cmu.edu/archive.ietf-acap;UIDVALIDITY=818895118/;uid=1722 
a decision to go with Plane 14 for at least ACAP.

Finally, no, I cannot see a use-case for searching on the string 
representation of size. I can see a use-case for searching using 
"i;ascii-numeric", but comparators aren't supported for ANNOTATION 
searches, or indeed SORTs.

Dave.

Date: Tue, 20 Sep 2005 11:54:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE attributes and searching
Cc: Dave Cridland <[email-masked]>
Sender: [email-masked]

I'd like to make two suggestions.

1. Writing to an annotation sets all unwritten attributes to nil. That 
is, if an annotation has content-type and you set a new value, 
content-type is set to nil. (Ditto: If you set content-type without 
setting value, value is implicitly set to nil.)

2. We get a new attribute called "datetime" which stores a date-time in 
a specified syntax. IMAP date-time is fine by me, as is RFC3339 syntax. 
Either now or later, we extend the search command to search on it.

These solve my pressing problems.

The potential for content-type confusion and mischief remains, although 
suggestion 1 helps, particularly if the draft calls attention to the 
possible problems.

Having display-name, content-language doesn't bother me. They may be 
left unused, but they don't actively bother me. The search/size 
issue... I'm not sure. Do we need to search on the size?

Arnt

Date: Tue, 20 Sep 2005 11:30:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

(Separate issue, separate message)

Lisa Dusseault writes:
> The Chandler requirements: we'd certainly like to be able to annotate 
> emails so that we could synchronize this kind of information between 
> two Chandler clients instances:
>  - what collections an email belongs to (our collections don't always 
>  map to IMAP folders because of issues like belonging to multiple 
>  collections)
>  - an "archived" flag or property (for us an email may not be new, may 
>  be read, but may or may not be archived yet out of the user's view)
>  - a reminder on an email (e.g. read this email by Oct 2)
> - other, as-yet-unknown properties to be created by users (e.g. a 
> "department" property with "IT" and "HR" values)

Could you talk a little about the types of these?

I am worried that the current type system doesn't fit the task. All of 
these are text/plain in the current type system, but text/plain doesn't 
permit things like a server-side search for overdue reminders.

Arnt

Date: Tue, 20 Sep 2005 10:29:35 +0100
Subject: ANNOTATE attributes and searching
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

A) Attributes.

I'd just like to review what attributes we have, and state my opinion 
on them. I can live with all of them, incidentally, I'd simply rather 
reduce the number to the bare minimum required for the use-cases we 
have.

1) value

Obviously this is required. :-)

2) size

Although many annotation stores may not have size, it seems pretty 
trivial to extract the data and measure its size on any backend. 
However, note the interesting search problem below.

3) content-type

I'm concerned that usage of content-type means extra round-trips, and 
non-conformant clients can quite easily store a value out of sync 
with the content-type. Equally, Arnt's suggestion that clients may 
well ignore the content-type totally holds.

My inclination is that RFC2046 is not expressive enough to define the 
permissable syntax of value, and where we actually require the 
ability to store multiple different types, use of multiple different 
entries should suffice.

4) content-language

I'm aware of the need for this, although I'd much prefer MLSF or 
Plane 14, either of which solves this problem better, as I understand 
things. (I understand MLSF, I haven't a clue about Plane 14.)

In any case, I do think it's going to be redundant in most cases, 
though, and I wonder whether this couldn't be moved to ANNOTATEMORE. 
If comments are likely to be mixed Chinese and Japanese, say, and no 
tagging mechnism is suitable, then content-language has to stay.

Mark, you're the expert here, as I recall - what *is* the situation 
with Plane 14 et al?

5) display-name

I'm somewhat lost on this. I do think there's a need to store a 
human-readable version of, for instance, the opaque keywords that 
some clients use, but since keywords are defined per-mailbox, it 
seems logical to define their display names per-mailbox, rather than 
per instance.

I might be missing the point totally here, but this attribute seems 
like the right idea in the wrong place. I think this ought to be 
pushed into ANNOTATEMORE.

B) Searching

We need to search "value", that much is obvious. But why do we need 
to perform substring matches for every other attribute? Do we really 
need to know which attributes have a size whose ASCII representation 
includes a digit 4?

Dave.

Date: Tue, 20 Sep 2005 11:21:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Lisa Dusseault writes:
> - other, as-yet-unknown properties to be created by users (e.g. a 
> "department" property with "IT" and "HR" values)
>
> We're not opposed to writing internet-drafts if other clients are also 
> interested in reminders, archived flag or collection membership but 
> the last use case simply can't be handled by writing an 
> internet-draft to describe the properties that a user might think to 
> create.  That use case absolutely requires some namespace that's open 
> to creating arbitrary annotation names even on the fly.

I believe /vendor/osafoundation/ is sufficiently open. In general, only 
RFC-blessed annotation entry names are supposed to be used, but within 
/vendor/<IANA-registered>, anything goes. Does this match other 
people's understanding?

Arnt

Date: Mon, 19 Sep 2005 19:29:19 -0400
From: Cyrus Daboo <[email-masked]>
To: Rob Siemborski <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Sender: [email-masked]

Hi Rob,

--On September 19, 2005 3:32:25 PM -0700 Rob Siemborski 
<[email-masked]> wrote:

> Getting rid of vendor attributes sounds quite sane to me.

There seems to be general consensus for this, and unless there are any 
objections I will make this change. I was going to push out a new version 
of the draft today (as promised to the WG Chairs), but I want to make this 
change and also see how the other issue (content-type etc) plays out over 
the next day or so, and then submit on Wednesday.

-- 
Cyrus Daboo

Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Date: Mon, 19 Sep 2005 15:41:49 -0700
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

Yes Rob -- thanks for the clarification.

lisa

On Sep 19, 2005, at 3:32 PM, Rob Siemborski wrote:

> On 9/19/05, Lisa Dusseault <[email-masked]> wrote:
>
>> Without the vendor space, is there any way to add attributes without
>> writing Internet-Drafts and bringing to RFC?  Because I can see 
>> several
>> software clients wanting to add custom information (reminders on
>> flagged emails, colour coding for display) without wanting to go to 
>> all
>> that trouble.  If servers supported annotations and *didn't* offer a
>> vendor space (and a way to register vendor names) then we'd see 
>> clients
>> using the normal attribute space and ignore the
>> publication/specification requirements, and that would have its own
>> eventual problems of conflicting attribute names and syntaxes.
>
> We're talking about attributes, not entries, right?
>
> There should definately be a vendor space for entries -- atleast for
> ANNOTATEMORE, vendors are already using it.
>
> I don't see a real need for a vendor space for attributes.
>
>> The Chandler requirements: we'd certainly like to be able to annotate
>> emails so that we could synchronize this kind of information between
>> two Chandler clients instances:
>>   - what collections an email belongs to (our collections don't always
>> map to IMAP folders because of issues like belonging to multiple
>> collections)
>>   - an "archived" flag or property (for us an email may not be new, 
>> may
>> be read, but may or may not be archived yet out of the user's view)
>>   - a reminder on an email (e.g. read this email by Oct 2)
>>   - other, as-yet-unknown properties to be created by users (e.g. a
>> "department" property with "IT" and "HR" values)
>
> These all sound like requirements for entries, not attributes.
>
> Getting rid of vendor attributes sounds quite sane to me.
>
> -Rob
>
> --
> Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
> Software Engineer     |                       |            650-623-6925

Date: Mon, 19 Sep 2005 15:32:25 -0700
From: Rob Siemborski <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On 9/19/05, Lisa Dusseault <[email-masked]> wrote:

> Without the vendor space, is there any way to add attributes without
> writing Internet-Drafts and bringing to RFC?  Because I can see several
> software clients wanting to add custom information (reminders on
> flagged emails, colour coding for display) without wanting to go to all
> that trouble.  If servers supported annotations and *didn't* offer a
> vendor space (and a way to register vendor names) then we'd see clients
> using the normal attribute space and ignore the
> publication/specification requirements, and that would have its own
> eventual problems of conflicting attribute names and syntaxes.

We're talking about attributes, not entries, right?

There should definately be a vendor space for entries -- atleast for
ANNOTATEMORE, vendors are already using it.

I don't see a real need for a vendor space for attributes.

> The Chandler requirements: we'd certainly like to be able to annotate
> emails so that we could synchronize this kind of information between
> two Chandler clients instances:
>   - what collections an email belongs to (our collections don't always
> map to IMAP folders because of issues like belonging to multiple
> collections)
>   - an "archived" flag or property (for us an email may not be new, may
> be read, but may or may not be archived yet out of the user's view)
>   - a reminder on an email (e.g. read this email by Oct 2)
>   - other, as-yet-unknown properties to be created by users (e.g. a
> "department" property with "IT" and "HR" values)

These all sound like requirements for entries, not attributes.

Getting rid of vendor attributes sounds quite sane to me.

-Rob

--
Rob Siemborski        |     PGP:0x5CE32FCC    |     [email-masked]
Software Engineer     |                       |            650-623-6925

Cc: Philip Guenther <[email-masked]>, [email-masked], Arnt Gulbrandsen <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Date: Mon, 19 Sep 2005 15:23:05 -0700
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Without the vendor space, is there any way to add attributes without 
writing Internet-Drafts and bringing to RFC?  Because I can see several 
software clients wanting to add custom information (reminders on 
flagged emails, colour coding for display) without wanting to go to all 
that trouble.  If servers supported annotations and *didn't* offer a 
vendor space (and a way to register vendor names) then we'd see clients 
using the normal attribute space and ignore the 
publication/specification requirements, and that would have its own 
eventual problems of conflicting attribute names and syntaxes.

That said, I suspect the lack of a vendor space probably wouldn't cause 
too many conflicts in practice -- I don't know anybody who uses more 
than two different email clients to access their IMAP folders (one 
desktop and one treo/palm application is the most I've seen) and only 
one of those is likely to use annotations (the PC client) in the near 
future... so collisions will in fact be rare.  Clients may have to be 
encouraged not to put annotations on emails other than in their own 
account because even the vendor space won't help if two users are using 
the same client and one wants the email to show up as blue and one as 
purple.

The Chandler requirements: we'd certainly like to be able to annotate 
emails so that we could synchronize this kind of information between 
two Chandler clients instances:
  - what collections an email belongs to (our collections don't always 
map to IMAP folders because of issues like belonging to multiple 
collections)
  - an "archived" flag or property (for us an email may not be new, may 
be read, but may or may not be archived yet out of the user's view)
  - a reminder on an email (e.g. read this email by Oct 2)
  - other, as-yet-unknown properties to be created by users (e.g. a 
"department" property with "IT" and "HR" values)

We're not opposed to writing internet-drafts if other clients are also 
interested in reminders, archived flag or collection membership but the 
last use case simply can't be handled by writing an internet-draft to 
describe the properties that a user might think to create.  That use 
case absolutely requires some namespace that's open to creating 
arbitrary annotation names even on the fly.

Lisa

On Sep 19, 2005, at 6:36 AM, Cyrus Daboo wrote:

>
> Hi Philip,
>
> --On September 18, 2005 4:00:54 PM -0700 Philip Guenther 
> <[email-masked]> wrote:
>
>>> They're painful to implement. And tricky.
>>
>> I was about to call them a holdover from ACAP and ask whether anyone
>> had used them there, but after double checking with RFC 2244 I see
>> that isn't true: ACAP doesn't provide for extensions to the set of
>> valid metadata other than revising the base spec.
>>
>> Unless someone can come up with a compelling use-case that can't
>> be handled satisfactorily by placing the data in a (parallel?) entry
>> under the /vendor/ or /<section-part>/vendor/ tree, then we should
>> probably remove vendor.* attributes.
>>
>> Did the authors have something in mind when they were defined?
>>
>
> Flexibility to add additional meta-data that a client may need for its 
> own behaviour. E.g. a client may want to show who authored a 
> particular annotation so might include a 
> 'vendor.example.com.authored_by' attribute that it manages. Of course 
> in  a multi-client environment, custom attributes are likely going to 
> be a problem.
>
> I certainly do not have any specific use cases that I would need 
> vendor attributes for right now. I know that there are a bunch of 
> clients that do a lot more with metadata than I do (e.g. OSAF's 
> Chandler client) - maybe some of those folks could speak to this?
>
> I guess we have three choices:
>
> 1) Keep vendor attributes.
> 2) Remove vendor attributes entirely.
> 3) Allow vendor attributes only on vendor entries.
>
>
> -- 
> Cyrus Daboo
>

Date: Mon, 19 Sep 2005 17:59:26 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> On Mon Sep 19 16:21:02 2005, Arnt Gulbrandsen wrote:
>> Dave Cridland writes:
>>> Content-Type isn't present in ACAP, and it's never caused a problem 
>>> to me, at least.
>>
>> Could you describe some typical use in ACAP and/or ANNOTATEMORE?
>
> No. :-)

Sorry. I meant some actual use of annotations in ACAP and/or ANNOTATEMORE.

Arnt

Date: Mon, 19 Sep 2005 16:59:15 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Mon Sep 19 16:21:02 2005, Arnt Gulbrandsen wrote:
> Dave Cridland writes:
>> Moreover, the content-type usually won't be enough - what's the 
>> content-type of the flags? text/plain; charset="utf-8"? Whereas 
>> really, it's much more restrictive than that.
> 
> Right.
> 
> The use-cases I can think of all seem to be 'text/plain', but 
> really something more restrictive. Date-time, numbers, booleans and 
> t/p;f=f covers the use cases I could dream up today. This worries 
> me - having a type system where all the differences are invisible 
> is not good.
> 
> 
Oh, I can think of situations where the data stored in an annotation 
might not be textual in nature.

Consider a client - or even a mailserver - which thumbnails image 
attachments, putting the thumbnail data into an annotation. Done by 
the mailserver, or a LAN-based desktop client, that's pretty 
reasonable, and possibly even useful.

But I'd expect the same image format to be used in all cases.

Now consider a case where a badly written client writes in a 
text/plain comment, but doesn't set the content-type at all. That's 
actually worse than your previous suggestion, because here, the badly 
written client messes up well-written clients.

>> Content-Type isn't present in ACAP, and it's never caused a 
>> problem to me, at least.
> 
> Could you describe some typical use in ACAP and/or ANNOTATEMORE?

No. :-)

As I say, it's not present in ACAP. The meaning of an attribute's 
value is defined by the dataset-class definition, or the base 
specification. Some attribute definitions don't fit the definition of 
text/plain, even when they are textual.

I don't know of any usage of non textual data in ANNOTATEMORE, 
either, although I've not yet implemented this, nor examined the 
deployed usage in great detail.

Dave.

Date: Mon, 19 Sep 2005 17:21:02 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Dave Cridland writes:
> Moreover, the content-type usually won't be enough - what's the 
> content-type of the flags? text/plain; charset="utf-8"? Whereas 
> really, it's much more restrictive than that.

Right.

The use-cases I can think of all seem to be 'text/plain', but really 
something more restrictive. Date-time, numbers, booleans and t/p;f=f 
covers the use cases I could dream up today. This worries me - having a 
type system where all the differences are invisible is not good.

> Content-Type isn't present in ACAP, and it's never caused a problem to 
> me, at least.

Could you describe some typical use in ACAP and/or ANNOTATEMORE?

Arnt

Date: Mon, 19 Sep 2005 17:04:35 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> I know that there are a bunch of clients that do a lot more with 
> metadata than I do (e.g. OSAF's Chandler client) - maybe some of 
> those folks could speak to this?

Please.

> I guess we have three choices:
>
> 1) Keep vendor attributes.
> 2) Remove vendor attributes entirely.
> 3) Allow vendor attributes only on vendor entries.

For now I'm not implementing them, and based on what people said in 
Paris, noone else is, either. I can reconsider later, if a good 
use-case or client demand turns up.

(Btw, I don't think a feature whereby like "...authored_by" is a good 
use case. If it's a good idea, then the server should write it based on 
the client's credentials, not based on the client's say-so.)

Arnt

Date: Mon, 19 Sep 2005 16:49:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Cc: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Cyrus Daboo writes:
> Section 3.2.1 clearly limits what can be in the value of anything in 
> /flags hierarchy.

Sure. As long as everyone's well-behaved, there is no problem. But what 
if someone isn't well behaved? For example, what if someone sticks a 
value containing executable content into a blah.shared value?

I see three interesting cases:

1. All other clients dutifully check the type and refuse to read the 
annotation if it doesn't have the expected type.

2. At least one other client checks the type, and reacts to the value as 
that type, ie. it executes the content.

3. All other clients ignore the type, and use the value as though it 
were they type they expect instead of the type they get.

None of this makes me at all happy.

Adding more examples to show that clients should check and handle 
different types doesn't strike me as a real solution. More of a 
band-aid.

What are some use-cases for having user-specified types (as opposed to 
having the type be implied by the entry name)?

Arnt

Date: Mon, 19 Sep 2005 15:42:45 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Mon Sep 19 06:40:07 2005, Cyrus Daboo wrote:
> --On September 18, 2005 7:39:37 PM +0200 Arnt Gulbrandsen 
> <[email-masked]> wrote:
>> It seems more natural to me that the type is bound to the entry 
>> name. Or
>> will anyone really be prepared for /vendor/microsoft/blah to be an
>> image/jpeg instead of the expected text/plain?
> 
> The difference between image/jpeg and image/png may well be 
> significant. i.e. the subtype is perhaps a lot more important.
> 
> 
Yes, but that can be achieved by /vendor/microsoft/blah.png versus 
/vendor.microsoft/blah.jpeg, and the specification for such defining 
which takes precedence.

Moreover, the content-type usually won't be enough - what's the 
content-type of the flags? text/plain; charset="utf-8"? Whereas 
really, it's much more restrictive than that.

Content-Type isn't present in ACAP, and it's never caused a problem 
to me, at least.

>> (I notice that the examples in the draft all fetch the value. They 
>> don't
>> first fetch the type and check that it is the expected type.)
> 
> Maybe we should have examples with different content-types and 
> charsets on text content types.

C: A01 FETCH 1 (ANNOTATION ("/comment" "content-type"))
S: * 1 FETCH (ANNOTATION ("/comment ("content-type.shared" 
"audio/wav" "content-type.priv" "application/ms-word"))
S: A01 OK Completed

As far as I can detirmine, this would be legal with ANNOTATE as it 
stands.

Personally, I'd like to mandate /comment to be 'text/plain; 
charset="utf-8"; format="flowed"', rather than simply noting that 
it's recommended to be text/plain.

Dave.

Date: Mon, 19 Sep 2005 09:40:07 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: annotate: why does each annotation have a type, etc?
Sender: [email-masked]

Hi Arnt,

--On September 18, 2005 7:39:37 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

> It seems more natural to me that the type is bound to the entry name. Or
> will anyone really be prepared for /vendor/microsoft/blah to be an
> image/jpeg instead of the expected text/plain?

The difference between image/jpeg and image/png may well be significant. 
i.e. the subtype is perhaps a lot more important.

> Or, perhaps more immediately, who'll be prepared for /flags/\seen to be
> an image/jpeg?

Section 3.2.1 clearly limits what can be in the value of anything in /flags 
hierarchy.

> (I notice that the examples in the draft all fetch the value. They don't
> first fetch the type and check that it is the expected type.)

Maybe we should have examples with different content-types and charsets on 
text content types.

-- 
Cyrus Daboo

Date: Mon, 19 Sep 2005 09:36:12 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Sender: [email-masked]

Hi Philip,

--On September 18, 2005 4:00:54 PM -0700 Philip Guenther 
<[email-masked]> wrote:

>> They're painful to implement. And tricky.
>
> I was about to call them a holdover from ACAP and ask whether anyone
> had used them there, but after double checking with RFC 2244 I see
> that isn't true: ACAP doesn't provide for extensions to the set of
> valid metadata other than revising the base spec.
>
> Unless someone can come up with a compelling use-case that can't
> be handled satisfactorily by placing the data in a (parallel?) entry
> under the /vendor/ or /<section-part>/vendor/ tree, then we should
> probably remove vendor.* attributes.
>
> Did the authors have something in mind when they were defined?
>

Flexibility to add additional meta-data that a client may need for its own 
behaviour. E.g. a client may want to show who authored a particular 
annotation so might include a 'vendor.example.com.authored_by' attribute 
that it manages. Of course in  a multi-client environment, custom 
attributes are likely going to be a problem.

I certainly do not have any specific use cases that I would need vendor 
attributes for right now. I know that there are a bunch of clients that do 
a lot more with metadata than I do (e.g. OSAF's Chandler client) - maybe 
some of those folks could speak to this?

I guess we have three choices:

1) Keep vendor attributes.
2) Remove vendor attributes entirely.
3) Allow vendor attributes only on vendor entries.

-- 
Cyrus Daboo

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: LIST (SUBSCRIBED) "" "" 
Date: Sun, 18 Sep 2005 16:46:56 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>What does that do, then? List the subscribed mailboxes, or just return 
>the hierarchy separator?

Neither.  Per pargraph two of section 3, the empty mailbox name is not
treated specially in extended LIST commands.  So, it should only return
an untagged LIST response if the mailbox with the empty name is
subscribed.  I don't know of any servers under which the empty name can
be a valid mailbox, but servers that permit SUBSCRIBE to operate on
names that don't exist may let the client subscribe the name...

Philip Guenther

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes? 
Date: Sun, 18 Sep 2005 16:00:54 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>They're painful to implement. And tricky.

I was about to call them a holdover from ACAP and ask whether anyone
had used them there, but after double checking with RFC 2244 I see
that isn't true: ACAP doesn't provide for extensions to the set of
valid metadata other than revising the base spec.

Unless someone can come up with a compelling use-case that can't
be handled satisfactorily by placing the data in a (parallel?) entry
under the /vendor/ or /<section-part>/vendor/ tree, then we should
probably remove vendor.* attributes.

Did the authors have something in mind when they were defined?

Philip Guenther

Date: Sun, 18 Sep 2005 20:07:26 +0100
Subject: Re: annotate: why does each annotation have a type, etc?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Sun Sep 18 18:39:37 2005, Arnt Gulbrandsen wrote:
> It seems more natural to me that the type is bound to the entry 
> name. Or will anyone really be prepared for /vendor/microsoft/blah 
> to be an image/jpeg instead of the expected text/plain?
> 
> Or, perhaps more immediately, who'll be prepared for /flags/\seen 
> to be an image/jpeg?
> 
> 
Agreed. The only use-case I can think of is for discovery of what 
vendors have stuck into their own attributes, but that's hardly going 
to be helped, since if the vendors are trying to keep that hidden, 
they can simply lie.

Moreover, dropping attributes to be just value and size helps 
implementations simply back the data onto existing stores. If I were 
writing a server, I'd do exactly this - store annotations in ACAP, 
mapping annotation entries to ACAP attributes, and annotation 
attributes to ACAP metadata. I'm pretty sure this would help for 
backending onto LDAP attributes and WebDAV properties, as well.

Content-Language is the interesting one, because although humans can 
generally guess the language for most human languages quite easily 
(or at least, if they can't, the data is meaningless to them anyway), 
this isn't the case with languages using Chinese ideograms, if I 
recall the discussion from this exact problem in ACAP correctly. I 
seem to recall that Mark Crispin knew most about this subject in 
those days - I'd certainly appreciate knowing if the situation has 
changed.

My gut feel is that for annotations which are human readable, such as 
comments, local convention will effectively dictate the language to 
be used, but for public mailboxes with world-writable shared 
annotations (and I do have a use-case for this), we do need to mark 
the language somehow. My inclination would be to use an ANNOTATEMORE 
annotation on the mailbox for this, however - I think in general, all 
comments in a mailbox are likely to be in a single language.

Dave.

Date: Sun, 18 Sep 2005 19:56:26 +0100
Subject: Re: ANNOTATE: does anyone really want vendor.* attributes?
From: Dave Cridland <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Sun Sep 18 18:21:59 2005, Arnt Gulbrandsen wrote:
> They're painful to implement. And tricky.

I have no use-case for anything other than value and size, actually.

Dave.

Date: Sun, 18 Sep 2005 19:39:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: annotate: why does each annotation have a type, etc?
Sender: [email-masked]

It seems more natural to me that the type is bound to the entry name. Or 
will anyone really be prepared for /vendor/microsoft/blah to be an 
image/jpeg instead of the expected text/plain?

Or, perhaps more immediately, who'll be prepared for /flags/\seen to be 
an image/jpeg?

(I notice that the examples in the draft all fetch the value. They don't 
first fetch the type and check that it is the expected type.)

Arnt

Date: Sun, 18 Sep 2005 19:21:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: ANNOTATE: does anyone really want vendor.* attributes?
Sender: [email-masked]

They're painful to implement. And tricky.

Arnt

Date: Fri, 16 Sep 2005 19:50:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: LIST (SUBSCRIBED) "" ""
Sender: [email-masked]

What does that do, then? List the subscribed mailboxes, or just return 
the hierarchy separator?

Arnt

Date: Fri, 16 Sep 2005 19:40:13 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext: remote+recursivematch
Sender: [email-masked]

Recursivematch/childinfo is much nicer to implement than matchparent 
was. I like that change.

However, now I ran into something else. If an IMAP server doesn't offer 
remote mailboxes, then (recursivematch remote) is effectively the same 
as (recursivematch), except that the former is legal and the latter 
prohibited. That doesn't make sense to me, but I don't understand what 
the real problem is.

Arnt

Date: Mon, 05 Sep 2005 14:44:13 +0100
Subject: Re: RECURSIVEMATCH and REMOTE
From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: <[email-masked]>, Lisa Dusseault <[email-masked]>
Sender: [email-masked]

On Sun Sep  4 23:21:20 2005, Alexey Melnikov wrote:
> Dave Cridland wrote:
>> Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks 
>> for every mailbox.
> 
> 
Ack. Not every mailbox, of course - every mailbox with any children, 
local or remote.

> There is a suggestion in the latest draft to omit redundant 
> CHILDINFO blocks (in section 3.3):
> 
>   Servers SHOULD ONLY return a non-matching mailbox name along with
>   CHILDINFO if at least one matching child is not also being 
> returned.
>   That is, servers SHOULD suppress redundant CHILDINFO responses.
> 
> But a naive implementation will do as you describe.
> 
> 
No, it's not redundant - it's just equivalent to \HasChildren 
attribute.

>> All selection options must indicate in their specification and 
>> registrations whether they operate with RECURSIVEMATCH. REMOTE 
>> indicates that it does not. Therefore, although an implementation 
>> which does not provide remote mailboxes MUST accept REMOTE, it is 
>> treated as a no-op, and a client which issues just REMOTE 
>> RECURSIVEMATCH without any other selection options is in error.
> 
> I am fine with treating REMOTE RECURSIVEMATCH on such servers as an 
> error or noop. I don't care much either way.
> 
> 
No, not just on "such servers", on all servers. On a server which 
does support remote mailboxes, "REMOTE RECURSIVEMATCH" still, 
according to the specification, returns a CHILDINFO (REMOTE) for any 
mailbox which has inferior mailboxes, whether or not any of those 
submailboxes are local or remote.

Dave.

Date: Sun, 04 Sep 2005 23:21:20 +0100
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked], Lisa Dusseault <[email-masked]>
Subject: Re: RECURSIVEMATCH and REMOTE
Sender: [email-masked]

Dave Cridland wrote:

>
> Sorry this is so late... (Explanation below)
>
> The problem:
>
> What exactly should REMOTE with RECURSIVEMATCH actually do?
>
> REMOTE - expands the selection to return both local and remote mailboxes.
>
> RECURSIVEMATCH - adds information about which mailboxes have child 
> mailboxes which match the selection.
>
> Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks for 
> every mailbox.

There is a suggestion in the latest draft to omit redundant CHILDINFO 
blocks (in section 3.3):

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

But a naive implementation will do as you describe.

> Using REMOTE SUBSCRIBED RECURSIVEMATCH is presumably trying to find
> child mailbox which are subscribed, and extending the search to 
> include remote mailboxes - not looking for child mailboxes which are 
> both remote *and* subscribed.
>
> Proposal:
>
> All selection options must indicate in their specification and 
> registrations whether they operate with RECURSIVEMATCH. REMOTE 
> indicates that it does not. Therefore, although an implementation 
> which does not provide remote mailboxes MUST accept REMOTE, it is 
> treated as a no-op, and a client which issues just REMOTE 
> RECURSIVEMATCH without any other selection options is in error.

I am fine with treating REMOTE RECURSIVEMATCH on such servers as an 
error or noop. I don't care much either way.

> Specific Text:
>
> Section 3, para 5 [Starting "A LIST selection option"], add prior to 
> last sentence:
>
> "Some selection options are not affected by RECURSIVEMATCH, this is 
> defined by their specification."
>
> Text in section 3 about REMOTE [Beginning "REMOTE - "] adds this 
> sentence at the end of the first paragraph:
>
> "The REMOTE selection option is ignored for the purposes of 
> RECURSIVEMATCH. However, use of RECURSIVEMATCH and REMOTE will search 
> child mailboxes which are remote as well."
>
> Last sentence of the REMOTE prose gets deleted.
>
> Text in section 3 about RECURSIVEMATCH changes. First pararaph changes 
> to:
>
> "RECURSIVEMATCH - this option forces the server to return information 
> about parent mailboxes which may not match the remaining selection 
> options, but have some submailboxes which match those selection 
> options which are not defined as ignored for the purposes of 
> RECURSIVEMATCH. Information about children is returned in the 
> CHILDINFO extended data item, as described in Section 3.3"
>
> Finally, add something to the IANA template to indicate whether the 
> option is ignored for the purposes of RECURSIVEMATCH.
>
> Comments?

The suggestion is fine with me.

Alexey

Date: Sat, 03 Sep 2005 00:07:56 +0100
Subject: RECURSIVEMATCH and REMOTE
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Sorry this is so late... (Explanation below)

The problem:

What exactly should REMOTE with RECURSIVEMATCH actually do?

REMOTE - expands the selection to return both local and remote 
mailboxes.

RECURSIVEMATCH - adds information about which mailboxes have child 
mailboxes which match the selection.

Therefore, REMOTE RECURSIVEMATCH would display CHILDINFO blocks for 
every mailbox.

Using REMOTE SUBSCRIBED RECURSIVEMATCH is presumably trying to find
child mailbox which are subscribed, and extending the search to 
include remote mailboxes - not looking for child mailboxes which are 
both remote *and* subscribed.

Proposal:

All selection options must indicate in their specification and 
registrations whether they operate with RECURSIVEMATCH. REMOTE 
indicates that it does not. Therefore, although an implementation 
which does not provide remote mailboxes MUST accept REMOTE, it is 
treated as a no-op, and a client which issues just REMOTE 
RECURSIVEMATCH without any other selection options is in error.

Specific Text:

Section 3, para 5 [Starting "A LIST selection option"], add prior to 
last sentence:

"Some selection options are not affected by RECURSIVEMATCH, this is 
defined by their specification."

Text in section 3 about REMOTE [Beginning "REMOTE - "] adds this 
sentence at the end of the first paragraph:

"The REMOTE selection option is ignored for the purposes of 
RECURSIVEMATCH. However, use of RECURSIVEMATCH and REMOTE will search 
child mailboxes which are remote as well."

Last sentence of the REMOTE prose gets deleted.

Text in section 3 about RECURSIVEMATCH changes. First pararaph 
changes to:

"RECURSIVEMATCH - this option forces the server to return information 
about parent mailboxes which may not match the remaining selection 
options, but have some submailboxes which match those selection 
options which are not defined as ignored for the purposes of 
RECURSIVEMATCH. Information about children is returned in the 
CHILDINFO extended data item, as described in Section 3.3"

Finally, add something to the IANA template to indicate whether the 
option is ignored for the purposes of RECURSIVEMATCH.

Comments?

Dave.
-- 
I thought I'd sent some stuff on this issue ages ago, but it seems 
I'd somehow ended up with the wrong email address for the list. 
Probably my typo, since although normally it would get auto captured, 
this mailing list doesn't give List-Post headers. This was somewhat 
compounded by the minor problem that I've broken the addressbook 
editor. So it was a telnet localhost 674 job to fix it.