Subject: [VCARDDAV] Groups

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Feb 2008 21:15:19 -0500

Hi folks,
One thing that has been briefly discussed before is the issue of how to 
represent a "group" via a vCard. The idea here is that most address books 
provide some form of "group" support and it would be nice if that could be 
exchanged via vCards as well as the "individual" contact information.

We do have a new KIND property that can have the value "group", but there 
is no property to list the members of the group. So should we have a MEMBER 
property? This could appear multiple times and its value would be a URI. It 
would be handy if the URI could be a urn:uuid where the uuid is actually 
the UID value of a vCard, but I think in that case the UID has to follow 
the uuid format requirements. If that is so should we insist on UID values 
being uuids as per RFC4122. On a CardDAV server the URI could be an http 
URI to a vCard on the server.

-- 
Cyrus Daboo

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 28 Feb 2008 02:54:12 -0200

Cyrus Daboo wrote,

> property? This could appear multiple times and its value would be a URI.

It is a good idea... Membership is a consequence of defining groups. The 
only requirements imposed to implementations would be those which are 
already imposed by the AGENT property, therefore I think it will not harm 
(and it will avoid URIs as ORG values) .

Should text-value embbeded vCards be allowed? The URI approach is clearly 
better, though some device may not support URI resolution, and they may 
prefer to store it as a vCard entity (perhaps with a SOURCE referring to the 
original URI).

> It would be handy if the URI could be a urn:uuid where the uuid is 
> actually
> the uuid format requirements.
>If that is so should we insist on UID values being uuids as per RFC4122.
> On a CardDAV server the URI could be an http URI to a vCard on the server.

I don't think UID values should be REQUIRED to be urn:uuid (and nothing 
else) because of *this* reason, if that is what you meant.
Note that a UID value may be a URI (according to current syntax), and it may 
be useful to allow other kinds of identifiers (for both UID and MEMBER).

(See http://www.ietf.org/mail-archive/web/vcarddav/current/msg00093.html)

Anyway, we should clarify about the UID type: I'm suspicious about automatic 
promotion of uuid-like identifiers to uuid URNs, because an untyped 
identifier of the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  (where each x 
represent an hexadecimal digit) may not be RFC 4122 conformant (yes, it is 
perversion at a extreme, but it is possible); and it is not clear how to 
encode a URI/URN as a UID value.

In order to show our preference for uuids, we can make "urn:uuid" the 
default UID type, with "text-value" being an optional type. Fixed length UID 
are fast to look-up (as Simon said), and uuids do not require any external 
resolution/validation mechanism (other than provided by the application 
itself), thus they are fast to generate.

This would render a flawless "automatic promotion" mechanism (which can be 
applied not only to MEMBER but also to AGENT).

Best Regards,

Javier

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Feb 2008 10:27:19 -0500

Hi Javier,

--On February 28, 2008 2:54:12 AM -0200 Javier Godoy 
<[email-masked]> wrote:

> prefer to store it as a vCard entity (perhaps with a SOURCE referring to
> the original URI).

Allowing an embedded vCard as a MEMBER would be fine. In fact that solves 
the problem of having a group that is a simple "distribution list" - namely 
just a list of email addresses that do not necessarily reference existing 
vCards in the address book. There are use cases for both "distribution 
list" and "member by reference" type of groups.

> Note that a UID value may be a URI (according to current syntax), and it
> may be useful to allow other kinds of identifiers (for both UID and
> MEMBER).
>
> Anyway, we should clarify about the UID type: I'm suspicious about
> automatic promotion of uuid-like identifiers to uuid URNs, because an
> untyped identifier of the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
> (where each x represent an hexadecimal digit) may not be RFC 4122
> conformant (yes, it is perversion at a extreme, but it is possible); and
> it is not clear how to encode a URI/URN as a UID value.
>
> default UID type, with "text-value" being an optional type. Fixed length
> UID are fast to look-up (as Simon said), and uuids do not require any
> external resolution/validation mechanism (other than provided by the
> application itself), thus they are fast to generate.
>
> This would render a flawless "automatic promotion" mechanism (which can
> be applied not only to MEMBER but also to AGENT).

An alternative would be to invent either a new URI scheme for vcard UIDs, 
e.g.:

vcard:12345-56789

Through one could go a lot further at inventing a vcard scheme that 
supported access to arbitrary properties in the vCard. e.g.:

vcard:UID:12345-67890
vcard:FN:Cyrus%20Daboo
vcard:TEL:+1%20123%20456%207890

-- 
Cyrus Daboo

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 28 Feb 2008 16:11:01 -0200

Hi Cyrus,

On February 28, 2008 1:27 PM Cyrus Daboo wrote,

> An alternative would be to invent either a new URI scheme for vcard UIDs,

Interesting.

vCard's UIDs are "globally unique identifier" at least since version 2.1.
However these identifiers are not URIs... I strongly suspect URI were not
avoided because of a design choice, because URIs (as we currently know them)
were not mature by the time of RFC 2426. Thus the actual intent of RFC 2426
and vCard 2.1 authors was either "UIDs are URI" or "UIDs are URN", and we
have to reword it using updated terms.

It must be noted that "12345-56789" is a weak *globally* unique identifier
(though it is a valid UID). Are UID really required to be globally unique,
or just unique within the application domain?

The vcard scheme would be, by nature, a lenient identifier system (as
urn:publicid is).

> vcard:TEL:+1%20123%20456%207890

The first example univocally represents a resource up to the "global
uniqueness" of the UID property itself, but the others do not (unless
several properties were combined). It attaches entity properties to identity
issues (as opposite from a surrogated identifier approach), and it makes
difficult to assert beforehand whether the identifier references a single
vCard or a set of vCards with a common property (e.g. all the people with
TEL:+1 123 456 7890).

Moreover, the "arbitrary properties" approach provide a search feature that
may be useful, but it is much more expensive than mapping UIDs to resource
locations. I think we should not deal with this issue when only trying to
identify a vCard instance, but we may resume it later if such a search
feature is desirable.

Best Regards,

Javier