Hi Christer, > On 24 May 2023, at 6:52 pm, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> wrote: > > Hi Mark, > >> 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. > > Perhaps it would be useful to add a Note about that? Because, now the text > only says that parameter values must be String, without any justification. Documenting justification for technical decisions is a very slippery slope; doing so in every instance can quickly make specifications unusable as a practical matter. I don't see a strong reason to do so here, because it "just works." > Now, making the above assumption that an application is "sf-unaware", isn't > there a risk that the parameter NAMES will cause problems? Yes - but they should be fairly rare, as it's very common practice to use names that are compatible with SF tokens. That said, it's worth a note. I've reworked this section a bit and added a warning that some names won't serialise; see: https://ietf-wg-httpapi.github.io/link-template/draft-ietf-httpapi-link-template.html#name-the-link-template-header-fi Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
