Subject: [VCARDDAV] IETF79 vcarddav wg meeting notes

From: Marc Blanchet <[email-masked]>
Date: Mon, 15 Nov 2010 13:46:50 -0500

Hello,
  please find the minutes of our meeting. Please send any modifications 
to me directly.

Marc, co-chair.

--------------------

IETF Vcarddav working group
IETF 79 meeting, Beijing, China
November 10th 2010, 15h10-16h10

1. Administrativia

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

- i18n email
   - Problem: How to allow Unicode characters in EMAIL. Choose eai? 
utf-8? ...
   - Resolution: None. Chairs will discuss with area directors about.

- Restoring N format
   - Problem: Current format for N is not backward compatible.
   - Resolution: Go back to vCard 3's format and allow multiple items in
each component.

- DDAY, BIRTH, DEAH
   - Problem: New properties which are not widely implemented.
   - Resolution: Remove them from base vCard 4. (Could be defined as an
extension.)

- Remove fields from ADR
   - Problem: PO box and extended address fields are misunderstood and
not interoperable.
   - Resolution: Keep fields, but indicate that they SHOULD be empty.

- Link LABEL to ADR
   - Problem: No way to know which LABEL is associated with which ADR.
   - Resolution: Remove LABEL property and make it a parameter of ADR.

- Remove BINARY
   - Problem: BINARY value type is redundant with data: URI scheme.
   - Resolution: Remove BINARY property, remove FMTTYPE and ENCODING
parameters.

- SEX
   - Problem: Biological vs psychological semantics are unclear. Allowed
values are un-intuitive and restrictive.
   - Resolution: Rename SEX to GENDER. Change values to (male, female,
<free-form text>). IANA registry for additional values that could be 
reserved.

- TEL property
   - Problem: Previous parsers of TEL property values cannot parse tel: 
URIs.
   - Resolution: Default to free-form text, but SHOULD reset to a URI.

- CALSCALE parameter
   - Problem: Having only a single pre-defined value makes this parameter
useless.
   - Resolution: Refer to iCalendar and create an IANA registry for 
calendar types.

- Calendar properties
   - Problem: FBURL, CALADRURI, and CALURI are new for vCard 4. Maybe
better suited for an extension.
   - Resolution: Keep them.

- Date ranges
   - Problem: Proposal to add a new parameter for identifying validity
ranges for properties.
   - Resolution: Do not add.

- KIND property
   - Problem:
     - KIND property is new for vCard 4.
     - Maybe BEGIN:VGROUP would be better.
     - Semantics for KIND:thing are vague.
   - Resolution:
     - Reduce the list to the ones we think we understand well right now.
     - If you want new ones registered, you have to write a draft that
profiles the fields that make sense for that kind.

- RELATED property
   - Problem: Property is new for vCard 4. Allowed values do not make
consensus. Multiple types are impossible.
   - Resolution:
     - Use the XFN 1.1 taxonomy.
     - Allow a list of types.

- Synchronization
   - Problem: Synchronization is new for vCard 4.
   - Resolution: Keep it.

- CATEGORIES property
   - Problem: Would be nice to use URIs as tags.
   - Resolution: Do not do this. (Could be specified in an extension.)

- VERSION parameter
   - Problem: VERSION parameter is useless, violates DRY.
   - Resolution: None. ("Take it to the list.")
     - Proposal: Drop it. Specify 1.0 in text.

- CLASS parameter
   - Problem: Not used in practice. Interoperability is bad.
   - Resolution: Drop it.

- Case sensitivity
   - Problem: Case causes interoperability issues in practice.
   - Resolution: Output SHOULD be upper-case. Accept both.

- New ACCOUNT property
   - Problem: Proposal for a new ACCOUNT property.
   - Resolution: Reject proposal. (Could be added in an extension.)

- REV property
   - Problem: Proposal for allowing date resolution.
   - Resolution: Reject proposal.

- Cardinality notation
   - Problem: Notation is new, people are unfamiliar with it.
   - Resolution: Adopt ABNF notation.

3. Charter discussion
  Concensus was that there are possible additional work items. Next IETF 
should have a vcarddav meeting to discuss these.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 28 Nov 2010 11:00:28 +0000

On 15 November 2010 18:46, Marc Blanchet <[email-masked]> wrote:

>  please find the minutes of our meeting.

I regret that I was unable to participate.

>  - Resolution: Remove them from base vCard 4. (Could be defined as an

I object most strongly to this; for all the reasons given in previous
discussions.

>  - Resolution: Remove LABEL property and make it a parameter of ADR.

hCard currently uses LABEL for non-granular addresses. How will they
be catered for if this change occurs?
Is hCard perhaps in error in its current behaviour?

> <free-form text>). IANA registry for additional values that could be

For issues around plain text values for these items, see:

    http://www.sarahmei.com/blog/2010/11/26/disalienation/

What use is SEX="Ada Lovelace"?

>  - Resolution: Refer to iCalendar and create an IANA registry for calendar
> types.

It does *not* make the parameter useless, it makes it extendable.

It is not clear from the wording of the proposed resolution that the
new parameter will be kept. Is that the case?

>  - Resolution: Output SHOULD be upper-case. Accept both.

Why upper-case? [Genuine question;  not meaning to challenge]

Regards,

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Nov 2010 08:44:59 -0500

> be catered for if this change occurs?

How about this?

ADR;LABEL="My non-granular address":;;;;;;

> What use is SEX="Ada Lovelace"?

I think that's the wrong question to ask. It has been made very clear on
this mailing list that people want this. At this point, it's better to
ask "Why not allow it?"

> new parameter will be kept. Is that the case?

It will be kept.

> Why upper-case? [Genuine question;  not meaning to challenge]

Because that's what is most commonly used in practice right now.
Ensuring that your output is upper-case (we're talking about property
and parameter names here) is a way to avoid some interoperability issues.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca