Subject: [VCARDDAV] Notes from IETF meeting

From: Chris Newman <[email-masked]>
Date: Wed, 24 Mar 2010 11:10:07 -0700

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.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 24 Mar 2010 11:19:31 -0700

> vcarddav notes

Chris, thanks for doing this. Posted to the proceedings site.

Please send comments about notes to the list and I'll make new version 
of minutes and post it the proceedings.

Marc.
-- 
=========
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
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 25 Mar 2010 15:31:23 +0100

Hi,
because this is my first post to the list a short introduction may be in 
order. My name is Florian Zeitz, I'm currently a student at the 
RTWH-Aachen in Germany and since recently member of the XSF.
The later is what go me interested in the vCard work, as it is likely 
going to be used in XMPP.

On 2010-03-24 at 19:10 Chris Newman wrote:
> Proposal: keep top-level wrapper, but if list is empty in vCard, then
> empty text container is not used in XML format.
>
I'm the person from the XMPP room who thought it would be worth 
stressing this point and as the outcome is different from what I'd 
suggest and chiming in on a real life discussion via XMPP turns out to 
be hard I'd like to make my point again:
What I'd suggest is leaving empty elements (which are part of a 
"structured field") e.g. <pobox/> out completely.
The reason for keeping it I heard in the discussion was that it makes 
conversion to the "normal" vCard format easier. I personally don't think 
so. Checking whether an element is empty or doesn't exist is not a lot 
more complex than only checking whether it is empty.
If you are creating vCards in vCardXML you'll have to make sure you 
create empty elements even though they'll tell you nothing.
Someone present at IETF77 (I didn't quite catch the name, sorry) also 
mentioned he dislikes it when people include empty elements just because 
the Schema dictates it. I know it doesn't really count as an argument, 
but it makes the XML look 'ugly' IMHO.
I could also make a point about unnecessary overhead, but considering 
the amount of data we're talking about that would probably cause 
hilarity to ensue.

--
Florian Zeitz

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Mar 2010 17:22:00 +0100

On 25.03.2010 15:31, Florian Zeitz wrote:
> ...
 > ...

That was me.

Ugliness of the XML is one thing.

Potential interop problems is another. People like to leave out useless 
markup when they get away with it, so we should make sure that 
implementations are consistent in whether they allow it or not.

Best regards, Julian

---

From: Simon Perreault <[email-masked]>
Date: Thu, 25 Mar 2010 10:10:09 -0700

> "structured field") e.g. <pobox/> out completely.

Makes sense. Unless someone disagrees, I'll modify the schema accordingly.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 25 Mar 2010 10:19:34 -0700

Hi Simon,

> Makes sense. Unless someone disagrees, I'll modify the schema accordingly.

That is fine for these "structured" values - i.e. just make the 
sub-elements optional. But in other cases we may not want do that. e.g. a 
property with no value:

DESCRIPTION:

<description>
  <text />
<description>

or an empty parameter value. Should we say that <text /> should not be 
present?

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 25 Mar 2010 10:21:03 -0700

On 2010-03-25 10:19, Cyrus Daboo wrote:
> sub-elements optional. But in other cases we may not want do that. e.g.
> a property with no value:
>
> DESCRIPTION:
>
> <description>
> <text />
> <description>
>

Right. Properties *always* have values. Therefore the <text/> needs to 
be present.

Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 30 Mar 2010 14:58:47 -0600

>> a property with no value:

Where is the <description/> element defined? I ask because that the
early Jabberites added such an element to XEP-0054, but I can't find it
in RFC 2426 or draft-ietf-vcarddav-vcardrev.

> Right. Properties *always* have values. Therefore the <text/> needs to

Agreed (or one needs to leave out the property parameter altogether).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/