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

[Mark Nottingham <[e-mail]>]

The quotes in my examples weren't part of the value -- sorry for the confusion.

The point is that SF is being retrofit here -- parameters are defined by applications that may not be aware that they're being used in a context that leverages SF, so we can't assume they'll follow SF syntactic rules. Doing so would require updating RFC8288 (and potentially breaking many existing applications).

Cheers,


> On 22 May 2023, at 5:57 pm, Christer Holmberg <[e-mail]> wrote:
> 
> ...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
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/