<style defang_type="text/css">
p, li { white-space: pre-wrap; }
</style><div><br></div><div><br></div><div>On Thu, Feb 9, 2012, at 09:58 AM, Jeroen van Meeuwen wrote:<br></div><blockquote class="QuoteMessage" type="cite"><p style="margin: 0px; text-indent: 0px;"><br></p><p style="margin: 0px; text-indent: 0px;">> I think the important thing is trackability from a user point of view. <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> Let's say I'm a Cyrus sysadmin who has discovered a bug in their<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> installation, which is described in a Bugzilla ticket and already fixed in<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> some newer release. The key things I want to know are:<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> - is there a fix?<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> - if so, is that fix in a release yet?<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> - if so, which release(s) is it?<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> - if not, where can I get a patch that I can apply to my install?<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "><br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">- and/or, for the last point, where/how can I request the patch be made available for a current release series (i.e. 2.4.$z)<br></p></blockquote><div><br></div><div>Good point.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><p style="margin: 0px; text-indent: 0px;">> > >> Special-Use:<br></p><p style="margin: 0px; text-indent: 0px;">> > <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > Technically, it's been outlined what Kolab Systems is seeking to do<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > here, and as it is not so much on the roadmap for other parties<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > involved, we're therefore seeking ways to allow us to also actually do<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > the work (instead of asking other parties to do the work for us).<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > <br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > I'm looking forward to it, as currently I may have seemed to ill- /<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > ambiguously define what it is we're trying to do exactly.<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> <br></p><p style="margin: 0px; text-indent: 0px;"><br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">What we're specifically looking for, paraphrasing a 30.000 ft high-level birds view, is xCal and xCard stored in IMAP folders that are also made available through CalDAV / CardDAV, <br></p></blockquote><div><br></div><div>Ok.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div><br></div><div>where such folders are annotated through SPECIAL-USE, <br></div></blockquote><div><br></div><div>Sounds good.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div>so that any IMAP client is automatically compatible. <br></div></blockquote><div><br></div><div>I'm not entirely sure what you mean by "compatible".<br></div><div><br></div><div>If a client understood Content-Type: application/calendar+xml and did something useful with it, like display the calendar, or start up a separate calendar tool, then it's compatible. If a client didn't understand that, a user opening that folder would see a bunch of XML gibberish, which is very nearly the moral equivalent of not showing anything at all, except more confusing.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div><br></div><div>SPECIAL-USE already requires "ENABLE SPECIAL-USE" by the client,<br></div></blockquote><div><br></div><div>No it doesn't. RFC6154 says no such thing.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div><br></div><div> and the server can therefore (to a client not enabling SPECIAL-USE) just hide the \Calendar and/or \Contacts folders.<br></div></blockquote><div><br></div><div>Hmm, this is an ugly area.<br></div><div><br></div><div>RFC6154 defines a new RETURN (SPECIAL-USE) option for the LIST command, which allows a client to specifically request a listing of mailboxes including the SPECIAL-USE information. Cyrus recognises this and adds in the SPECIAL-USE information.<br></div><div><br></div><div>However, RFC6154 allows the server to emit that information even when not specifically requested to. This is legal thanks to a loophole in RFC5258, and the example in section 5.1 of RFC6154 shows this happening. Apparently the iOS 5 client expects that to happen:<br></div><div><br></div><div><a href="http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3642">http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3642</a><br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div><br></div><div> Such-and-such requires an extension to the current SPECIAL-USE RFC though, as currently it only ever involves messages, does not set any standards regarding the format of folder's contents (as it only involves mail). There need to be some clarifications on what is a private "annotation" within SPECIAL-USE, <br></div></blockquote><div><br></div><div>Visibility semantics of the new attributes are extremely fuzzy and poorly thought out in RFC6154.<br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><div><br></div><div>and what could arguably be a shared annotation, all of which justify an extension / replacement of the current RFC to be drafted.<br></div></blockquote><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "><br></p><div>Cyrus does an ugly thing here - it exports an annotation /private/specialuse but the annotation's behaviour is almost exactly the normal /shared semantics. In fact the mapping between the semantics of annotation visibility and special-use attribute visibility are not at all obvious.<br></div><div><br></div><div>I explained this problem in an internal post the other day<br></div><blockquote><div><br></div><div>The special-use data is already defined in the RFC as being tied to a specific annotation.<br></div><div><br></div><div>Unfortunately the RFC authors didn't quite get the visibility semantics right. The annotation is defined in the final RFC to be /private/specialuse, which sounds right at first glance but is a poor approximation to the actual underlying semantics of some of the keywords. It is also a pain to implement because it means storing multiple values on the mailbox, one for each user who has set a value. An earlier draft had /shared/specialuse, which has different problems.<br></div><div><br></div><div>Cyrus compromises by calling the annotation /private/specialuse, enforcing /private access controls, but storing it in a way which is actually more like /shared.<br></div><div><br></div><div>The *real* visibility semantics of special-use are fuzzy and not well addressed in the RFC. They probably vary from keyword to keyword, and the most sensible set of semantics for most of those keywords are probably not either of the semantics defined for /private or /shared but a third thing. Those might be something like "this is a flag stored on a mailbox, which any user can see, but which has a special effect only when accessed by the owner of the mailbox", but that's not the only possibility. Another possibility might be "this is a flag stored on a mailbox, which only a specific user can see, which has a special effect if seen". Or even "this is a flag stored on a mailbox, which every user can see, which has a special effect for every user but that effect is specific to the user".<br></div><div><br></div><div>To give an example of what I mean, imagine a folder called 'user.alice.Flagged', on which user 'alice' has set the \Flagged special-use item. What is the behaviour of the folder when user 'bob' looks at it? Possibilities include:<br></div><div><br></div><div> - bob sees all of alice's messages which have the \Flagged flag (this is probably the closest approximation to /shared)<br></div><div><br></div><div> - bob sees all of bob's messages which have the \Flagged flag<br></div><div><br></div><div> - bob sees an empty folder with the \Flagged special-use item<br></div><div><br></div><div> - bob sees an empty folder without the \Flagged special-use item (this is the closest approximation to /private)<br></div><div><br></div><div>Now \Flagged defines a magical virtual folder serverside (and we don't implement it in Cyrus anyway). There are other special-use items which are intended to be set on regular un-virtual folders as hints for the client, e.g. \Sent and \Drafts. These have similar but slightly different conceptual problems.<br></div><div><br></div><div>For example, let's say there exist folders 'user.alice.Sent', on which alice has set the \Sent special-use item, and 'user.bob.Sent', on which bob has set the \Sent special-use item. Bob now starts a client and sends a message; which folders should the client add copy of the sent message to?<br></div><div><br></div><div> - user.bob.Sent (if the client sees the \Sent special-use item on that folder only, i.e. /private semantics)<br></div><div><br></div><div> - user.bob.Sent (if the client sees both \Sent items and chooses only the one(s) under user.bob)<br></div><div><br></div><div> - user.bob.Sent *and* user.alice.Sent (if the client sees both \Sent items and copies to all of them, which is probably the best match to /shared semantics)<br></div><div><br></div><div> - user.alice.Sent (if the client sees both \Sent items and chooses the first folder in lexical order).<br></div><div><br></div><div>In practice none of this makes the slightest bit of difference because almost always any folder with a special-use set on it will be owned by a single user and not be writable by any other users.<br></div></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="QuoteMessage" type="cite"><p style="margin: 0px; text-indent: 0px;"><br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> > >> * Undo.<br></p><p style="margin: 0px; text-indent: 0px;"><br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> Ah I see. I agree entirely about the uselessness of 'Are you sure?', but I<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> think we should have a weak and specific form of Undo, which provides for<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> ways to undo only those operations which would otherwise lose data, and<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> only for a limited period of time. For example, deleting a message or<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> deleting a folder should have an equivalent Undo operation, but setting the<br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> \Flagged flag should not.<br></p><p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "><br></p><p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">And that is the general idea, I think; The infrastructure (Cyrus IMAP server) should allow for the client to deploy an "undo" mechanism, rather then each client trying to do so themselves. A reference example could be "Delete folder" - currently there's absolutely no way for the user to completely autonomously recover from that<br></p></blockquote><div><br></div><div>Agreed - the server should provide a standard mechanism for the client to back out that change,<br></div><div><br></div><div class="signature sig6157271">-- <br></div><div class="signature sig6157271">Greg.<br></div>