Subject: [VCARDDAV] draft-george-vcarddav-vcard-extension

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Jul 2009 10:53:38 -0400

Robins George and I have written up a starting point for
social-networking extensions to vCard data:
  http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension

It's very rough right now, intended as a place to start in discussing
what should be there.  Comments, please.

Chairs: may we have some time on the agenda in Stockholm to talk about this?

Thanks...
Barry

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 15 Jul 2009 00:09:09 -0300

> what should be there.  Comments, please.

Here are my 2 cents.

For interoperability, it would be useful if implementations not aware of the
social-networking extension could treat
accountServiceHomepage, OpenID, socialProfile and photoAlbum as URI (indeed,
these new properties add additional semantics on URI, but a general fallback
as "URI" may be acceptable)

See http://www.ietf.org/mail-archive/web/vcarddav/current/msg00460.html

About DEPICTION,  I understand it is a list of URIs about something else, but
without references to the depicted objects. Is it correct?

Some other comments and suggestions:

> The basic notion of 'depiction' could also be extended to deal with
> multimedia content (video clips, audio).
Consider adding a type parameter, with media-type valuespace.

> revised version of this draft document will be submitted to the RFC  editor
> as a Proposed Standard
See RFC 2026 for the difference between Experimental and Proposed Standard.
According to your description I think it fits better as Experimental.
Note that an Standard Track RFC will NOT be required for specifying extension
elements, as long as they do not modify other elements defined in Standard
Track RFCs (see section 11.2.1 of draft-ietf-vcarddav-vcardrev-08)

4. Property socialCode
>
>   Special notes:  This property MUST include the parameter "TYPE" to
>       specify the type of social network code being used.  There are no
>       predefined values for "TYPE", here -- the types will be
>       understood (or not) by the vCard users.

Either specify a registry of socialCode types, mantained by IANA (I'm not sure
about the requirements for creating such registry),
or mandate every type to begin with "x-" in order to be forward-compatible
with a future official registry.

>Property: interest
>Property: topicInterest

See the discussion about CATEGORIES enhanced.

http://www.ietf.org/mail-archive/web/vcarddav/current/msg01063.html

>  Informative References

RFC 2425, 2426, 4770 will be obsoleted by draft-ietf-vcarddav-vcardrev;
reference the latter.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 15 Jul 2009 07:29:44 -0400

On Tuesday 14 July 2009 23:09:09 Javier Godoy wrote:
> 4. Property socialCode
>
> Either specify a registry of socialCode types, mantained by IANA (I'm not
> sure about the requirements for creating such registry),

No need to create a new registry. The second registry in section 11.3.5 of 
draft-ietf-vcarddav-vcardrev-08 is where it should go.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 15 Jul 2009 11:42:11 -0400

> Chairs: may we have some time on the agenda in Stockholm to talk about this?

sure.

note to the wg: while we requested 2 hours slot, we got a 1 hour slot.
Therefore, we will have to be short and clear in our
presentations/discussions...

Marc.

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

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca