UIDs as ATTENDEE IDs, please fix that

[Helge Heß]

Hi,

CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think  
thats a really BIG mistake, I feel very strongly about it ;-) and  
would like to see that behaviour modified.

Currently:
   ATTENDEE;X-CALENDARSERVER-EMAIL=abc@...:urn:uid:29838484...

should be
   ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@...
or even
   ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:[phone]


Why? There are two big reasons:

a) Interoperability. I would claim that all iCalendar clients use  
mailto ids today. Plus plenty of other iCalendar infrastructure.  
Changing this will result in interop issues and breaks a lot of stuff  
for (IMO) no good reason.

b) The URN is completely opaque/proprietary to the client. It can't  
possibly resolve a URN to a contact database or other things which  
relate to attendees. This results in bad user experience and cross app  
integration at multiple levels.


Note that my suggestion still includes a server specific UID which can  
be used for a stable resolution - as long as clients preserve it. And  
if not, its still sufficient for the far majority of real world  
deployments (reassigning email addresses is a no go, don't understand  
why people even consider that :-).

Cyrus claims that this is not viable because clients throw away X-  
attributes. Does iCal do that? I think Kontact, Evo, Moz are all  
preserving such (we certainly do).

Note: I'm fine with emitting URNs for stuff which can't possibly be  
resolved. Resources or locations _might_ be in that category, though I  
would still prefer an LDAP URL (+ UID X attr) if they are backed by  
something like OD. This still gives the client a way to learn about  
the ATTENDEE.

Thanks a lot,
   Helge
--
Helge Hess
http://helgehess.eu/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Wilfredo Sánchez Vega]

On May 1, 2009, at 8:05 AM, Helge Heß wrote:

> CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think  
> thats a really BIG mistake, I feel very strongly about it ;-) and  
> would like to see that behaviour modified.
>
> Currently:
>  ATTENDEE;X-CALENDARSERVER-EMAIL=abc@...:urn:uid:29838484...
>
> should be
>  ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@...
> or even
>  ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:[phone]
>
>
> Why? There are two big reasons:
>
> a) Interoperability. I would claim that all iCalendar clients use  
> mailto ids today. Plus plenty of other iCalendar infrastructure.  
> Changing this will result in interop issues and breaks a lot of  
> stuff for (IMO) no good reason.

   Well, I disagree with the assertion that there is no good reason.

> b) The URN is completely opaque/proprietary to the client. It can't  
> possibly resolve a URN to a contact database or other things which  
> relate to attendees. This results in bad user experience and cross  
> app integration at multiple levels.

   The ATTENDEE value is a URI, and doesn't have to be a mailto: URI.  
I recognize that most agents have used mailto:, but iMIP is the  
primary transport for iTIP in most agents.  I don't believe that it is  
reasonable for a CalDAV client to continue to assume that email  
addresses will always be used to identify attendees.

   The ATTENDEE value is a primary key on the calendar server for  
identifying a user.  An email address is a delivery address on an  
email server, which may be (and is, in our case) on a separate and  
unrelated server.  It is not tenable to have the primary key in our  
system be controlled by a separate system that we have no visibility  
into.

   Additionally, email addresses are not immutable.  You might be helge@...
  today and then due hess@... tomorrow.  Again, we have no  
visibility into that, and no way to know these are the same two  
people, and absolutely no way to know that helge@... two days from  
now is actually Joe Helge, who just joined Foo Corp.

> Note that my suggestion still includes a server specific UID which  
> can be used for a stable resolution - as long as clients preserve  
> it. And if not, its still sufficient for the far majority of real  
> world deployments (reassigning email addresses is a no go, don't  
> understand why people even consider that :-).
>
> Cyrus claims that this is not viable because clients throw away X-  
> attributes. Does iCal do that? I think Kontact, Evo, Moz are all  
> preserving such (we certainly do).
>
> Note: I'm fine with emitting URNs for stuff which can't possibly be  
> resolved. Resources or locations _might_ be in that category, though  
> I would still prefer an LDAP URL (+ UID X attr) if they are backed  
> by something like OD. This still gives the client a way to learn  
> about the ATTENDEE.

   LDAP might work if the server was always bound to an LDAP service,  
