vcarddav notes
IETF 77 Anaheim
Wednesday March 24, 2010
--------------
Agenda
 http://www.ietf.org/proceedings/10mar/agenda/vcarddav.txt

**vCard 4.0
 http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-10
 http://tools.ietf.org/agenda/77/slides/vcarddav-0.pdf

Discussion of "XML" property.  Brief controversy over whether to allow two encodings -- is it OK embed vcard-text-format-encodable properties in XML properties?  Sense of the room is to not allow that.  Julien suggests "MUST NOT generate" but it is still equivalent.

Discussion about content of "XML" property.  Is it a fragment or an XML element?  Sense of room is that content of "XML" property should be an XML element, and SHOULD have its own namespace.  Element is to be parsed as if a child of the vcard element.

Also drop the idea of default namespace for content of "XML" property.

Element can be treated as a full document if <?xml ...> header added.

Q: Has anyone implemented pid and pidmap stuff?
A: No comment from room

No other issues before WGLC?
Appear to be no other issues.

**vCard XML
 http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-02
 http://tools.ietf.org/agenda/77/slides/vcarddav-1.pdf

Issue: restrict extensions to live underneath vcard container, not inside <n> container.

Issue: remove <text> wrappers around contents of <adr> sub-elements?  Or should it be a wrapper around the outside of them?  Would be nice to get rid of them, but maybe can't due to the suffix example under <n> since it's a list of text elements.

Discussion: use attributes for property syntax?  Need to be careful of schema compatibility.  Probably can't.

Issue: difference between <pobox><text/></pobox> vs. <pobox/>
* List with one empty string element, vs. empty list?
* vCard text format can't represent this
Proposal: keep top-level wrapper, but if list is empty in vCard, then empty text container is not used in XML format.

How to translate X-props and VND-props?
=> take issue to the list

**vCard Service Type
 http://tools.ietf.org/html/draft-daboo-vcard-service-type-00
 http://tools.ietf.org/agenda/77/slides/vcarddav-2.pdf

Defines service-type property on IMPP properties; continue as individual submission to avoid blocking base specs.  Also want to general use how to specify the service for arbitrary properties.

**Directory Gateway
 http://tools.ietf.org/html?draft=draft-daboo-carddav-directory-gateway-00
 http://tools.ietf.org/agenda/77/slides/vcarddav-3.pdf

Open issue: should we allow multiple gateways?  Proposal: no
Issue: is this just a discovery mechanism?  Maybe "read-only" is not necessary.
Issue: how is this different from other shared address books?
Issue: general discovery problem?

Keep as individual for now.

CardDAV status: blocked on vCard4 and SRV registry document.