[VCARDDAV] Notes from IETF meeting

[Chris Newman <[e-mail]>]

vcarddav notes
--------------
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.