Subject: [VCARDDAV] ghostbusters vCard

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Oct 2011 19:53:28 -0600

draft-ietf-sidr-ghostbusters (currently in IESG review) contains the
following vCard4 example:

     BEGIN:VCARD
     VERSION:4.0
     FN:Human's Name
     ORG:Organizational Entity
     ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A.
     TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212
     TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213
     EMAIL:[email-masked]
     END:VCARD

I think several lines in that example are not consistent with RFC 6350:

1. The values for TYPE are case-sensitive. So TYPE=work and so on.

2. Comma-separated values for TYPE need to be quoted. So
TYPE="voice,text,work" and TYPE="fax,work".

Anything else?

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 17 Oct 2011 22:18:36 -0400

Hi Peter,

> 1. The values for TYPE are case-sensitive. So TYPE=work and so on.

I don't think so. Section 3.3:

   Parameter values that are not explicitly defined as
   being case-sensitive are case-insensitive.

I don't see anything in the definition of TYPE that says case-sensitive. I 
think case-insensitive is correct for enumerated values like TYPE.

> TYPE="voice,text,work" and TYPE="fax,work".

No. The Comma is used as a delimiter for multiple values. There is no 
requirement to quote. Now I do see that examples in 6350 use quotes - I 
think that is wrong as per the definition of type:

           type-param = "TYPE=" type-value *("," type-value)

           type-value = "work" / "home" / type-param-tel
                      / type-param-related / iana-token / x-name
             ; This is further defined in individual property sections.

There are no DQUOTEs defined.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 17 Oct 2011 22:29:17 -0400

Hi,

> There are no DQUOTEs defined.

Ughh! So there is more wrong with 6350 than I thought. In 2425 we have:

   param        = param-name "=" param-value *("," param-value)
   param-value  = ptext / quoted-string
   ptext  = *SAFE-CHAR
   SAFE-CHAR    = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
      ; Any character except CTLs, DQUOTE, ";", ":", ","

Note how SAFE-CHAR excludes a comma. That ensures that multi-valued 
parameter values can be correctly parsed, because if any individual value 
were to contain a comma, it would need to be quoted:

FOOBAR-PARAM="comma, here","no comma"

Now in 6350 we have:

   param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
   SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
     ; Any character except CTLs, DQUOTE, ";", ":"

Note how comma is allowed as a SAFE-CHAR. This is wrong. Take a look at 
SORT-AS, which is the only parameter which is multi-valued with a "complex" 
(non-token) value:

     sort-as-param = "SORT-AS=" sort-as-value

     sort-as-value = param-value *("," param-value)

If param-value were allowed to contain a comma and not be quoted, there 
would be no way to distinguish the param-value from a list of param-values.

At this point I think we need to revert the definition of SAFE-CHAR to that 
used in 2425.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Oct 2011 21:48:24 -0600

On 10/17/11 8:18 PM, Cyrus Daboo wrote:
> I don't see anything in the definition of TYPE that says case-sensitive.
> I think case-insensitive is correct for enumerated values like TYPE.

You're right. I read the sentence before that but not the next one...

> There are no DQUOTEs defined.

Aha, so we might to file an erratum against the examples in 6350.

Peter

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Oct 2011 08:40:42 -0400

> TYPE="voice,text,work" and TYPE="fax,work".

Cyrus is right about the errata (aaaaargh!). And just to be clear, the
ghostbusters vCard is OK. If quoting was added, even though it is unnecessary,
it would be done properly like this:

TYPE="voice","text","work"
TYPE="fax","work"

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: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Oct 2011 21:11:38 -0600

> TYPE="voice","text","work"

Thanks for the clarifications!

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Oct 2011 10:05:31 -0400

Hi Simon,

--On October 18, 2011 8:40:42 AM -0400 Simon Perreault 
<[email-masked]> wrote:

> ghostbusters vCard is OK. If quoting was added, even though it is
> unnecessary, it would be done properly like this:
>

Well I would argue even that is not valid according to the current syntax:

"type-value" is defined as an iana-token and that does not allow use of 
double-quotes.

The point here is that "param-value" specifies an overall pattern that 
paramater values must conform to, but individual parameters can be more 
restrictive than that in their own definitions.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Oct 2011 10:08:18 -0400

> "type-value" is defined as an iana-token and that does not allow use of

Exactly. That's what I meant by you being "right about the errata". The
ABNF is wrong. And we need some examples illustrating the corner cases
of parameter quoting.

Simon

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 09:47:10 +0200

> ABNF is wrong. And we need some examples illustrating the corner cases

Right.

We have the same problem with HTTP and HTTP-related specs. Abusing the 
ABNF to enumerate values when there's extensibility anyway leads to 
questions about whether the predefined values really parse the same way 
as new ones. (And they should.)

Best regards, Julian