Hi Wilfredo,
this is a very good reply, I know see much better where you are coming
from :-)
On 20.05.2009, at 19:32, Wilfredo Sánchez Vega wrote:
This is false. When a client transmit email itself, it should
inform the server of this (schedule-agent=client) so that the server
does not also attempt delivery.
A regular CalDAV client won't set the SCHEDULE-AGENT header, there is
nothing in the CalDAV spec which requires that. This is a CalDAV-
Scheduling extension.
I think the interop issues (I see) mostly go away if:
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)
b) the CalDAV scheduling draft enhances the REPORTs, so that email
addresses can be retrieved together with the iCal entity
(point c in my mail of 2009-05-17)
[even CalDAV-sched aware clients will base a lot of infrastructure
on emails]
You claim that clients might break due to assumption they have about
iMIP. iMIP clients aren't going to just work with CalDAV; they have
to do something more in order to comply with the CalDAV spec.
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)
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.
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]
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.
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?
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.
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.
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).
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.
[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.]
Anyways, all that is nitpicking, it does not bring us anywhere.
What do you propose the server does here? There is no longer a
directory record with wsanc...@mit.edu in it, so I can't locate the
ATTENDEE, even though it existed before. I believe you imply that
in this case I can notice this and use my X-ID parameter to locate
the user instead.
Yes, I suggest that the server _always_ uses the X-ID parameter to
locate the user if its present. In fact, I'm very much in favor in
adding an additional, none X- parameter for that. Like:
ATTENDEE
;SCHEDULE-AGENT=SERVER
;SCHEDULE-SERVER-ID=urn:uuid:298383-28382-3823
:mailto:a...@def
Doesn't look too bad to me :-)
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.
[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.
Sequence:
1. meeting with user B planned by user A client A
2. email reassigned from user A to user C
3. meeting status changed by user B via iMIP
Point is, all that email-deleted, email-changed thing happens super-
rarely in the real world. And if it happens, there are bigger issues
than dropped scheduling messages. (obviously emails send to the wrong
account, which is why very few people reassign emails)
You want to know which clients fail to preserve the X-ID parameter.
The reason this doesn't matter is that doing so doesn't always solve
the problem either. if a client sees this:
ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanc...@mit.edu
Let's say the client decides to change the email address because it
knows my mit.edu address is obsolete, and it has my new one. It
otherwise wants to keep the information intact. It doesn't know
what X-ID, but, being a good citizen, it doesn't monkey with it:
ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanc...@wsanchez.net
Once again, should the server ignore this change and go with the X-
ID, or go with the address provided by the client?
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.
All of this has to be defined, but it a whole lot simpler if we go
back to doing the right thing and conform to the specification.
Yes, that means I have to rely on clients doing so as well.
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.
Maybe also consider specifying a SCHEDULE-SERVER-ID and related
semantics. Though I have no strong feelings about that part.
Thanks,
Helge
--
http://zideone.com/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
