Subject: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-12.txt

From: [email-masked]
Date: Mon, 12 Jul 2010 08:30:28 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : vCard Format Specification
	Author(s)       : S. Perreault, P. Resnick
	Filename        : draft-ietf-vcarddav-vcardrev-12.txt
	Pages           : 83
	Date            : 2010-07-12

This document defines the vCard data format for representing and
exchanging a variety of information about individuals and other
entities (e.g., formatted and structured name and delivery addresses,
email address, multiple telephone numbers, photograph, logo, audio
clips, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-12.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Jul 2010 12:13:33 -0400

> 	Filename        : draft-ietf-vcarddav-vcardrev-12.txt

This revision addresses comments received during WGLC, as well as a
bunch of them received afterwards.

WGLC comments were received from:
- Markus Lorenz
- Cyrus Daboo
- Javier Godoy

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 12 Jul 2010 12:16:27 -0400

> bunch of them received afterwards.

Forgot to add: here's the change log!

   o  Fixed example of LANGUAGE cardinality.

   o  Added note about YYYY-MM date format.

   o  Fixed appendix A.

   o  VERSION property must come first.

   o  Fixed mistake in PID example.

   o  Removed two changes from Appendix A which were probably intended
      to go into this change log section.

   o  Explicitly state that the value for the BEGIN and END properties
      is case-insensitive.

   o  Removed the SORT-STRING property.  Created the SORT-AS parameter.

   o  "T" and "Z" in dates and times are now mandatory uppercase.

   o  Added the "version" MIME parameter.

   o  More consistent capitalization.

   o  Added missing "ANNIVERSARY" in name production rule.

   o  Added missing calscale-param in param production rule.

   o  Moved definition of GEO and TZ parameters to section 5.

   o  Simplified discussion of encoding.

   o  Removed restriction for "work" and "home" values of TYPE parameter
      w.r.t. the KIND property.

   o  XML value may now be binary.

   o  Created VERSION parameter for XML.

   o  BIRTH and DEATH can now have URI values.

   o  Created the FMTTYPE parameter.

   o  KEY can now take a text value.

   o  Added references to RFC 5545 (iCalendar).

   o  Added namespace column in parameters registry.

Simon

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 12 Jul 2010 14:49:28 -0400

To the wglc commenters: does the new revision answer your comments?

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: Daisuke Miyakawa <[email-masked]>
Date: Tue, 13 Jul 2010 13:57:52 +0900

I'm glad to see the new revision =)

> 3.2. ABNF Format Definition
> ...
> vcard = "BEGIN" ":" "VCARD" CRLF
>             1*contentline
>              "END" ":" "VCARD" CRLF
>       ;A vCard object MUST include the VERSION and FN properties.
> ...

> 6.7.9.  VERSION
> ...
> Special notes:  This property MUST be present in the vCard object,
>       and it must come first.

Then, I'd like the section 3.2 have must-come-first statement, like this:

> vcard = "BEGIN" ":" "VCARD" CRLF
>            "VERSION" ":" "4.0" CRLF
>             1*contentline
>              "END" ":" "VCARD" CRLF
>       ;A vCard object MUST include the VERSION and FN properties, and
VERSION must come first.

Thanks,

2010/7/13 Marc Blanchet <[email-masked]>

> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

-- 
Daisuke Miyakawa (宮川大輔)
[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Tue, 13 Jul 2010 08:58:00 -0400

On 2010-07-13 00:57, Daisuke Miyakawa wrote:
> I'd like the section 3.2 have must-come-first statement, like this:
> 

Consider it done.

Simon

---

From: Markus Lorenz <[email-masked]>
Date: Sun, 18 Jul 2010 16:32:38 +0200

> To the wglc commenters: does the new revision answer your comments?

My comments are answered, yes. Thanks.

But I've got another question concerning the LANGUAGE property examples.
The following is an illegal example:

     BIRTH;LANGUAGE=fr:Ville de Quebec
     BIRTH:Quebec City

Can I assume that if a LANGUAGE parameter is present, it MUST be present
for every property representing the same data? I think this is not
explicitly stated in the specification. The difference to the legal example

     BIRTH;LANGUAGE=fr:Ville de Quebec
     BIRTH;LANGUAGE=en:Quebec City

is just the missing LANGUAGE parameter in the second property. The
specification says in "5.1. LANGUAGE":

   Properties with different LANGUAGE parameters that represent the same
   data count as 1 toward cardinality [...]

>From this one could assume that the same data could be represented by
two entries of the same property with one present and one absent
LANGUAGE parameter, because the LANGUAGE parameters are obviously
different. The value for the absent LANGUAGE parameter (if needed at
all) could come from the MIME header.

---

From: "Javier Godoy" <[email-masked]>
Date: Sun, 18 Jul 2010 13:22:36 -0300

Markus Lorenz wrote:

> I've got another question concerning the LANGUAGE property examples.
>for every property representing the same data?

Yes. In this case it MUST be present because BIRTH is (0,1) and the omission 
of LANGUAGE makes the second ocurrence a different logical property.
Note however that the following example is legal because there are two 
instances of TITLE:

TITLE;LANGUAGE=fr:Patron
TITLE:Something else

>The specification says in "5.1. LANGUAGE":
>

I think your interpretation is technically right, but I wouldn't like 
depending on an external MIME header in order to determine the validity of the 
vCard instance.
For instance, the following example would be legal only if Content-Language is 
different from "fr":
 BIRTH;LANGUAGE=fr:Ville de Quebec
 BIRTH:Quebec City

Perhaps we should require that [[
 Properties with no PID and no LANGUAGE parameters are logically different 
from any other property, thus each occurence count as 1 towards cardinality.
]]

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Jul 2010 08:44:55 -0400

> all) could come from the MIME header.

How about we add this sentence?

"Properties without a LANGUAGE parameter always count as 1 toward
cardinality by themselves."

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Jul 2010 08:46:13 -0400

On 2010-07-18 12:22, Javier Godoy wrote:
> Properties with no PID and no LANGUAGE parameters are logically
> different from any other property, thus each occurence count as 1
> towards cardinality.
> ]]

