Subject: [VCARDDAV] [Technical Errata Reported] RFC6350 (4213)

From: RFC Errata System <[email-masked]>
Date: Sun, 28 Dec 2014 08:25:34 -0800 (PST)

The following errata report has been submitted for RFC6350,
"vCard Format Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=4213

--------------------------------------
Type: Technical
Reported by: Eric Vought <[email-masked]>

Section: 5.4

Original Text
-------------
"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names."

Corrected Text
--------------
"Two property instances are considered alternative representations of
the same logical property if and only if their names as well as the
value of their ALTID parameters are identical.  Property instances
without the ALTID parameter MUST NOT be considered an alternative
representation of any other property instance.  Values for the ALTID
parameter are not globally unique: they MAY be reused for different
property names.

"Values for group and for the PREF parameter SHOULD be the same for all
alternative representations of the same property. The values of group
and PREF are not defined for a property if they differ among alternative
representations of the same logical property."

Notes
-----
The corrected text "not defined" is intended as a literal statement of the consequences of the current specification and not a change to the meaning of the current specification. The submitter recommends that the text "Values for the group and for the PREF parameter MUST be the same..." be considered for future versions of this document.

It is also requested that the example below be added to the "legal but questionable" list in section 5.4.

Section 3.3 contains the text:

"The group construct is used to group related properties together.
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."

There is no valid interpretation available for an application if a logical property has more than one group (see example below) and clearly no way to display such properties together, therefore the group construct has no defined meaning for such a case. This is particularly troublesome when converting to formats such as the VCard XML Schema where the group is represented as an XML schema in which properties are contained.

Also, Section 5.3 states in reference to the PREF parameter:

"Note that the value of this parameter is to be interpreted only in
relation to values assigned to other instances of the same property
in the same vCard.  A given value, or the absence of a value, MUST
NOT be interpreted on its own."

The meaning of "instances of the same property" is not decipherable with respect to logical properties which differ in their PREF parameter value, therefore application behavior is also not defined for this case.

Example:

volunteer.ORG;ALTID=1;PREF=1;LANGUAGE=en:Doctors Without Borders
causes.ORG;ALTID=1;LANGUAGE=fr:Médecins Sans Frontières
volunteer.ORG:Community Emergency Response Team;Some County\, Some State
volunteer.ROLE:CERT Instructor
ORG;TYPE=WORK:Sometown Medical Center

The alternative representation of "Doctors Without Borders" is legal according to the current text but breaks the 'volunteer' grouping: the same logical property is requested by the VCard to appear in two places. Similarly, the PREF tag on "Doctors Without Borders" is legal but nonsensical. The logical application representation of the ORG properties with ALTID=1 as the same logical property breaks sort ordering or selection by PREF. Similarly, application representation of PREF as a priority queue of properties breaks for this case. The application is forced to drop consideration of PREF and group in these cases and should be explicitly allowed to do so (even though it may support PREF and grouping in the general case).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6350 (draft-ietf-vcarddav-vcardrev-22)
--------------------------------------
Title               : vCard Format Specification
Publication Date    : August 2011
Author(s)           : S. Perreault
Category            : PROPOSED STANDARD
Source              : vCard and CardDAV
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Sun, 28 Dec 2014 12:02:53 -0500

This seems tobe a perfectly good conversation to have, but well out of
scope for "errata".  Simon, do you think otherwise?

Barry

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Dec 2014 10:01:52 -0500

> scope for "errata".  Simon, do you think otherwise?

Agreed. Eric, your reasoning appears correct to me, and would be good input
for vCard 4.1. (FYI, 4.1 is not currently being worked on, but there are
discussions from time to time about starting such an effort...)

Simon

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Dec 2014 13:03:29 -0500

> discussions from time to time about starting such an effort...)

Is there anything here that qualifies as approved errata, where I
could edit out the rest in the errata system?  Or shall I just mark
the report as "rejected" for now, and we leave the discussion on the
mailing list?

Barry

---

From: Simon Perreault <[email-masked]>
Date: Mon, 29 Dec 2014 15:38:20 -0500

> the report as "rejected" for now, and we leave the discussion on the

I think should can mark it "rejected".

Thanks,
Simon

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Dec 2014 15:51:00 -0500

> 1) What should the current spec say to make clear its current meaning given
> that errata are not permitted to change its meaning? and
...
> #1 is my real concern for purposes of the errata
...
> I am unfamiliar with this group's process. When I worked with
> interpretations for IEEE PASC, there was a basic form response to the effect
> of, "The spec says what it says, but what it says currently makes no sense
> (for this case), therefore implementations shall not depend upon that
> combination. The underlying question will be resolved in a future version."
> I imagine you have a similar way of wording that? That is more or less what
> I was expecting to get back.

Well, we do have something of that nature: I can mark the errata
report "Rejected", which means either that it's wrong or that it's
outside the scope of the errata system, or I can mark it "Held for
Document Update" (HFDU), which means that it's a reasonable errata
report, but the resolution needs to be left for a future document
revision.

I do have some latitude here, and, while I see this as a "Rejected"
case (on the "out of scope" grounds), your point that it's hard (or
impossible) to build an implementation of this feature that reliably
interoperates... makes me inclined to use the latitude and go with
"HFDU" instead.

So that's what I intend to do, unless someone screams in the next
couple of days.

Barry