and even then requires the client to implement another protocol, and  
still then assumes that the client has access to the LDAP server.

   Instead, we provide a REPORT query that can resolve a calendar user  
address (including email, if we think we can uniquely identify a  
principal with it) into a principal URL and additional attributes,  
including full name, email, etc. so that you can do all of this via  
CalDAV.

   For expediency, we also provide email as a parameter, as you note  
to clients, as we do with the full name.  In the future, we may offer  
up a URL to a CardDAV record.

   Both of these (the parameters and the new REPORT) need to be  
standardized for interoperability.

        -wsv

_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

On 06.05.2009, at 18:52, Wilfredo Sánchez Vega wrote:
>  Well, I disagree with the assertion that there is no good reason.


Please elaborate. Whats the advantage of

   ATTENDEE;X-EMAIL=abc@...:urn:uid:98128912

over

   ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@...
or
   ATTENDEE;DIR=urn:uid:98128912:mailto:abc@...

Thats the core of my claim of 'no good reason'. Your requirements can  
be met w/o breaking anything existing. (if this does break with some  
client, please tell us which)


Further, as I said, there is no way for a client to resolve a UID to  
some contact record. You talk about a REPORT to resolve UIDs, I  
suppose this might be OK. Whats this REPORT?

BTW1: using properties for lastname/firstname etc is rather useless,  
since properties are not covered by etags, hence uncachable.
BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV,  
plain URL pointing to a vCard would be fine, similiar to FBURL)


>  Both of these (the parameters and the new REPORT) need to be  
> standardized for interoperability.


Well, yes, I also thought that we might want to standardize a UID  
parameter to avoid an X-CALSERVER-UID. But then, this is basically  
what DIR already provides.

Thanks,
   Helge
--
Helge Hess
http://helgehess.eu/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Wilfredo Sánchez Vega]

On May 6, 2009, at 10:10 AM, Helge Heß wrote:

> Please elaborate. Whats the advantage of
>
>  ATTENDEE;X-EMAIL=abc@...:urn:uid:98128912
>
> over
>
>  ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@...
> or
>  ATTENDEE;DIR=urn:uid:98128912:mailto:abc@...
>
> Thats the core of my claim of 'no good reason'. Your requirements  
> can be met w/o breaking anything existing. (if this does break with  
> some client, please tell us which)

   The advantage is that the primary value of the property corresponds  
to the primary key on my server, and this is unlikely to break.

   I'm not convinced that parking a GUID in DIR is a valid use of DIR,  
nor that DIR is any safer than an X-parameter.

   I'm not inclined to trust all clients to do the right thing  
according to the spec.  This apparently includes not assuming that the  
value is an email address, per the spec, but I'm willing to live with  
that if it keeps my primary keys intact.

> Further, as I said, there is no way for a client to resolve a UID to  
> some contact record. You talk about a REPORT to resolve UIDs, I  
> suppose this might be OK. Whats this REPORT?

   report_DAV__principal_property_search here:
   http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/extensions.py

   Though that may be reorganized in a bit.  I'm guessing Cyrus will  
write up a spec for that in a bit as well.

> BTW1: using properties for lastname/firstname etc is rather useless,  
> since properties are not covered by etags, hence uncachable.

   It's useless for caching, perhaps.  That doesn't make it useless,  
though it might make it worthless to you.

   WebDAV has its flaws as regards properties and caching.

> BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV,  
> plain URL pointing to a vCard would be fine, similiar to FBURL)

   Agreed.

>> Both of these (the parameters and the new REPORT) need to be  
>> standardized for interoperability.
>
> Well, yes, I also thought that we might want to standardize a UID  
> parameter to avoid an X-CALSERVER-UID. But then, this is basically  
> what DIR already provides.


