I agree. If 50% of EPP extensions have not been registered than the goal of 
this registry has not been met.

Given that, the following paragraphs from Section 1 should be struck:

RFCs 3735 and 5730 do not describe how extension development can be managed and 
coordinated. This has led to a situation in which server operators can develop 
different extensions to address similar needs, such as the provisioning of 
Value Added Tax (VAT) information. Clients then need to support multiple 
extensions that serve similar purposes, and interoperability suffers as a 
result.

An IANA registry can be used to help manage and coordinate the development of 
protocol extensions. This document describes an IANA registry that will be used 
to coordinate the development of EPP extensions.


Thanks for pointing this out.

-andy, as an individual

On 05-03-2026 8:26 AM, Gould, James wrote:
I believe that we're getting off topic of the WGLC for 
draft-ietf-regext-ext-registry-epp.  The question is not whether creating EPP 
transports is a good idea, but whether if they are created can they be 
registered in the EPP Extension Registry.  The EPP Extension Registry should 
not be used as a blocker for the creation of EPP extensions, but simply as a 
registry to publish the existence of the EPP extensions.  In the case of the 
EPP Extensibility and Extensions analysis, we only found 60% of the EPP 
extensions analyzed registered in the EPP Extension Registry.  I don't believe 
we identified all the EPP extensions in the wild, so that % is probably around 
40% - 50% that are registered.  I don't view that % in meeting the goal of the 
EPP Extension Registry, which is meant to provide visibility for consolidation 
of EPP extensions.  What is the % that defines success for the EPP Extension 
Registry?  I would put that % around 90% and not 40% - 50% since that would 
make future assessments like the EPP Extensibility and Extensions analysis much 
simpler and complete.

In the case of EoH, there have been multiple independent specifications and 
implementations in the wild that were never registered in the EPP Extension 
Registry.  If the community wants to consolidate on EPP extensions that should 
include the EPP transports, independent of the anticipated number of EPP 
transports and whether having additional EPP transports is a good thing or a 
bad thing.   Consider that the EPP transports will be defined independent of 
the registration in the EPP Extension Registry, which leads to the creation of 
similar incompatible extensions in the wild.


_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to