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

[Christer Holmberg <[e-mail]>]

Hi Mark,

>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.

Perhaps it would be useful to add a Note about that? Because, now the text 
only says that parameter values must be String, without any justification.

Now, making the above assumption that an application is "sf-unaware", isn't 
there a risk that the parameter NAMES will cause problems?

According to RFC 8288 (Section 3), the syntax for the parameter name is 
'token':

     Link       = #link-value
     link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
     link-param = token BWS [ "=" BWS ( token / quoted-string ) ]

 According to RFC 7230 (Section 3.2.6), the syntax for 'token' is:

     token          = 1*tchar
     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                    / DIGIT / ALPHA
                    ; any VCHAR, except delimiters


However, RFC 8941 (Section 3.1.2) only allows a subset of those characters for 
parameter names (key):

      parameter     = param-key [ "=" param-value ]
      param-key     = key
      key           = ( lcalpha / "*" )
                         *( lcalpha / DIGIT / "_" / "-" / "." / "*" )
      lcalpha       = %x61-7A ; a-z

For example, RFC 8941 does not allow capital letters, or a bunch of
special characters, for parameter names, that RFC 7230 do allow.

Regards,

Christer



> 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=c2215f80-2678-4d68-bcee-ea310de4050b&u=https%3A%2F%2Fwww.mnot.net%2F