On May 25, 2009, at 4:46 AM, Helge Heß wrote:
a) the default of SCHEDULE-AGENT is changed from SERVER to CLIENT,
this will make iCal server leave the ATTENDEE intact for
regular CalDAV clients (if I understood you right)
This removes a very useful feature of scheduling-aware servers,
which is that a non-scheduling-aware client can still do simple things
like accept a meeting (by changing PARTSTAT) and all the right
scheduling magic still happens, because the server takes care of it.
Most of the existing CalDAV (*not* CalDAV scheduling) clients don't
need to do anything special to support CalDAV.
Kontact, Evolution and Lightning are all based on an iCalendar
internally. To support CalDAV, they 'just' need to replace the
storage layer. Outlook is somewhat similiar, while the storage layer
is pluggable, the whole scheduling part is not pluggable but handled
in internal code (it still can be done, but its major work).
They do need to do a lot more to become CalDAV scheduling clients.
In fact most plugin architectures do not allow an easy replacement
of the scheduling handling. (which is why I don't see this happening
soon)
I guess I'm choosing to focus my priorities on scheduling-aware
clients, and those that are not can come along for the ride as best as
they can.
I'm not sure I believe that they need a lot more to become
scheduling clients, but I can see how software that make assumptions
in their infrastructure will have challenges when new infrastructure
comes into play.
The ATTENDEE property value is a delivery address.
When iCal is used in conjunction with iTIP, yes. If its used as a
storage format, the ATTENDEE line represents a contact. And
calendaring software rarely lives on its own, but usually integrates
with contact management.
Unless the client sets SCHEDULE-AGENT=CLIENT, iTIP is always in play.
BTW: using CALURI to store the UUID in a vCard is IMHO as
questionable as using DIR in ATTENDEEs for that purpose :-) [and has
the same id resolution issues attached]
Agreed.
It tells the server who needs to be notified of changes to a
meeting. Your proposal to add an X-parameter (or DIR) with the
authoritative delivery address does not comply with the spec, which
requires that we use the value of the property.
Fair enough, though only relevant for CalDAV-Sched clients.
…if they set SCHEDULE-AGENT=CLIENT.
The only interesting argument I'm hearing against using a URN is
that the client can't resolve that to something useful. This is
why our server is diligent about filling in the CN param regardless
of whether it is provided, as well as added an X-param with the
email address that you think is the best way to identify a user (we
provide it so you can send email to the user, but you may use it as
you wish).
The X-APPLE-EMAIL thing does not help much (well, it does help me in
Outlook ...). My whole point is about not breaking existing things.
The X- thing just makes it slightly easier. Maybe spec an EMAIL
attribute then, similiar to DIR and CN?
Yes. We've decided to change the name of the X-APPLE-EMAIL
parameter to EMAIL and plan to register it after the iCalendar spec
update goes in. (We're making the change prior to registration so we
don't have to figure out how to migrate from one to the other later;
I'm hard-pressed to think of why anyone might propose an EMAIL
parameter that isn't an email address.)
I would also like to point out that I do NOT think that the email is
the best person/group/resource identifier per-se, its just the only
one which is reasonable interoperable.
Understood.
Now, MIT tells me I can't keep my email address after more than a
decade past graduation
Thats the email stability issue. That an email address is reassigned
is obviously as an edge case as it can get (one in a million?). That
an email address is not working anymore isn't a big issue, its still
a valid identifier.
Whoah. That is not nearly the edge case you think it is. At MIT I
recall that it happened fairly regularly while I was around, in fact.
Note that the server might still rewrite the email to its new email
based on the UUID. (iCal contains the pkey, but the directory
updated the email. Hence, on the next GET, the server might deliver
a new email).
This is correct.
Also note that UUIDs also have their own 'stability' issues. Eg if a
server is reinitialized, UUIDs become meaningless, while email
addresses will still work.
Sure. If you mis-configure or delete data on your server, bad
things happen.
[Another thing which will (often!) happen in the real world is that
a CalDAV server sends out iMIP messages but the replies will bypass
the CalDAV server. Hence the client needs to remap the iMIP attendee
info to the CalDAV attendee.]
On our server, the replies come back to the server. The only case
where it does not is SCHEDULE-AGENT=CLIENT where the client does the
iMIP scheduling.
Anyways, all that is nitpicking, it does not bring us anywhere.
Well, it may clarify some requirements.
This is clearly a violation of the spec, and is not what the client
asked me to do. The client is asking me to use wsanc...@mit.edu as
an attendee. Let's say that following the spec is not all that
important, because we are very smart and know better, so I notice
that the email address is not in the directory, but my ID in there,
so I delivery it to the new record, and perhaps I even update the
property value to have the new email address. Is this what you
suggest?
Yes, thats the additional smartness thing you might want to do. I
don't really suggest it though, I suggest to use email addresses,
always. Maybe give the user a chance to resolve it, if it can't be
found in the directory anymore.
I don't consider that viable. For one thing there is no way to ask
the user to do anything except via the protocol. There is no way in
the protocol to specify that a client should ask for conflict
resolution from the user, and I imagine that doing so property is more
than a little bit of work. Even assuming that, it requires that the
server wait for a reply from the user, which could never come, before
it continues with event processing.
[reassigned email]
Here's a simpler case: the server supports server-side iMIP (and
hey, by coincidence, ours does). Should we send an iMIP message to wsanc...@mit.edu
as we normally do for which ATTENDEEs we don't provide CalDAV
delivery, or stick with the X-ID, or emit an error?
Don't know, very edgy edge case. Fact is, that the whole iMIP part
breaks in this case anyways. Other iMIP clients will still have the
old iMIP address and will deliver messages incorrectly. Which makes
this one a non-point actually.
It's "very edgy" because you aren't writing the server. For me,
it's a case I have to deal with.
Why would it ignore the change? It can perfectly detect that the
client *wants* to change the email.
How thats implemented in the server, is the servers choice. It could
attempt to update the directory (often inappropriate, might depend
on the server type). I guess I would rather have an email address
field kept with the ID. NULL means, derive from directory, set
means, use what the client did provide.
Another option would be to switch from SCHEDULE-AGENT=SERVER to
CLIENT. Or emit an error which tells the client its need to switch
to perform the change.
Or I can expect clients to abide by the protocol spec and do what
I'm doing now.
As my conclusion so far, consider my points a) and b) at the top of
the email. I have the impression that this would be an acceptable
compromise?
A client which is sched-aware could use b) to do the addressbook
integration stuff.
I'm not inclined to push for (a) as I mentioned above, but I agree
about (b).
Anyways, iCal server does not honour SCHEDULE-AGENT=CLIENT, it
always replaces the ATTENDEE with the UUID.
That should be fixed now.
-wsv
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