_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

On 16.05.2009, at 00:45, Wilfredo Sánchez Vega wrote:

> On May 6, 2009, at 10:10 AM, Helge Heß wrote:
>> Please elaborate. Whats the advantage of
>>
>> ATTENDEE;X-EMAIL=abc@...:urn:uid:98128912
>>
>> over
>>
>> ATTENDEE;X-CALSERVER-UID=98128912:mailto:abc@...
>> or
>> ATTENDEE;DIR=urn:uid:98128912:mailto:abc@...
>>
>> Thats the core of my claim of 'no good reason'. Your requirements  
>> can be met w/o breaking anything existing. (if this does break with  
>> some client, please tell us which)
>
>  The advantage is that the primary value of the property corresponds  
> to the primary key on my server, and this is unlikely to break.

The likeliness that it will break is quite high, obviously. While some  
clients might conform with the iCal RFC and support arbitrary ATTENDEE  
URLs, only emails are widely deployed and tested.

Obviously iMIP is the only kind-of-standard actually deployed for  
scheduling, and the UUIDs completely fail with that. And that won't  
change anytime soon, given that 80% of the deployed groupware systems  
(Domino/Exchange) won't support CalDAV scheduling any time soon, so  
iMIP is crucial at least for 5+ years.

And the most important thing is still, that the pkey is completely  
opaque to the client. Hence, it can't possibly integrate attendees  
with existing contact management systems. And thats just a no-go.

> I'm not convinced that parking a GUID in DIR is a valid use of DIR,  
> nor that DIR is any safer than an X-parameter.

I guess I tend to agree. DIR is standardized though, less software is  
allowed to drop it. (formally, in practice software which drops either  
is buggy ...)

> I'm not inclined to trust all clients to do the right thing  
> according to the spec.  This apparently includes not assuming that  
> the value is an email address, per the spec, but I'm willing to live  
> with that if it keeps my primary keys intact.

Well, IMHO its a very weird balancing of things.

Situation a) UUID attendees
- clients might break
- server definitely breaks if clients break

Situation b) UUID in X-
- client might loose X- (though, thats a theory, no specifics!)
- server still does NOT break in 99% of the cases, since it
   fallbacks to emails

So yes, you might loose a distinct primary key. You must be prepared  
to that anyways, since a client is also free to transmit emails or  
whatever it wants at any time.


I fail to comprehend your position given that:
a) you fail to name clients which would actually loose your X-
    property
b) clients which might loose your X- property, would still work
    very well, given that you must deal with email matching anyways


>> Further, as I said, there is no way for a client to resolve a UID  
>> to some contact record. You talk about a REPORT to resolve UIDs, I  
>> suppose this might be OK. Whats this REPORT?
>   report_DAV__principal_property_search here:
>  http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/extensions.py
>
>  Though that may be reorganized in a bit.  I'm guessing Cyrus will  
> write up a spec for that in a bit as well.

Oh well. Thats really one of the few aspects which already works  
reasonably well in the real world. Why add even more API/standards for  
that.


So far, I still miss a good reason. That a server wants to embed its  
own ID is perfectly viable - and perfectly possible via X-.
But breaking working stuff? Implemented in iMIP and many clients? That  
just doesn't seem to be viable.

Clients won't follow you on the UID thing, thats pretty much for sure.  
It will be a solution which can only work well Apple<->Apple.
The ATTENDEE id you came up with is completely proprietary and  
unresolvable. No addressbook integration possible (w/o Apple specific  
hacks).

All that is _very_ disappointing.

Sorry,
   Helge
--
Helge Hess
http://helgehess.eu/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

OK,

rereading the thread it sounds like you refuse to fix it. I guess  
there is little we can do about it besides filing bug reports listing  
Lightning, Evolution, Kontact, ... interoperability issues :-)

So lets focus on how a client can resolve the 'Apple way' GUIDs and  
how all that works internally.


