Subject: Re: [VCARDDAV] New drafts for review

From: Simon Perreault <[email-masked]>
Date: Fri, 01 Mar 2013 10:40:51 +0100

Le 2013-02-28 23:17, Ciny Joy a écrit :
> Thanks for reviewing, Simon. Mike may be able to answer your question
> better. We were looking at this from the point of how would one
> search for a resource to schedule. In that case we need something to
> decide whether a particular vCard should be included in the search
> result or not.

Right. In that case one could just search for vCards with the necessary 
properties.

Another problem I see is duplication of information. You have it 
explicitly "schedulable" in the OBJECTCLASS property, and you also have 
it implicitly by the properties the vCard has. What if the two become 
out of sync? As an example, what if an OBJECTCLASS:schedulable vCard 
ends up losing one of the properties that make it schedulable? This 
could happen for example after having been edited by a vCard UA that 
doesn't know about the OBJECTCLASS property, or even by a vCard UA that 
does know about OBJECTCLASS but doesn't know about the "schedulable" class.

I'm all for defining classes of vCards as sets of necessary properties, 
but I'm not convinced about OBJECTCLASS.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Mike Douglass <[email-masked]>
Date: Fri, 01 Mar 2013 09:41:37 -0500

On 03/01/2013 04:40 AM, Simon Perreault wrote:
> Right. In that case one could just search for vCards with the 
> necessary properties.
>
> explicitly "schedulable" in the OBJECTCLASS property, and you also 
> have it implicitly by the properties the vCard has. What if the two 
> become out of sync? As an example, what if an OBJECTCLASS:schedulable 
> vCard ends up losing one of the properties that make it schedulable? 
> This could happen for example after having been edited by a vCard UA 
> that doesn't know about the OBJECTCLASS property, or even by a vCard 
> UA that does know about OBJECTCLASS but doesn't know about the 
> "schedulable" class.
>
> I'm all for defining classes of vCards as sets of necessary 
> properties, but I'm not convinced about OBJECTCLASS.
>
There were a number of motivations for objectclass - perhaps not all 
made explicit.

First we ended up in a hole trying to define what 'kind' of thing we 
had. Just trying to guess from the properties that appear doesn't work 
too well (otherwise why would anybody have invented KIND). Also some 
properties are allowable for different kinds of things. You might have a 
calendar user address - that doesn't necessarily make you schedulable - 
it just means you have a calendar.

There's the mapping from ldap to vcard. I at least am trying to make as 
much information as possible available from enterprise directories via a 
carddav gateway. I'd liek to make some of the information in there 
available to the end user or systems.

There's the defining of default behavior - if we know an entity is 
schedulable we can specify default behavior when properties are missing

I'd suggest that most of the interoperability problems we've encountered 
in calendaring are due to different interpretations of what to do when 
faced with a particular set of properties.  The objectclass approach 
allows us to specify how a particular set of properties and defaults are 
to be handled.

Scheduling takes place asynchronously - it happens after the event is 
stored in the users calendar. I'd like to tell them up front that the 
entity they are trying to schedule is not a schedulable entity - rather 
than try to notify them at some time in the future. We have many rooms 
on our campus which have a presence as directory entities but cannot be 
scheduled. Some even have calendars - I'd not have much success trying 
to schedule our theater but I might want to see what's happening there.

MikeD