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
> <christer.holmberg@xxxxxxxxxxxx> 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 <gen-art-bounces@xxxxxxxx> On Behalf Of Christer
> Holmberg
> Sent: Monday, 22 May 2023 10.48
> To: Mark Nottingham <mnot@xxxxxxxx>
> Cc: gen-art@xxxxxxxx; HTTP APIs Working Group <httpapi@xxxxxxxx>; Last
> Call <last-call@xxxxxxxx>
> 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
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
