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

[Christer Holmberg <[e-mail]>]

...and, as the comment was about Parameters, my examples should look like:

Example-Header: X; parm="1234"	// sf-string
Example-Header: X; parm=1234		// sf-integer

Example-Header: X; parm="foo123"	// sf-string
Example-Header: X; parm=foo123	// sf-token

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

Example-Header: X; parm="1.2"		// sf-string
Example-Header: X; parm=1.2		// sf-decimal

Regards,

Christer

-----Original Message-----
From: Gen-art <[e-mail]> On Behalf Of Christer Holmberg
Sent: Monday, 22 May 2023 10.48
To: Mark Nottingham <[e-mail]>
Cc: [e-mail]; HTTP APIs Working Group <[e-mail]>; Last Call
<[e-mail]>
Subject: Re: [Gen-art] Genart last call review of
draft-ietf-httpapi-link-template-02

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