I like the idea. Let's see what others say. Pawel
On 23.10.25 14:11, Hollenbeck, Scott wrote:
-----Original Message----- From: Pawel Kowalik <[email protected]> Sent: Thursday, October 23, 2025 1:04 AM To: Hollenbeck, Scott <[email protected]> Cc: [email protected]; Gould, James <[email protected]>; draft-ietf-regext-ext- [email protected]; [email protected] Subject: [EXTERNAL] Re: [regext] Re: WG Last Call: draft-ietf-regext-ext-registry- epp-00 (Ends 2025-10-27) Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Scott, XML schema/namespace registration is not required however, so choice b) is still possible correct? We are deciding about registration rules for EPP extensions, and I think a toll gate of draft being WG adopted to registrier it with IETF namespace may be the right balance. Viele Grüße / Kind regards Pawel Kowalik[SAH] It's possible up to a point. A draft can define a value in the IETF namespace, but that's something that we should only encourage for drafts that are intended for RFC status. The issue arises when an attempt is made to register the value(s). The guidance in 3688 says "it must be documented in a RFC". Since drafts aren't RFCs, and they haven't been through WG or IETF last calls to measure consensus, I have to believe the experts would reject any request to register values in the IETF namespace based on a non-RFC specification. We'll have to face this issue if we decide to request registration of the namespace and schema URNs that are described in abandoned WG drafts as part of any attempt to register the draft specifications in the EPP extension registry. Let's explore the idea that you floated in your reply to James: "Would there be any value in introducing additional status to the registration as “Internet Draft”, “In Development” or alike?" Maybe we can use "MUST register" for the "Standards Track" and "Informational" document status values, and "SHOULD register" for the "Other" and "In Development" statuses. Would that help? ScottOn 22. Oct 2025, at 16:57, Hollenbeck, Scott <[email protected]>wrote:-----Original Message----- From: Pawel Kowalik <[email protected]> Sent: Tuesday, October 21, 2025 12:31 PM To: Andy Newton <[email protected]>; Gould, James <[email protected]>; Hollenbeck, Scott <[email protected]>; draft-ietf-regext-ext-registry- [email protected]; [email protected] Subject: [EXTERNAL] Re: [regext] Re: WG Last Call: draft-ietf-regext-ext-registry- epp-00 (Ends 2025-10-27) Hi, I think it's ok to say MUST but same time not apply this retrospectively to already registered extensions. Similar approach as proposed in the RDAP extensions draft. Fixing those sins of the past will cause more problem than it solves. Also I see additional question: what makes an "IETF specification"? Taking this literarily one would not be allowed to register an extension with IETF namespace until it becomes RFC. Taking into account extension development, some deployments happen already in themean time. So the choice is to:a) have different namespace during development -> downside is change of namespace in already existing deployments and clients after it becomesRFC.b) say that drafts under IETF change control (so from the point of WG adoption) can use IETF namespace, which is more pragmatic approach imho and solves the issue with abandoned drafts, as those even if abandoned still remain under IETF change control[SAH] Thanks for the input, Pawel. I agree that I'd rather not see any changeapplied retroactively. With respect to choice "b" above, the issue is that RFC 3688 says this: "NOTE: in order for a URN of this type to be assigned, the item being registered MUST have been through the IETF consensus process. Basically, this means that it must be documented in a RFC." Drafts aren't RFCs, so I doubt that a request to register a value in the IETF namespace with an I-D reference specification will be approved.Scott
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
