Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-08.txt

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Oct 2009 15:38:20 -0400

Markus Lorenz wrote, on 2009-07-27 08:41:
> I'm a little bit confused about this definition. As I understand it, non
> of the properties allow "TYPE" except TEL and RELATED, because non of
> them allow the "type-param" parameter. IMPP for example has the definition:
>    IMPP-param = "VALUE=uri" / pid-param / pref-param / any-param
> Can I use "TYPE=xyz" as an "any-param"
>    any-param  = (iana-token / x-name) "=" param-value
> because it allows "iana-token" parameter-names? Then why is "type-param"
> explicitly allowed for TEL and RELATED?

Indeed, this is under-constrained. iana-token should be understood to mean
"identifier registered from IANA *used as defined*".

I have no idea how to make this clearer though...

> Why are the values of "type-value-tel" also allowed in RELATED and
> values of "type-value-related" in TEL? I can substitute this definition:
>    RELATED-param =/ type-param / pid-param / pref-param / any-param
>    TEL-param = "VALUE=uri" / type-param / pid-param / pref-param
> 
>       / any-param
>    type-param = "TYPE=" type-value *("," type-value)
>    type-value = type-value-tel / type-value-related
>       / iana-token / x-name

Well, no, they are not allowed. The text says so. ;)

The grammar is under-constrained in many places. We would need to move beyond
ABNF if we wanted it to be super tight. I see the primary purpose of an ABNF
grammar to be communication, and I think we're getting to a pretty good state now.

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org