Hi Mark, >>>> Q2_2: The text says "Parameter values MUST be Strings." >>>> >>>> It is unclear what "Strings" means. Does it mean that parameter >>>> values must be encoded as quoted-strings? If so, why? RFC8288 says >>>> that parameter values can be encoded both as token and quoted-string. >>> >>> S 1.1: "This specification uses the following terms from >>> [STRUCTURED-FIELDS]: List, String, Parameter." >> >> Yes. But, in Section 3.1.2 of [STRUCTURED-FIELDS] there is no >> restriction that the Parameter value must by String. My question is >> why you are making that restriction, instead of just allowing the >> different Parameter value encodings defined in [STRUCTURED-FIELDS]? > > 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. 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). Thanks! Regards, Christer
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