a) if a client PUTs a message with attendees like that:

      ATTENDEE:mailto:abc@...

    CalServer will lookup the mailto in its directory and replace
    it with:
      ATTENDEE;X-CALENDAR-SERVER-EMAIL=abc@...:urn:uuid:29382..

    The server will do this instantly and the client needs to do
    a GET after each PUT.

a1) Question: what happens if the mailto is not in the local
     directory, but points to an external participant?
     (eg comes from a CardDAV server)

a2) Can you return modified content in the PUT response, with a
     200 OK instead of requiring a reGET? (not sure whether that
     would be OK will HTTP)


b) if a client PUTs a message with an attendee and a GUID like that:

      ATTENDEE:urn:uuid:98283...

    The UUID is not a CalServer one, its created by the client (or
    some other server).
    What will happen with that, stored as-is?


c) you mention that there will be an Apple specific REPORT to
    retrieve information about GUID attendees.
    To avoid additional HTTP IO, can we have it that way:

      <?xml version="1.0"?>
      <C:calendar-multiget xmlns="DAV:"
           xmlns:C="urn:ietf:params:xml:ns:caldav"
           xmlns:A="http://calendarserver.org/ns/">
        <prop>
          <getetag/><getcontenttype/>
          <C:calendar-data/>
          <A:attendee-info>
            <A:uuid/>
            <D:principal-URL/>
            <D:displayname/>
            <D:email/>
          </A:attendee-info>
        </prop>
      </C:calendar-multiget>

    Or something similiar. Core point is, that the required info
    can be retrieved in one step (simple GETs become useless ...)

Thanks,
   Helge

... still hoping that there will be an option to make the server do it  
the X-APPLE-UUID way.
--
http://zideone.com/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Wilfredo Sánchez Vega]

On May 15, 2009, at 4:31 PM, Helge Heß wrote:

> Well, IMHO its a very weird balancing of things.
>
> Situation a) UUID attendees
> - clients might break
> - server definitely breaks if clients break
>
> Situation b) UUID in X-
> - client might loose X- (though, thats a theory, no specifics!)
> - server still does NOT break in 99% of the cases, since it
>  fallbacks to emails
>
> So yes, you might loose a distinct primary key. You must be prepared  
> to that anyways, since a client is also free to transmit emails or  
> whatever it wants at any time.

   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.  In this case, I don't care about the  
property value, because the client is dealing with it, and the server  
should not modify it.  This isn't what we are talking about here,  
though.

> I fail to comprehend your position given that:
> a) you fail to name clients which would actually loose your X-
>   property

   I don't mention this because it doesn't matter which clients do it  
or not; your proposed changed don't solve the problem.

> b) clients which might loose your X- property, would still work
>   very well, given that you must deal with email matching anyways

   I'll get to that below.

   Email addresses are obviously important to iMIP, and iMIP isn't  
going away any time soon.  No dispute there.  I don't claim that UUIDs  
work for iMIP, but I'm not implementing an iMIP server; I'm  
implementing a CalDAV server.

   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.  
That should include dealing with whatever URI is in the ATTENDEE  
property.

   The ATTENDEE property value is a delivery address.  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.

   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 important thing is that this data is advisory, and not the  
authoritative delivery address, which remains the value of the property.

   For example:

   You send the server a meeting with:

        ATTENDEE;CN="Wilfredo Sanchez":mailto:wsanchez@...

   Per your suggestion, I look up wsanchez@... in my directory  
system and find the record with ID 1, so I tack on my ID:

        ATTENDEE;CN="Wilfredo Sanchez";X-ID=1:mailto:wsanchez@...

   Now, MIT tells me I can't keep my email address after more than a  
decade past graduation, so I get my directory record updated to wsanchez@...
.  Then you update the meeting my changing the time to the next day.

   What do you propose the server does here?  There is no longer a  
directory record with wsanchez@... 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.  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 wsanchez@...
  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?

   That's pretty good, as it clearly works well enough in this case.

   So what if the in the same day that I lost my mit.edu email, it was  
