Subject: Re: [VCARDDAV] [Technical Errata Reported] RFC6350 (3100)

From: Simon Perreault <[email-masked]>
Date: Fri, 03 Feb 2012 10:49:56 -0500

Sorry for the late reply...

On 2012-01-30 16:55, Javier Godoy wrote:
>> Well, all parameters can be implicitly quoted. So why restrict
>> yourself to the TYPE parameter?
>
> Because Section 5 specifies that "the property parameter can be
> multi-valued in which case the property parameter value elements are
> separated by a COMMA" and "property parameter value elements that
> contain the COLON, SEMICOLON, or COMMA character separators MUST be
> specified as quoted-string text values".

Right.

> As I understand Section 5, there are two value elements ("text" and
> "voice"), and what must be quoted is not the property parameter
> *value* (as in TYPE="text,voice"), but the property parameter value
> *elements* (as in TYPE="text","voice"). . Since TYPE is defined as "a
> comma-separated subset of a predefined enumeration", not only there
> is no need to escape the comma, but the comma MUST NOT be escaped
> since it is the list delimiter instead of a part of the *parameter
> value element*.

RIGHT! There is definitely a bug in the example. Now I see it.

> This is similar to
> N;SORT-AS="Aboville,Marie,Christine":d'Aboville;Marie,Christine;;
> instead of
> N;SORT-AS="Aboville","Marie,Christine":d'Aboville;Marie,Christine;;
>
>
>> If the ABNF is to be fixed, it would need to be done implicitly for
>> all parameters at once.
>
> Most of the other parameters either must be quoted (and already allow
>  DQUOTE in ABNF), or are defined as a single element that cannot
> contain comma/semicolon/colon (thus the implicit quote rule is
> harmless). Even most of the list types are not ambiguous if the whole
> value is quoted, for instance the integer-list value
> "+1234556790,432109876" can be understood as
> "+1234556790","432109876", but there are no conflicting examples or
> definitions in RFC 6350.
>
> My concern is that quoting "text,voice" does not conforms Section 5,
> and should be explicitly allowed. Whether the requirement of quoting
> value elements per Section 5 remains as an implicit rule or it is
> explicitly stated in the ABNF, is a separate issue that I didn't
> intend to discuss.

Now I'm not following you. Are you saying that

TYPE="text,voice"

is OK or not?

IMHO,

TYPE=text,voice
TYPE="text","voice"

are OK while

TYPE="text,voice"

is wrong.

If we agree on that then I think the errata can be approved.

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

---

From: "Javier Godoy" <[email-masked]>
Date: Sat, 4 Feb 2012 20:08:25 -0300

On 2012-02-03, Simon Perreault wrote:

> Are you saying that

I agree it is wrong, but I'm unsure about the impact on existing 
implementations if they assumed that the examples were correct.

> If we agree on that then I think the errata can be approved.

Depending on the resolution, the errata might have to be modified (is that 
possible?), because I suggested fixing the ABNF, and only mentioned (in the 
"Notes" part) the alternative of fixing the examples and leaving the ABNF 
intact.

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Mon, 06 Feb 2012 08:32:56 -0500

On 2012-02-04 18:08, Javier Godoy wrote:
> Depending on the resolution, the errata might have to be modified (is
> that possible?), because I suggested fixing the ABNF, and only mentioned
> (in the "Notes" part) the alternative of fixing the examples and leaving
> the ABNF intact.

OK, we're on the same wavelength now. I suggest modifying the errata 
because the example is wrong. There's no way to make it right while 
keeping an ABNF that is consistent across parameters (so that it is 
possible to write a generic vCard parser).

To modify the errata, just file a new one, the AD will do the rest. ;)

Simon

---

From: Peter Sheerin <[email-masked]>
Date: Mon, 06 Feb 2012 10:39:02 -0800

Can you explain this a bit more?

Is there a fear that doing it right will impact existing 4.0 
implementations, or is the concern something else?

---

From: Simon Perreault <[email-masked]>
Date: Mon, 06 Feb 2012 13:55:01 -0500

> implementations, or is the concern something else?

The RFC contains an example with:

TYPE="foo,bar"

The intent is to have two values of the TYPE parameter: foo and bar. 
Equivalent to this:

