Re: Standard Extensions

Jay,

<4.  Currently EPP *defines* a data model for domain name registrations,
which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz
data model).   If the <ICANN data model changes at any point then amending
EPP will require lots of effort all round.  It might be better to pre-empt
this by moving to an alternative <approach where the EPP protocol is used
to *describe* the registration data expected.  If then it was agreed that
all gTLD registrations must include say a <registrant type as they have in
.uk, then this could be added merely by updating the description the
servers send rather than the protocol.

Could this item be addressed with a Registry EPP Mapping, as I've shortly
described previously, that provides the meta-data (features and policies)
for each TLD supported by the EPP server?  Examples of attributes that
could be included in a Registry Info Response is defined below.  This EPP
Mapping would be large and it would need to be flexible to define the
features and policies of Registries that support the RFC's.  I would like
to have the working group, if formed, help define this mapping so that
multiple registries support it and it is useful for the registrars.

O name 
O phase 
	- sunrise? (Optional to support existing TLD's)
		+ startDate
		+ endDate
	- rights? (Optional to support existing TLD's)
		+ startDate
		+ endDate
	- open 
		+ startDate
		+ endDate?
O services 
	- namespace URI's+ (note - A single EPP connection could support more
than one TLD with a different set of supported services)
O extensions
	- namespace URI's* (note - A single EPP connection could support more
than one TLD with a different set of supported extensions)
O domain
	- level+
		+ minLength
		+ maxLength
		+ regex+
		+ reservedNames?
	- ns
		+ min
		+ max
	- requiredContacts? (Optional to support thin registries)
		+ registrant
		+ admin?
		+ tech?
		+ billing?
	- gracePeriods
		+ create
		+ renew
		+ autoRenew
		+ transfer
	- period
		+ create
			# min (unit)
			# max (unit)
		+ renew 
			# min (unit)
			# max (unit)
		+ transfer
			# min (unit)
			# max (unit)
	- rgpPeriod 
		+ redemptionPeriod
		+ pendingRestore
		+ pendingDelete
	- dnssec 
		+ dsData?
			# min
			# max
			# algorithm+
			# digestType+
		+ keyData?
			# min
			# max
			# algorithm+
		+ maxSigLife
			# supported
			# default
			# min?
			# max?
		+ urgent
			# supported
	- authInfo
		+ regex+
	- pendingActions?
		- create
		- update
		- renew
	- idn
		...
O Host
	...
O Contact
	...


--
  
JG
 

 
James Gould
Principal Software Engineer
[email protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 1/24/12 7:02 PM, "Jay Daley" <[email protected]> wrote:

>
>On 19/01/2012, at 1:50 AM, Hollenbeck, Scott wrote:
>
>> Let's assume for a moment that we have enough interest to form a
>>working group focused on the development of a set of standard EPP
>>extensions. If we had to start writing a charter today, what
>>functionality would people most like to see included?
>
>Two extensions that are on my todo list to write up but never get to the
>top:
>
>1.  Cryptographic signatures.   Lots of XML apps do this using a variety
>of mechanisms:
>
>	- PGP in special tags <pgp></pgp>
>	- S/MIME as used in XMPP (Jabber)
>	- SAMLv2.0 HTTP POST 'SimpleSign¹ Binding
>	- Detached PGP signatures (as per .nz DNRS protocol)
>	- but not XML-Dsig ­ complete disaster
>(http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt)
>
>2.  Delegation errors/warnings.  A variety of TLDs check the delegation
>data and the nameservers before entering the data into their zones (note,
>in .nz we do not).  Such checks include whether the nameserver are
>serving the zone, whether the serial numbers are the same, whether all
>the authorities reported are being configured in the parent zone and so
>on.  
>
>A standard extension around this would be useful for
>- a TLD that does checks advertising that fact (and what those checks are)
>- reporting failures if doing checks
>- optional support for a TLD that will provide this information to a
>registrar upon request, but not run proactive checks or interfere with
>the delegation process
>
>
>Then there is the big change to the core protocol I've always wanted to
>do:
>
>3.  Change the command extension mechanism to use SubstitutionGroup to
>give first class extensions.
>
>
>And finally something for us to think about:
>
>4.  Currently EPP *defines* a data model for domain name registrations,
>which fits gTLDs and some ccTLDs but not all (note, it does fit the .nz
>data model).   If the ICANN data model changes at any point then amending
>EPP will require lots of effort all round.  It might be better to
>pre-empt this by moving to an alternative approach where the EPP protocol
>is used to *describe* the registration data expected.  If then it was
>agreed that all gTLD registrations must include say a registrant type as
>they have in .uk, then this could be added merely by updating the
>description the servers send rather than the protocol.
>
>
>cheers
>Jay
>
>-- 
>Jay Daley
>Chief Executive
>.nz Registry Services (New Zealand Domain Name Registry Limited)
>desk: +64 4 931 6977
>mobile: +64 21 678840
>
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg