Re: [VCARDDAV] Groups

Hi Chris,

> Newman wrote,
>
> It's not clear to me the architecture benefits from treating a group as an
> explicit object, rather than treating a group as an implicit object that
> results from a search.

The KIND attribute was first thought for representing organizations as vCard 
entities (kind="org" vs. kind="individual"). It addresses the situation 
explained in Section 5.1.5 of draft-resnick-vcarddav-vcardrev-01. Then Cyrus 
a suggested a "group" kind, on the same basis (thus groups are no longer 
represented as fake "individual" instances).

He pointed out that  [[

  iCalendar has a CUTYPE parameter for ATTENDEE's defined as:

     cutypeparam        = "CUTYPE" "="
                         ("INDIVIDUAL"          ; An individual
                        / "GROUP"                   ; A group of individuals
                        / "RESOURCE"            ; A physical resource
                        / [...]
]]

Note that KIND alters the traditional (version <= 3) semantic of the vCard 
entity, which now holds only for the "individual" kind.

For instance, one would not expect a N property within an "org" or "group" 
vCard). The "group" is different from "org" because only the latter is 
related to ORG properties on the member-side (thus member's "ORG" might 
identify the organization of which the entity is "member of", up to name 
equivalence). It is not clear to me which other assumtions are made for the 
"group" kind.
(btw, I would like to see it briefly explained somewhere in the spec...)

> If we create what is fundamentally a new type of vCard object it's going 
> to
> require a lot more change to existing vCard software than if we add an
> attribute and a search model to instantiate a group implicitly.

I'm not sure about this assertion. I think no special handling is REQUIRED 
for the KIND property (though an application MAY benefit from it).

A minimal port from version 3 to version 4 may treat "kind" as a new 
property with no particular meaning, delegating to the user the 
responsability of deciding which semantics applies for that kind,
Besides, the default "individual" kind makes unnecessary to deal with KIND 
at all if all vCards are interpreted from the RFC 2426 (individual-only) 
point of view.

On the other hand an enhanced application might use the kind value for 
displaying the vCards according to their kind and/or disallowing some 
properties which do not make sense for that kind.

Best Regards

Javier

P.S. I hope I had understood your concern in the right direction... 

_______________________________________________
VCARDDAV mailing list
VCARDDAV@ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav