Hey, Specifying interoperability in terms of what artifacts look like on the wire doesn’t take into account divergence of behavior between sending and receiving, leading to security as well as interop issues - especially when there are many potential producers and/or consumers of the artifact (as is often the case with web protocols). That’s why we’ve taken the approach of specifying parsing and serialisation behaviors separately in structured fields, mirroring the approach that’s taken in many other modern parts of the web stack such as html. Cheers, Sent from my iPhone > On 25 Feb 2025, at 3:10 pm, Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote: > > Ho Mark, > >> On 2/24/25 6:41 PM, Mark Nottingham wrote: >> Hi Paul, >> Thanks for the review; responses below -- >>>> On 25 Feb 2025, at 4:36 am, Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote: >>> 1) NIT: Lack of normative language for syntax >>> >>> I gather this document intends to normatively specify some of the syntax of HTTP requests and responses. Yet the specification fails to use normative language. For instance, consider the following sentence from section 2: >>> >>> "The Cache-Groups HTTP Response Header is a List of Strings [STRUCTURED-FIELDS]." >>> >>> To clearly be normative, I would expect this to be stated as: >>> >>> "The Cache-Groups HTTP Response Header MUST be a List of Strings [STRUCTURED-FIELDS]." >>> >>> This problem is present in sections 2 and 3, and also in the reference [STRUCTURED-FIELDS]. >> We avoid that style of requirement, because it doesn't make clear who the requirement applies to, or how to handle failures. Structured fields requires (in section 1.2) use of specific algorithms that address that shortcoming. > > I don't understand. Are you saying that replacing "is" by "MUST be" makes the requirement less clear? > > I've heard many stories of implementers who only feel obligated to implement the parts of a spec that say "MUST". I don't agree with that approach, but it is out there. Using the BCP 14 keywords to express normative intent helps to reduce questions about normative intent. > > Thanks, > Paul -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
