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