[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-08.txt
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