given to someone else.  So now in the directory, we have a new record  
with ID 2 and my old email address, as well as the old record with ID  
1 and my new email address.  Should we:

        1) use the X-ID because we know better
        2) use the mit.edu email address because that's what the client asked  
for
        3) raise an error to the client and hope that it can tell the user  
something useful

   #1 is the one that works, though still in violation of the spec.  
Note that this situation may seem contrived, and it is, but it is  
something we have to deal with.  Here's a simpler case: the server  
supports server-side iMIP (and hey, by coincidence, ours does).  
Should we send an iMIP message to wsanchez@... as we normally do  
for which ATTENDEEs we don't provide CalDAV delivery, or stick with  
the X-ID, or emit an error?

   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:wsanchez@...

   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:wsanchez@...

   Once again, should the server ignore this change and go with the X-
ID, or go with the address provided by the client?

   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.

        -wsv

_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

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 wsanchez@... 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:abc@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 wsanchez@... 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 wsanchez@...
>  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:wsanchez@...
>
>  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:wsanchez@...
>
>  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@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Wilfredo Sánchez Vega]

   Sorry I'm so slow to reply to these, because this is a good  
conversation to have, and you are making me think about this harder,  
which is good.

   But a bunch of things are landing at the same time here, including  
a conference next week that I have to be ready for.  :-)

   Anyone at Apple WWDC who want to have this conversation in person,  
come find me at the IT Lab after the Calendaring Talk on Tuesday.  
Anyoen at CalConnect this week, I'll be at the Roundtable, time  
permitting.

        -wsv

_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

On 02.06.2009, at 10:32, Wilfredo Sánchez Vega wrote:
>  But a bunch of things are landing at the same time here, including  
> a conference next week that I have to be ready for.  :-)

;-)

>  Anyone at Apple WWDC who want to have this conversation in person,  
> come find me at the IT Lab after the Calendaring Talk on Tuesday.  
> Anyoen at CalConnect this week, I'll be at the Roundtable, time  
> permitting.

I'm leaving on Sunday and won't be at the WWDC, but I'm at the  
Roundtable.

Anyways, iCal server does not honour SCHEDULE-AGENT=CLIENT, it always  
replaces the ATTENDEE with the UUID.

There also seems to be agreement that SCHEDULE-AGENT=SERVER will stay  
the default. (which I dislike, but can't do anything about :-)

Thanks,
   Helge
--
Helge Hess
http://helgehess.eu/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Wilfredo Sánchez Vega]

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 wsanchez@... 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 wsanchez@...
>>  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@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

On 26.06.2009, at 21:22, Wilfredo Sánchez Vega 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.

Well, yes, but there are no such clients. All clients I know of are  
(iMIP) scheduling aware. Which is my core point I guess.

Maybe we should be more specific about what clients we are talking:
- iCal.app  (no plugin API at all, completely proprietrary)
- Evolution (storage API)
- Kontact   (storage API)
- Mozilla   (no real 'storage' API, all done at client level?)
- Outlook   (storage API, iMIP like scheduling API)
any other? emClient? APIs?

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

*All* existing clients _are_ (iMIP) scheduling aware. Its just that  
the scheduling isn't 'pluggable'.
In fact I don't know a single client which has pluggable scheduling  
(or no scheduling!). [we can/could explore some hacks in Outlook, but  
after all users are used to emails]

Its a bit like punishing standard focused clients (iMIP) for doing  
standards.


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

Yes. And standards which introduce new infrastructure w/o (seriously)  
considering backwards compatibility are usually not particulary  
successful.
But yeah, the iPhone will change everything ;-) [I'm actually serious  
on that one]


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

Sure. My point was that the ATTENDEE is usually way more than an  
address for iTIP.

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

Sounds OK. Not sure I can parse the latter. But yes, there are not  
only SMTP email addresses. So if EMAIL is a URL/URN, it would be  
helpful. Not sure.


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

