Semantics organisation

[mnot]

3. Conformance seems oddly separated from 1.1. Requirements Notation and 1.2. Syntax Notation; can we just move its contents up into 1?

Also, 11. ABNF List Extension: #rule seems like it's a natural for a peer or child of 1.2. Syntax Notation, rather than being buried between Response Header Fields and Security Considerations.

If that's all too much to put at the head of the document, could we perhaps move these things together to the end of the document (either one of the last sections, or as appendices), and just keep a skeleton referring to them at the top?

[reschke]

The list expansion once was an appendix, and we were told to move it up :-(

[mnot]

By whom?

[reschke]

During IESG review AFAIR.

[mnot]

I am tempted to try again; that's often just a matter of personal taste.

[royfielding]

Conformance is where it is because of its usage of defined terms. It is much more important than it looks -- I don't want it in an appendix. I don't have an opinion on where the list extension belongs.

[mnot]

My proposal was to move Conformance to a new subsection of the introduction, to make it a peer of the requirements and syntax notations -- i.e., everything about "how to read this document" is in one place. That OK with you @royfielding?

Likewise, I wanted to move the list rule into a subsection of 1.2 Syntax Notation, since that's what it is.

[royfielding]

But that means conformance would be making requirement statements about defined terms before the terms are actually defined. Is that okay? Or do we just need to split those sentences out?

[royfielding]

Did you mean the entire section

https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#conformance

or just some specific part of it? Moving the whole thing up doesn't make sense to me.

[mnot]

The whole thing. Too deep?

How about moving Conformance up above Architecture? (yes, this is getting towards choosing colours...)

[reschke]

Likewise, I wanted to move the list rule into a subsection of 1.2 Syntax Notation, since that's what it is.

Please don't. Too much prose in the wrong place. A forward reference is just fine.

[mnot]

Hmm, then see #187 (and comments there). Perhaps turn section 11 into a "generic syntax" bucket?

[reschke]

+1 to collecting generic syntax in a single place, in case it's really more than the whitespace part.

I'd separate common ABNF rules from the list extensions; these are different layers.

[mnot]

So, leave #rule as is, and add a new "Generic Syntax" section next to it?

[mnot]

See PR. I think the remaining question is whether to move the contents of "Header Field Value Components" there as well (i.e., Tokens, Quoted Strings, Comments and Parameters.