FOSDEM Report - Saturday

[Greg Banks]

On Thu, Feb 9, 2012, at 09:58 AM, Jeroen van Meeuwen wrote:

  > I think the important thing is trackability from a user
  point of view.

  > Let's say I'm a Cyrus sysadmin who has discovered a bug in
  their

  > installation, which is described in a Bugzilla ticket and
  already fixed in

  > some newer release. The key things I want to know are:

  >

  > - is there a fix?

  >

  > - if so, is that fix in a release yet?

  >

  > - if so, which release(s) is it?

  >

  > - if not, where can I get a patch that I can apply to my
  install?

  >

  - 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)

Good point.

  > > >> Special-Use:

  > >

  > > Technically, it's been outlined what Kolab Systems is
  seeking to do

  > > here, and as it is not so much on the roadmap for other
  parties

  > > involved, we're therefore seeking ways to allow us to also
  actually do

  > > the work (instead of asking other parties to do the work
  for us).

  > >

  > > I'm looking forward to it, as currently I may have seemed
  to ill- /

  > > ambiguously define what it is we're trying to do exactly.

  >

  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,

Ok.

where such folders are annotated through SPECIAL-USE,

Sounds good.

so that any IMAP client is automatically compatible.

I'm not entirely sure what you mean by "compatible".

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.

SPECIAL-USE already requires "ENABLE SPECIAL-USE" by the client,

No it doesn't.  RFC6154 says no such thing.

and the server can therefore (to a client not enabling
SPECIAL-USE) just hide the \Calendar and/or \Contacts folders.

Hmm, this is an ugly area.

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.

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:

[1]http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3642

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,

Visibility semantics of the new attributes are extremely fuzzy
and poorly thought out in RFC6154.

and what could arguably be a shared annotation, all of which
justify an extension / replacement of the current RFC to be
drafted.

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.

I explained this problem in an internal post the other day

The special-use data is already defined in the RFC as being tied
to a specific annotation.

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.

Cyrus compromises by calling the annotation /private/specialuse,
enforcing /private access controls, but storing it in a way which
is actually more like /shared.

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".

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:

 - bob sees all of alice's messages which have the \Flagged flag
(this is probably the closest approximation to /shared)

 - bob sees all of bob's messages which have the \Flagged flag

 - bob sees an empty folder with the \Flagged special-use item

 - bob sees an empty folder without the \Flagged special-use item
(this is the closest approximation to /private)

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.

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?

 - user.bob.Sent (if the client sees the \Sent special-use item
on that folder only, i.e. /private semantics)

 - user.bob.Sent (if the client sees both \Sent items and chooses
only the one(s) under user.bob)

 - 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)

 - user.alice.Sent (if the client sees both \Sent items and
chooses the first folder in lexical order).

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.

  > > >> * Undo.

  > Ah I see. I agree entirely about the uselessness of 'Are you
  sure?', but I

  > think we should have a weak and specific form of Undo, which
  provides for

  > ways to undo only those operations which would otherwise
  lose data, and

  > only for a limited period of time. For example, deleting a
  message or

  > deleting a folder should have an equivalent Undo operation,
  but setting the

  > \Flagged flag should not.

  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

Agreed - the server should provide a standard mechanism for the
client to back out that change,

--

Greg.

References

1. http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3642
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120210/d8ae932a/attachment-0001.html