Folks, I like this new text explaining I-D’s do not qualify as stable documentation for “Specification required”, and only IETF documents can use IETF namespaces as a summary of our interim meeting.
However, we forgot one use case where we have precedents. Proprietary EPP extensions that cannot reach consensus as standard can also choose the path to publish an informational RFC describing the proprietary extension through the individual submission track. This is stable documentation for a proprietary extension. This happened for example to RFC9095 (Strict Bundling) Since this is an IETF document, it did use the IETF schema and namespaces. To give correct guidance to authors and designated experts: -Is registration of XML namespaces also required for proprietary extensions when they apply for EPP extension registry registrations? The texts is now not clear, and registration of XML schema and namespaces might be a hurdle to register a proprietary extension. (Remember the goal of the registry is to identify proprietary extensions to harmonise into standard extensions even when they use incompliant namespaces) -Are informational RFCs allowed to use IETF namespaces? My guidance would be: -For IETF Standards track EPP extensions, XML schema and namespace URIs must be registered in the IETF XML Registry using the procedures described in RFC 3688, These URIs must use the IETF namespaces. -For proprietary (non-IETF Standards track) EPP extensions, it is encouraged to register XML schema and namespace URIs in the IETF XML Registry. -Non-IETF namespaces must be used for non-IETF specifications. Regards, Antoin [no-hat] > Op 15 jan 2026, om 20:29 heeft Andy Newton <[email protected]> het volgende > geschreven: > > > Scott, > > I offer the following friendly amendments. > > -andy, as an individual > > OLD: > > 124 Note that the "Specification Required" policy requires review by a > 125 "designated expert". Section 5 of RFC 8126 [RFC8126] describes the > 126 role of designated experts and the function they perform. This > 127 policy also requires "a permanent and readily available public > 128 specification". RFC documents meet that requirement. Proprietary > 129 specifications may meet that requirement, depending on how they are > 130 archived and accessible. Internet-Draft documents do not meet that > 131 requirement. RFC 2026 [RFC2026] notes that "Internet-Drafts have > no > 132 formal status, and are subject to change or removal at any time". > > NEW: > > Note that the "Specification Required" policy requires review by a > "designated expert". Section 5 of RFC 8126 [RFC8126] describes the > role of designated experts and the function they perform. This > policy also requires "a permanent and readily available public > specification". RFC documents meet that requirement. Proprietary > specifications may meet that requirement, depending on how they are > archived and accessible. RFC 2026 [RFC2026] notes that "Internet-Drafts have > no > formal status, and are subject to change or removal at any time". However, > the IETF does allow their use for registrations into "Specification Required" > registries using the process described in [RFC7120]. > > OLD: > > 150 Extensions should be evaluated for architectural soundness using > the > 151 guidelines described in RFC 3735 [RFC3735], including the Security > 152 Considerations section of that document. Expert evaluation should > 153 explicitly include consideration of the privacy consequences of > 154 proposed extensions, and, at a minimum, ensure that any privacy > 155 considerations are fully documented in the relevant > specification(s). > 156 URIs proposed in extensions (XML namespace and schema registration > 157 requests are commonly found in EPP extensions) should be evaluated > 158 for both syntactic and semantic correctness. XML schema and > 159 namespace URIs must be registered in the IETF XML Registry using > the > 160 procedures described in RFC 3688 [RFC3688]. IETF namespaces must > be > 161 reserved for IETF specifications. Non-IETF namespaces must be used > 162 for non-IETF specifications; the designated experts may need to > work > 163 with a registrant to identify URIs that can be added to the IETF > XML > 164 Registry. Extensions and any normative reference necessary to > 165 implement the extension must not be denoted with "work in-progress" > 166 or any similar description. > > NEW: > > Extensions should be evaluated for architectural soundness using the > guidelines described in RFC 3735 [RFC3735], including the Security > Considerations section of that document. Expert evaluation should > explicitly include consideration of the privacy consequences of > proposed extensions, and, at a minimum, ensure that any privacy > considerations are fully documented in the relevant specification(s). > URIs proposed in extensions (XML namespace and schema registration > requests are commonly found in EPP extensions) should be evaluated > for both syntactic and semantic correctness. XML schema and > namespace URIs must be registered in the IETF XML Registry using the > procedures described in RFC 3688 [RFC3688] unless they are defined > in an Internet Draft temporarily registered in this registry according > to the procedures of [RFC7120]. IETF namespaces must be > reserved for IETF specifications. Non-IETF namespaces must be used > for non-IETF specifications; the designated experts may need to work > with a registrant to identify URIs that can be added to the IETF XML > Registry. Extensions and any normative reference necessary to > implement the extension must not be denoted with "work in-progress" > or any similar description. > > OLD: > > 210 Document Status: The document status of the specification document. > 211 For RFC documents, the possible set of values includes "Standards > 212 Track", "Informational", "Experimental", "Historic", and "BCP" as > 213 described in Sections 4 and 5 of RFC 2026 [RFC2026]. For documents > 214 that are not RFCs, this will always be "Other". > > NEW: > > Document Status: The document status of the specification document. > For RFC documents, the possible set of values includes "Standards > Track", "Informational", "Experimental", "Historic", and "BCP" as > described in Sections 4 and 5 of RFC 2026 [RFC2026]. For Internet Drafts, > this will be "Temporary". For all other documents this will be "Other". > > OLD: > > 216 Reference: A permanent, publicly available reference to the > 217 specification of this extension. This could be an RFC number or > some > 218 other pointer to the document defining the extension that meets the > 219 "Specification Required" registry policy. > > NEW: > > Reference: A publicly available reference to the specification of this > extension. > For RFCs, this will be the RFC number. For Internet Drafts, this will be a > reference to the draft in the datatracker. For all other documents, this will > be a refernce to the extension that meets the "Specification Required" > registry policy. > > OLD: > > 221 Registrant Name and Email Address: The name and email address of > the > 222 person that is responsible for managing the registry entry. If the > 223 registration is of an IETF Standards Track extension, this can > simply > 224 be listed as "IESG, <[email protected]>". > > NEW: > > Registrant Name and Email Address: The name and email address of the > person that is responsible for managing the registry entry. If the > registration is of an IETF Standards Track extension or an Internet Draft, > this will be "IESG, <[email protected]>". > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
