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
