https://github.com/anewton1998/draft-regext-rdap-extensions/issues/52
>> Section 2.4.5, paragraph 1 >> 2.4.5. Bare Extension Identifiers >> >> Some RDAP extensions define only one JSON value and do not prefix it with >> their RDAP extension identifier, instead using the extension identifier as >> the JSON name for that JSON value. That is, the extension identifier is >> used "bare" and not appended with an underscore character and subsequent >> names. > I fully support defining and allowing Bare Extension Identifiers. For > document readability it would be better to define both Bare Extension > Identifiers and Extension Prefixed Identifiers (a name I just minced) as > terms somewhere after defining the syntax in 2.2. All the sections between > 2.2 and this point do not have a notion of Bare Extension Identifiers - not > in text or examples. The reader has an impression that prefixing with > extension identifier and appending a name to it is the only allowed method. [JS] Having a glossary of terms section upfront should help. Not sure about “Extension Prefixed Identifiers” phrase since “extension identifiers” is already commonly used throughout the RDAP specs. We can perhaps re-explain it in the glossary, to help differentiate from the other styles (bare, profile, and marker). >> Section 2.4.5, paragraph 3 >> Usage of a bare extension identifier contravenes the guidance in [RFC9083]. >> This document updates [RFC9083] to explicitly allow this pattern. > If we are updating RFC9083 I would expect more normative text, which would > tell which normative text of RFC9083 is void and what is the replacement. [JS] Fair point. Looks like the normative text of RFC9083 is in one place and should be swappable. >> Section 2.4.5, paragraph 3 >> Along similar lines, an extension may define a single new object class, and >> use the extension's identifier as the object class name. > This is too vague and as it also belongs to updates of RFC9083 I would expect > a very specific normative text. [JS] Again, fair point.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
