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

[Simon Perreault <[e-mail]>]

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
> "[phone]","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