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

Barry Leiba <barryleiba@computer.org> Sun, 28 December 2014 17:02 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E131D1AD59D for <vcarddav@ietfa.amsl.com>; Sun, 28 Dec 2014 09:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIF8azdZuARU for <vcarddav@ietfa.amsl.com>; Sun, 28 Dec 2014 09:02:56 -0800 (PST)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D890D1AD590 for <vcarddav@ietf.org>; Sun, 28 Dec 2014 09:02:55 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id hs14so10205861lab.22 for <vcarddav@ietf.org>; Sun, 28 Dec 2014 09:02:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=kpqBJf7A38EGaDiRT1BPbmOoWT8/mmYz3o+KUnhFaFk=; b=EGme6X6hiIz8+1OijV5qBJq0tkZOdDwq3WYNkPfIv45wvpBLBaIVPhHf0muJefmj6d BrUfCghqwiiL5DYQ5TPWhN2Wj4H9aeP4UIGc/zI4n8JO8M3sgYhgVpEl0sWjFruuSGpa vbIRvcqFPamCYFEHMPInavj9ISIU2bcAyf0HTLioUTzRjP6G5pYFFhQy+KOi+KiJCTkB bjSbdUMrGiq/Hy3iQk46GmC/NTLeH2vH2UFoMHkKe5t7u1jwKyZ3AGg4Is9c/d26Zj11 3kB4PCR4FfWwrJsyUc1FED9UbOQvq7GFaJpgEnk2V5GPeYB+KkbaCuN3UEreAB9R0ffm nldA==
MIME-Version: 1.0
X-Received: by 10.152.22.67 with SMTP id b3mr53236310laf.82.1419786173935; Sun, 28 Dec 2014 09:02:53 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.127.168 with HTTP; Sun, 28 Dec 2014 09:02:53 -0800 (PST)
In-Reply-To: <20141228162534.4BEE418008C@rfc-editor.org>
References: <20141228162534.4BEE418008C@rfc-editor.org>
Date: Sun, 28 Dec 2014 12:02:53 -0500
X-Google-Sender-Auth: FY1n9rHNQeiRqQiBKm-m_Sx3Mfw
Message-ID: <CALaySJLRdD8qpNC0MWE+t8MXVtBnnZngNESNRv_9=xWTnFRNjQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/vcarddav/_yPfUgh_X0AfqORwEFnEmgZI-bQ
Cc: Simon Perreault <simon.perreault@viagenie.ca>, Pete Resnick <presnick@qti.qualcomm.com>, evought@pobox.com, CardDAV <vcarddav@ietf.org>
Subject: Re: [VCARDDAV] [Technical Errata Reported] RFC6350 (4213)
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav/>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Dec 2014 17:02:58 -0000

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

Barry

On Sun, Dec 28, 2014 at 11:25 AM, RFC Errata System
<rfc-editor@rfc-editor.org> wrote:
> 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 <evought@pobox.com>
>
> 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
>