Re: [Last-Call] Genart last call review of draft-ietf-httpapi-link-template-02

[Christer Holmberg <[e-mail]>]

Hi Mark,

>>> Ah. The reason is that allowing any type would require creating a
>>> mapping of current values to SF types, and there are just too many
>>> potential (and undocumented) values already in use to do this.
>>
>> I don't think that is true. Just because the Parameter syntax allows
>> values to be encoded sf-string, sf-token, sf-boolean etc it doesn't
>> mean that you have to map each value (existing or new ones) to each of
>> those encodings. If a value is defined as a String, then it has to be 
>> encoded as a sf-string.
>
> Consider an implementation that wants to serialise a link relation that has 
> a 'foo' Parameter
> that it has no special knowledge of. If the value is "bar", that's very 
> straightforward -- it will
> successfully serialise as a Token. However, consider the value "1.2.3.4" --  
> it will fail parsing, because
> it looks like an Integer or Decimal to the parser, but it isn't.

It will not look like an Integer or Decimal to the parser: if the value is 
surrounded by quotes, it is a String. Tokens, Integers and Decimal do not have 
quotes.

Example-Header: "1234"    	// sf-string
Example-Header: 1234		// sf-integer

Example-Header: "foo123"	// sf-string
Example-Header: foo123	// sf-token

Example-Header: "1.2.3.4"	// sf-string
Example-Header: 1.2.3.4	// NOT a valid value, as sf-decimal only allows one 
dot

Example-Header: "1.2"		// sf-string
Example-Header: 1.2		// sf-decimal


>Of course, we could specify something like "try to parse it as a Structured 
>Value; if serialisation
>fails, serialise it as a String." That strategy might be workable, but it 
>creates a lot of complexity -- 
>at runtime when you have to test the value by running code, and when values 
>are handled, because
>now they could come in multiple forms.
>
>Always serialising as a string recognises that, from the standpoint of the 
>Link header field, the
>value's type is opaque.

In general, if a parser is not able to determine the encoding without 
"testing" values etc, the syntax is bad. But, in the case of structured field 
values that is not the case: the parser will always know if a value is 
sf-string, sf-integer, sf-decimal etc.

Regards,

Christer