TYPE=foo,TYPE=bar

The example is wrong. It represents a single value of the TYPE 
parameter: "foo,bar" (a single string including the comma).

What I meant by "there's no way to make it right" is this: There is no 
way we can change the ABNF so that the example becomes correct. The 
example is just wrong. We must fix it with one of these:

TYPE=foo,bar
TYPE=foo,TYPE=bar
TYPE="foo","bar"

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 06 Feb 2012 14:21:57 -0500

Hi Simon,

--On February 6, 2012 1:55:01 PM -0500 Simon Perreault 
<[email-masked]> wrote:

> The example is wrong. It represents a single value of the TYPE parameter:
> "foo,bar" (a single string including the comma).
>

And perhaps we should have an example of 'TYPE="foo,bar"' and explain that 
that represents a single parameter value of "foo,bar" just to re-iterate 
the point.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 6 Feb 2012 17:14:29 -0500

> What I meant by "there's no way to make it right" is this: There is no way
> we can change the ABNF so that the example becomes correct. The example is
> just wrong. We must fix it with one of these:
>
> TYPE=foo,bar
> TYPE=foo,TYPE=bar
> TYPE="foo","bar"

I think we should fix it with ALL of those, and note in the example
that they're all valid and all equivalent.  And, yes, add Cyrus's
suggestion, as well.  This is such a confusing area that the more
examples we give -- including ones that say "this isn't valid" or
"this doesn't mean what you probably think it means" -- the better.

Barry

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 8 Feb 2012 10:43:07 -0300

On February 6, 2012 2:21 PM -0500 Cyrus Daboo wrote.

>> There is no

TYPE=foo;TYPE=bar

>> TYPE="foo","bar"

I'm not sure about this one.

On <http://www.ietf.org/mail-archive/web/vcarddav/current/msg02476.html> Simon
said that "all parameters can be implicitly quoted", but the published text of
RFC 6350 suggests that some parameters cannot be quoted, because the ABNF only
allows gratuitous quotes in TZ, ALTID, LABEL, SORT-AS and any-param (which are
defined in terms of param-value):

  param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE

  tz-parameter  = "TZ=" (param-value / DQUOTE URI DQUOTE)
  altid-param   = "ALTID=" param-value
  label-param   = "LABEL=" param-value
  sort-as-param = "SORT-AS=" sort-as-value
  any-param  = (iana-token / x-name) "=" param-value *("," param-value)

Thus ALTID="1" would be valid, while TYPE="foo" would not, because type-param
is defined as

  type-param = "TYPE=" type-value *("," type-value)
  type-value = "work" / "home" / type-param-tel
             / type-param-related / iana-token / x-name

If quoted values such as TYPE="foo" were valid, they should be explicitly
allowed (at least as a general comment in section 5, applying to all parameter
types).

> that represents a single parameter value of "foo,bar" just to re-iterate the
> point.

+1, though "foo,bar" is not a valid type-value.

Perhaps this clarification fits best for the SORT-AS param.

For instance, the value of the SORT-AS parameter in
    N;SORT-AS="Mann,James":de Mann;Henry,James;;
is a single param-value "Mann,James" that applies to the surname, and no
sort-string is specified for the given name.

On the other hand, the value of the SORT-AS parameter in
   N;SORT-AS="Mann","James":de Mann;Henry,James;;
is a list of two param-values: the first one "Mann" applies to the surname,
and the second one "James" applies to the given name.

In this case, both examples are valid according to the ABNF, but have
different meanings.

BTW, the sort results in section 5.9 do not change, because both "Henry" and
"James" sorts between "Christine" and "Osamu".

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Feb 2012 09:07:14 -0500

>>> example is just wrong. We must fix it with one of these:

Right. *sigh*

> allows gratuitous quotes in TZ, ALTID, LABEL, SORT-AS and any-param

Ok then I would consider that to be a bug in the ABNF. A parser should 
not need to know about specific parameters when parsing quotes.

> and the second one "James" applies to the given name.

Yes, this is a very good example.

Thanks,
Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Feb 2012 12:16:04 -0700

> "this doesn't mean what you probably think it means" -- the better.

Right. This needs attention, but it needs attention in 6350bis. I'm
going to make this erratum as "Hold for Document Update".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/