Reduce confusion wrt registry sections #800

[fantasai]

• Rename “registry section” to “embedded registry”.
• Move paragraph about Patent Policy to its own section.
• Remove the words “purely documentational” because it's easy to confuse with “informative” / “non-normative”.
• Add “(only)” to the sentence making registries non-normative for Patent Policy purposes.

---

Preview | Diff

[nigelmegitt]

Thank you @fantasai for putting this pull request together. I don't think it matches the state of the issue discussion as it stands, so either the issue thread contains some misunderstandings or the pull request needs a bit of adjustment.

I'd like to see the definition part of §6.5 amended as well, specifically the wording "associated components" which seems ambiguous. It is not clear that the registry tables are the registries, and that they must be hard linked to registry definitions, and can be used by reference or inclusion in a Rec track document.

[nigelmegitt]

I'm not yet convinced this is correct. I think it is true when applied to the Registry Tables and their entries, but it is not clear to me that the Registry Definition is not normative, since my understanding based on the issue thread (#800 (comment) especially) is that Registry Definitions are subject to the same document transition requirements as the reports in which they're contained. So if a Rec track technical report contains a Registry Definition, then it is treated as normative and cannot be changed without going through the generic requirements for changing a normative section of a Rec track document.

If that is correct, then it's only the Registry Tables that are non-normative here.

[frivoal]

So if a Rec track technical report contains a Registry Definition, then it is treated as normative and cannot be changed without going through the generic requirements for changing a normative section of a Rec track document.

Yes, but to pay attention to the first line of this sentence:

For the purposes of the Patent Policy [[PATENT-POLICY]] (only),
[…]

As far as Rec track transition criteria and the like are concerned, yes, this is treated like normative text, but that's not what that sentence is talking about.

[nigelmegitt]

OK, then we need to make that point somewhere else.

[frivoal]

I'm not sure I understand. What point? Where?

[dwsinger]

Nigel, do you want to use the phrase "embedded registry content" or "embedded registry tables" as we seem to have continuing confusion between that and "registry definition" (which is normative)?

[frivoal]

(Also, for better or worse, that is what the current text says. The diff makes it look like this is new text, but it is merely moved text, aside from the renaming from [=registry section=] to [=embedded registry=])

[nigelmegitt]

Nigel, do you want to use the phrase "embedded registry content" or "embedded registry tables" as we seem to have continuing confusion between that and "registry definition" (which is normative)?

There shouldn't be any difference between the rules for registry tables whether they're embedded or in a registry report, so I'm not sure why we'd have this term at all.

But I do prefer "registry tables" to "registry content" because it's clear that it excludes the registry definition(s).

[nigelmegitt]

I'm not sure I understand. What point? Where?

Sorry, I meant the point that has been discussed in this thread, about which of Registry Definition and Registry Table are a) normative and b) subject to which kind of change management.

[frivoal]

There shouldn't be any difference between the rules for registry tables whether they're embedded or in a registry report, so I'm not sure why we'd have this term at all.

It's not particularly deep: registry in a standalone document need a name, so that we can talk about that sort of documents. When discussing publications of such things for example, it's handy to have a name for them. So we called those "Registry Reports", because they're technical reports that contains registries (and nothing else). It also seemed convenient to have a word to talk about a registry which is not in a standalone registry report, but is inside a Recommendation. So we used to call these registry sections, but as you pointed out, there's a singular/plural issue with that term, so we're proposing to call those embedded registries.

In most respects, it doesn't matter if a registry is in a registry report, or is an embedded registry inside a REC, but the publication process is slightly different: RECs, for the sake of their non-registry parts, go through a PR stage, for instance, which is unnecessary for Registry reports.

[frivoal]

I meant the point that has been discussed in this thread, about which of Registry Definition and Registry Table are a) normative and b) subject to which kind of change management.

The word "normative" is used in the Process a number of times, it is used in the ordinary sense of the word, and not as a specific defined term within the Process, with clear consequence for being or not being normative. And I don't mean about registries specifically, I mean the Process in general.

As for Registries, I think the Process covers all the relevant aspects already, but I don't think the answer is just "yes it's normative" or "no it's not", because there are multiple facets to that, and it depends which one you are considering.

For instance, from the point of view of being requirements about an implementation of the specification, the Registry Definition is not normative, because it doesn't discuss the implementation in the first place, it discusses the registry tables. (The Process does say “must not contain any requirements on implementations“.)

But it does define binding behavior on people who will maintain the registry, and will use RFC2119 terms for doing that, so in that sense, it is normative.

Registry tables document values, not requirements, as discussed in https://www.w3.org/2023/Process-20231103/#reg-ref-specifications. So they are not a place to use RFC2119, and in that sense they are not normative, since they do not dictate anything. (The Process does say “must not contain any requirements on implementations“.) But they are (when sufficiently mature) authoritative, within the scope defined by the registry definitions.

But from the point of view of the Recommendation track publication process, and of the Registry Track publication process, the usual classes of changes 1 through 4 apply as always, with the first 2 being editorial, and the next 2 being substantive. No difference here between ordinary REC text and Registry Definitions. Changes to Registry tables are defined there to be their own class.

From the point of view of the Patent Policy, normative means:

For purposes of this definition, the normative portions of the Specification shall be deemed to include only architectural and interoperability requirements.

Registry tables do not contain requirements, so they cannot be normative for the purposes of the patent policy, and we call this out. (Plus, we need registry tables not to be covered by the Patent Policy, otherwise we couldn't do the rapid revisions registries are designed for).

The current process goes beyond that, and says that Registry Reports and Registry sections in their entirety are not subject to the patent policy, including Registry Definitions. For Registry Reports, this allows a simplified publication cycle, and for embedded registies, I think it does not make much of a difference (see #807 (comment)), but for now it matters not where they are defined.

And I think that covers it. Is there some other aspect of "being normative" that you'd like an clarification about?