Nope. RFC 8126 says that IANA registries are for interoperability. That is the
purpose of IANA registries. If you want to make others aware of what you have
done, I suggest LinkedIn.
-andy
On 05-03-2026 2:46 PM, Gould, James wrote:
Andy,
Should we replace those paragraphs with an agreed upon goal for the registry,
such as?
The goal of the registry is to publish the known existing extensions for
visibility for consolidation and to reduce functional duplication.
Thanks,
--
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 3/5/26, 2:40 PM, "Andy Newton" <[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.
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] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
