Subject: [VCARDDAV] ietf78 Maastricht meeting notes

From: Marc Blanchet <[email-masked]>
Date: Wed, 28 Jul 2010 12:22:33 +0200

based on Cyrus notes and mine, here is meeting notes. Please send diffs 
to me. Thanks Cyrus.

Marc.

====================

IETF Vcarddav working group
IETF 78 meeting, Maastricht, NL
July 28th 2010, 10h30-11h30

1. Administrativia

2. vcardrev wglc comments (Perreault, Resnick)
  draft-ietf-vcarddav-vcardrev

WGLC done. Issues fixed. Feedback after WGLC - some are being fixed.
Remaining issues:
- Escaping proposals:
     \; is always treated as an escape, plain ; may be a separator
     \t - no consensus to do this
     \uXXXX - no consensus to do this
- PID and LANGUAGE parameter:
     Proposal - put the "language grouping" inside the LANGUAGE 
parameter value rather than overload the PID. Make cardinality 
independent of PID. Concensus in the room to implement the proposal.
- a new rev of the draft will include these changes. Changes will be 
listed in an email to the wg mailing list. No additional WGLC will be 
done.  After 1 week review of the changes, then will be sent to IETF LC.

3. vcardxml wglc comments (Perreault)
  draft-ietf-vcarddav-vcardxml

WGLC done. Issues fixed.
Recent suggestion to map LANGUAGE parameter to xml:lang - no consensus 
to use xml:lang. The <language> element is not split into sub-elements 
(given the language grouping change above).
- new rev is to update to include the vcardrev language grouping into 
XML.  Changes will be listed in an email to the wg mailing list. No 
additional WGLC will be done.  After 1 week review of the changes, then 
will be sent to IETF LC.

4. carddav issue in RFC queue (Daboo, Touch)

service type registration issue. Joe Touch will send a sentence to 
Alexey and Cyrus and Chairs. SRVs already registered with dns-sd. IESG 
to fix alias issue.

5.Recharter (Chair, group)

* vCard 4 base:

* vCard in XML:

* CardDAV: service type registration issue.
  service name has been registered in the dns-sd Cheshire registry. this 
will be integrated into the new ports-service IANA registry. Joe Touch 
will send a sentence to Alexey and Cyrus and Chairs. IESG to fix alias 
issue. For SRV processing, If TXT record is there, MUST use. not 
required to have one.

* Charter/future:

Barry to work on social networking drafts.
Need to encourage someone to do LDAP mapping document.
Issues with convergence with Portable Contacts, OMA, and W3C API for 
contacts etc? Telechat? Thomas Roessler to setup.

Conclusion - continue work on the items in the charter (social 
networking, ldap) and revisit re-charting in Beijing based on WG 
activity between now and then.
-- 
=========
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: Wed, 28 Jul 2010 14:42:16 +0200

> based on Cyrus notes and mine, here is meeting notes. Please send diffs 
Thank you for writing this up.
I have some questions/remarks about some of the decisions and myself to blame for not being present. Feel free to scold me if you feel I should better be quiet.

I don't really understand this. IMHO this is not overloading the PID parameter. It is meant to uniquely identify a property, different language versions are logically the same property therefore should have the same PID. I didn't really catch a compelling reason to change this and it seems to me it only complicates parsing. It would be great if someone could clarify this decision for me.

> to use xml:lang.
So, what I grasped is that the consensus was "nice to have for XML folks, but not worth the special casing".
I suggested it, so of course I'm really biased, but personally the nice to have outweighs the special casing for me. It shouldn't be a lot of hassle to add an extra attribute while adding the LANGUAGE parameter and it would allow for constistency in environments where xml:lang is being used (e.g. I'm thinking of embedding vCards in XMPP where the stream and body tags usually have xml:lang specified).

--
Florian Zeitz

---

From: Simon Perreault <[email-masked]>
Date: Wed, 28 Jul 2010 15:01:22 +0200

Florian Zeitz wrote, on 07/28/2010 02:42 PM:
> I don't really understand this. IMHO this is not overloading the PID parameter.
> It is meant to uniquely identify a property, different language versions are
> logically the same property therefore should have the same PID. I didn't really
> catch a compelling reason to change this and it seems to me it only complicates
> parsing. It would be great if someone could clarify this decision for me.

PIDs are for synchronization. Here's a use case: you have a vCard translated in
25 languages, and you add a 26th translation. Should you synchronize only the
new data or all of the vCard? With the same PID for every language, you will
synchronize everything.

> I suggested it, so of course I'm really biased, but personally the nice to have
> outweighs the special casing for me. It shouldn't be a lot of hassle to add an
> extra attribute while adding the LANGUAGE parameter and it would allow for
> constistency in environments where xml:lang is being used (e.g. I'm thinking of
> embedding vCards in XMPP where the stream and body tags usually have xml:lang
> specified).

Two problems with xml:lang:
1. Special case, unlike other parameters.
2. Current XML libraries treat xml:lang specially and differently.

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: Wed, 28 Jul 2010 15:11:41 +0200

Hi Marc,

--On July 28, 2010 12:22:33 PM +0200 Marc Blanchet 
<[email-masked]> wrote:

>      Proposal - put the "language grouping" inside the LANGUAGE parameter
> value rather than overload the PID. Make cardinality independent of PID.
> Concensus in the room to implement the proposal.

So Simon, Joe and I had a further discussion about this over lunch. We came 
to the conclusion that including the grouping information in the LANGUAGE 
parameter value would not be ideal. Instead we agreed that a separate 
parameter would be better. Rationale included:

1) Allowing for properties to varying based on other options (e.g. have 
plain text and rich text variants, different image or audio formats etc).

2) Putting the grouping in the parameter value would make it much harder to 
filter/search for properties based on language alone. The expressions 
needed to search the value might not be simple comparison or starts-with 
type operations.

-- 
Cyrus Daboo

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 28 Jul 2010 16:41:57 +0200

Le 10-07-28 15:11, Cyrus Daboo a écrit :
> So Simon, Joe and I had a further discussion about this over lunch. We
> came to the conclusion that including the grouping information in the
> LANGUAGE parameter value would not be ideal. Instead we agreed that a
> separate parameter would be better. Rationale included:
>
> 2) Putting the grouping in the parameter value would make it much harder
> to filter/search for properties based on language alone. The expressions

I agree. if the language parameter remains the usual one which contains 
en,fr,... , then it is atomic to its semantics.

Marc.