I think this is better than my proposal!

Thanks,
Simon

---

From: Markus Lorenz <[email-masked]>
Date: Tue, 20 Jul 2010 00:29:41 +0200

>> different from any other property, thus each occurence count as 1

I think that would make it clear. Thanks.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Jul 2010 10:55:44 -0400

> Note however that the following example is legal because there are two

I worry about this situation, because (1) it feels like an error --
and it's likely that it would usually be an error, rather than an
intended situation, and (2) it's an error that's very easily made.

The problem is that I *can* see situations where it would be
intentional.  For example, if we expand the example above:

  TITLE;LANGUAGE=fr:Directeur de la recherche
  TITLE;LANGUAGE=en:Director of Research
  TITLE:Chair, vCardDAV working group

Here we clearly have two different titles, one of which is presented
in two languages, and the other of which is presented in an
unspecified language.

On the other hand, this one is clearly an error ("clearly", as the
eye, not the computer, sees it):

  TITLE;LANGUAGE=fr:Directeur de la recherche
  TITLE;LANGUAGE=en:Director of Research
  TITLE:Direktor für Forschung

If the default language for this vCard is German, we can see how this
happened.  The trouble is that the computer can't distinguish these
cases, and we have to rely on the creator of the vCard to get it
right.  Hm.  How has that worked out for us in the past?

> depending on an external MIME header in order to determine the validity of
> the vCard instance.
> For instance, the following example would be legal only if Content-Language
> is different from "fr":

How about this text, just to really drive the point home:
-----------------------------------------
OLD
   Properties with different LANGUAGE parameters that represent the same
   data count as 1 toward cardinality and MUST have the same PID value
   if the PID parameter is used.  This is because there is logically a
   single property which is expressed in multiple languages.

   Therefore, since BIRTH [...]