MIT isn't the center of the world either, its just a minor user in the  
overall scope :-) Much less than 0.001% of the users?
I'm not saying that some people won't do it, but they need to be aware  
of much more severe issues than just having wrongly routed meeting  
invitations ...


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

Si, and emails as IDs are much more reliable in such scenarios (and  
others, eg migrations). But OK.


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

IMHO thats a gross misconception. Email sends and reception are highly  
dependend on the actual email setup and configuration. Just because  
iCal server is used as a calendaring server doesn't imply that its  
used as the primary email server nor that the primary will route back  
emails to it. In fact if it isn't the primary, its quite unlikely that  
the back-channel is setup properly (real world ignorant admin thing ;-)
I'm pretty sure that the iMIP back channel is b0rked for a very large  
part of the deployments. Replies will arrive in the clients via eMail,  
but w/o the iCal server getting involved.
(I asked the crystal ball, its going to be that way, trust it!)


>> Anyways, all that is nitpicking, it does not bring us anywhere.
>   Well, it may clarify some requirements.

I guess you need to decide how well you plan to support 'the' other  
clients. For ZideOne, we are probably going to support anything you  
come up with. Other clients will be constrained by resources, politics  
and sanity ;-)
Making it easier for them (by considering their setup), can make the  
relevant standards and servers more successful (IMHO).
Eg Kontact is quite popular in Germany, and it really excels at  
standards. I know no other client which has an iCalendar  
implementation as complete.

At this time even just plain CalDAV is mostly an Apple client thing,  
many servers don't really implement CalDAV, they only do the very  
specific subset required for iCal.app. Eg I was kinda shocked that  
Zimbra doesn't even support GET on event URLs! (probably because  
iCal.app happens to do always use REPORTs to fetch the data ...) And I  
really don't like that situation.
Pushing clients to rework their scheduling does not really help the  
matter ...

>> [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 wsanchez@... 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.

Can't parse your response. The core issue is that other iMIP client  
will have the old address and you can't possibly deal with this,  
whether you write a server or not :-) If you allow iMIP, you need to  
live with its issues (eg reassigned emails). And you have to allow  
iMIP. Which significantly reduces the advantages of UUIDs.


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

I think CalConnect XV decided that (a) won't happen. IMHO its a  
mistake because it badly breaks the standards layering, but well.


>> Anyways, iCal server does not honour SCHEDULE-AGENT=CLIENT, it  
>> always replaces the ATTENDEE with the UUID.
>   That should be fixed now.

Nice. It doesn't really solve the issue that existing clients are  
doing iMIP, hence SCHEDULE-AGENT=CLIENT per default. But it at least  
makes it possible for CalDAV-Sched aware connectors to always inject  
that.

Greets,
   Helge

_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Helge Heß]

Hi,

stupid question: what is supposed to happen if the clients write an  
iCal file with a UID to the server? Eg:

   ATTENDEE;EMAIL="hh@...":urn:uid:299282-29393...

Will the server reject that? Will it rewrite the ATTENDEE URN-UID  
based on the EMAIL? Will it preserve the UID?

Thanks,
   Helge
--
Helge Hess
http://zideone.com/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev

[Cyrus Daboo-3]

Hi Helge,

--On July 1, 2009 1:25:43 PM +0200 Helge Heß <me@...> wrote:

> stupid question: what is supposed to happen if the clients write an iCal
> file with a UID to the server? Eg:
>
>    ATTENDEE;EMAIL="hh@...":urn:uid:299282-29393...
>
> Will the server reject that? Will it rewrite the ATTENDEE URN-UID based
> on the EMAIL? Will it preserve the UID?

If the uuid value is recognized as a valid user on the server it will
re-write the CN= and EMAIL= parameters to match values appropriate for that
principal. If the uuid is not recognized the server will not change the
property at all.

--
Cyrus Daboo

_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@...
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev