1 Nov 2004 19:44
Timo Sirainen <tss <at> iki.fi>
2004-11-01 18:44:09 GMT
2004-11-01 18:44:09 GMT
On 1.11.2004, at 20:09, Cyrus Daboo wrote: >> The 'm' right controls both read and write access to .priv >> annotation >> values. When it is on, access to .priv annotations is allowed, >> when >> it is off, access to .priv annotations is disallowed. >> >> Is this really needed? I think private annotations should work the >> same >> way as private flags. You can always read them, and you can write >> them if >> it's possible to permanently save flags. > > In an ACL-aware server there are different ways to control the flag > state 's' and 'w' bits. As a result I think there should also be a way > to enable/disable private annotations independently - hence the 'm' > bit. I know Alexey had some concerns with 'm' too so this is still an > open issue. Well, perhaps it would be useful to have "m" for writing because of that, but I think "r" would be more logical for reading private annotations. >> I thought clients weren't allowed to make up their own annotation >> entry >> names? Or what does this mean? > > If a client wants to create a 'boolean' (on/off) type property > associated with a message it has two options: use an IMAP keyword > (either private or registered), or create a vendor (or new standard) > annotation entry. The former gives no control over private/shared > state, whereas the latter does. So if there is a specific need for > such a property that does need explicit private/shared behavior then > the client can use annotations in lieu of IMAP keywords. I thought vendor namespaces meant that servers could create them, not clients. Maybe put at the beginning of 2.2.1 something like: Vendor namespaces can be created by either clients or servers. Servers MUST(?) support new namespaces created by clients. > Here is some alternate text for the above paragraph that I am > proposing to use instead. Note this also includes a sentence to > address the first point you made: > > Clients that need to implement a property on a message that is > either 'on' or 'off' and which requires separate private and shared > state can use an annotation to represent that property as opposed > to using IMAP Keywords, which cannot reliably discriminate the > private and shared state. However, clients MUST NOT use annotations > to replace existing IMAP flag behavior, which would cause > interoperability problems with non-ANNOTATE aware clients. > > If that is not suitable, please suggest some other text or > clarifications. Looks good to me.