Hi Christer, > On 20 May 2023, at 2:58 am, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> wrote: [...] >> 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. 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. > Having said that, I'm fine with having the restriction, because in reality I > assume the values always will have to be encoded as sf-strings anyway (you > can't encode a URI as a sf-integer, sf-boolean etc). Ok. Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
