Does the RST 2.0 registration requirement also apply to implementations of
active extension drafts? Imagine that a registry implemented a draft version
of the registry fee extension prior to it becoming an RFC and the registry
needed to pass RST 2.0. Would the registry need to register the draft version
in the EPP extension registry or worse yet copy the draft extension and
register it as a proprietary extension retaining the IETF namespace? The XML
namespace is not easily changed when registries choose to implement the draft
extension, since it will impact all registrars using that extension version.
The implementation of draft versions has been done with EPP from the beginning.
Consider the 04/02 days of EPP, when registries implemented the -04 version of
the base EPP draft and the -02 version of the object mapping drafts. The use
of point versioning of the XML namespace helped with the 04/02 days of EPP, but
draft versions of EPP extensions have been implemented with the launch phase
extension and the registry fee extension to name a couple. I believe we should
encourage the implementation of draft extensions that hopefully do become RFCs,
where there are instances that the draft extensions did not progress to RFC.
We can't foresee all the use cases going forward, but we certainly know the use
cases that have occurred over the past 20 years. I see the following
high-level use cases based on past experience:
1. Registries implement draft extensions prior to them becoming RFCs.
This should be encouraged and is the happy use case, where the RFCs get
registered, but there is an issue if there is an RST 2.0 requirement to
register draft extensions.
2. Registries implement draft extensions that eventually become abandoned for
various reasons.
We should encourage implementation, and we have not defined the
appropriate path for registries that have implemented draft extensions that are
abandoned by the working group. Should they copy the extension drafts and make
them proprietary extensions and if so, what happens when more than one registry
does this? What happens with the XML namespace, since a change in the XML
namespace has operational impacts and will cause fragmentation that registrars
would have to deal with?
3. Registries implement proprietary extensions to get around the risk of EPP
extension registry roadblocks.
This would be counter to our goal of consolidating and standardizing
the EPP extensions. Look at the number of proprietary extensions in the EPP
extensibility and extension analysis, which I don't believe we'll want to
encourage.
The MUST language being proposed in draft-ietf-regext-ext-registry-epp would
drive registries away from implementing extension drafts due to the EPP
extension registry hurdles. I don't believe that's the direction we want to
go.
--
JG
James Gould
Fellow Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 10/22/25, 10:59 AM, "Hollenbeck, Scott"
<[email protected]
<mailto:[email protected]>> wrote:
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.
> -----Original Message-----
> From: Andy Newton <[email protected] <mailto:[email protected]>>
> Sent: Tuesday, October 21, 2025 2:57 PM
> To: Hollenbeck, Scott <[email protected]
> <mailto:[email protected]>>;
> [email protected] <mailto:[email protected]>;
> draft-ietf-regext-ext-registry-
> [email protected] <mailto:[email protected]>; [email protected] <mailto:[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.
>
>
> On 10/21/25 14:23, Hollenbeck, Scott wrote:
> >> Once there is an implementation of a particular version of an I-D,
> >> does that mean a WG or the IETF are no longer free to change the
> specification?
> >
> > [SAH] Of course not, but you dodged *my* question. What are we trying to
> accomplish? If our goal is transparency, I see more benefit in allowing the
> EPP
> registration, not registering the squatted-on namespace URNs, and adding a
> note to the EPP registry entry that the registered extension references
> unregistered URNs than in rejecting the EPP registration.
>
> So the IETF should sanction a process whereby the IETF's own BCP is being
> violated? Then what is the point of having namespaces in EPP if they can be
> violated? (which also brings up the issue that the DEs should be checking to
> make sure new registrations aren't re-using URIs that are already registered)
> Also, what happens if the IETF un-abandons the work?
>
> The point I was attempting to make above is that if an implementation can
> change within the WG process, it can change outside of it as well. That is,
> the
> registration of the "abandoned" extension should have changed to use a non-
> conflicted URI.
>
> Also, the point of the IANA registry is interoperability. To that end,
> mistakes
> made in the past should not continued to be made in the future.
[SAH] When dealing with a non-RFC specification, registration of both the EPP
extension and any XML schemas and/or namespaces is voluntary. There's no BCP
(are you referring to BCP 81?) violation if no one requests registration of the
values. So let's imagine that some submits a request to register an EPP
extension, and an expert notices that an XML namespace hasn't been registered.
If this draft says that the namespace MUST be registered in order to register
the EPP extension, and the requestor refuses to do so for some reason, the
extension registration request must be rejected and we lose information
describing the extension. If the draft says SHOULD be registered, we can still
register the EPP extension if the namespace isn't registered. I agree that it
isn't optimal, but I'd prefer to have the extension registered without the
namespace being registered as opposed to not registering the extension at all.
As I wrote above, we can always add a note in the EPP extension registry that
the namespace hasn't been registered for some reason.
We're talking about adding a normative requirement that will have an impact on
the DE review process. I'll repeat what I wrote yesterday about wanting more
input to better measure consensus.
Scott
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
