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 <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://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