NEW
   Properties with different LANGUAGE parameters that represent the same
   data count as 1 toward cardinality and MUST have the same PID value
   if the PID parameter is used.  This is because there is logically a
   single property which is expressed in multiple languages. Properties with
   no PID and no LANGUAGE parameters are logically different from any
   other property, thus each occurence count as 1 towards cardinality.

   One must be particularly careful when using LANGUAGE parameters with
   properties that may have cardinality greater than one.  If a LANGUAGE
   parameter is specified on ANY instance of such a property, then one
   MUST be specified on ALL instances that are translations of the same
   property value.  An absent (or erroneously missing) LANGUAGE parameter
   creates a new value, unrelated to the others (or constitutes an error, if the
   PID parameters are the same).

   For example, this represents someone with two different titles, the first of
   which is presented in two languages:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:Chair, vCardDAV working group

   This represents someone with one title, presented in three languages:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:LANGUAGE=de:Direktor für Forschung

   And this is probably an error, because the German version is missing its
   LANGUAGE parameter:
      TITLE;LANGUAGE=fr:Directeur de la recherche
      TITLE;LANGUAGE=en:Director of Research
      TITLE:Direktor für Forschung

   Because such errors are not automatically detectable, extra care is
   needed to get this right.

   Since BIRTH [...]
-----------------------------------------

Barry

---

From: Simon Perreault <[email-masked]>
Date: Wed, 21 Jul 2010 11:02:30 -0400

On 2010-07-21 10:55, Barry Leiba wrote:
>    property value.

+1, with "and MUST have a PID parameter with the same value".

The PID parameter is useful in case you have this:

TITLE;LANGUAGE=fr:Directeur de la recherche
TITLE;LANGUAGE=en:Director of Research
TITLE;LANGUAGE=fr:Président, groupe de travail vCardDAV
TITLE;LANGUAGE=en:Chair, vCardDAV working group

Here you can't reliably know which one goes with which without the PID
parameter. Better:

TITLE;LANGUAGE=fr;PID=1:Directeur de la recherche
TITLE;LANGUAGE=en;PID=1:Director of Research
TITLE;LANGUAGE=fr;PID=2:Président, groupe de travail vCardDAV
TITLE;LANGUAGE=en;PID=2:Chair, vCardDAV working group

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Jul 2010 14:12:04 -0400

Hi Simon,

> TITLE;LANGUAGE=en;PID=2:Chair, vCardDAV working group

What about the group prefix? That could also be used to group language 
variants:

GRP1.TITLE;LANGUAGE=fr:Directeur de la recherche
GRP1.TITLE;LANGUAGE=en:Director of Research
GRP2.TITLE;LANGUAGE=fr:Président, groupe de travail vCardDAV
GRP2.TITLE;LANGUAGE=en:Chair, vCardDAV working group

-- 
Cyrus Daboo

---

From: Markus Lorenz <[email-masked]>
Date: Wed, 21 Jul 2010 20:41:01 +0200

> GRP2.TITLE;LANGUAGE=en:Chair, vCardDAV working group

Section 3.2 says:

   The group name is a syntactic convention used to indicate that all
   property names prefaced with the same group name SHOULD be grouped
   together when displayed by an application.  It has no other
   significance.  Implementations that do not understand or support
   grouping MAY simply strip off any text before a "." to the left of
   the type name and present the types and values as normal.

For my understanding the group construct should only be used to build
groups of properties which have a meaning to the user.

   [...] grouped together when displayed [...]. It has no other
   significance.

Therefore I don't think we should use groups to solve internal issues.

There would also be a problem for implementations that don't understand
or support the grouping, which is allowed. Those implementations
wouldn't be able to handle the LANGUAGE parameter correctly.

Best regards

Markus

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 21 Jul 2010 20:15:35 -0300

Cyrus Daboo wrote,

> GRP2.TITLE;LANGUAGE=en:Chair, vCardDAV working group

That approach doesn't disambiguate when both titles are related to the same
organization.

Besides, if PIDs are already present because of synchronization, there is no
need for identifying each property by using groups.

Best Regards

Javier

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 21 Jul 2010 20:15:25 -0300

Simon Perreault wrote,

>+1, with "and MUST have a PID parameter with the same value".

+1 too.

BTW, should we say that "all instances that are translations of the same value
SHOULD/MUST be assigned to the same group, if the group construct is used for
any of them"?

The following is obviously nosense:
 GRP1.TITLE;LANGUAGE=fr;PID=1:Directeur de la recherche
 GRP2.TITLE;LANGUAGE=en;PID=1:Director of Research

In this example, the translations (which are related because they are a single
logical value) are also unrelated because they belong to different groups.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 21 Jul 2010 19:38:49 -0400

> SHOULD/MUST be assigned to the same group, if the group construct is

I don't think so. Groups are completely orthogonal to this issue.

Simon