Re: Standard Extensions

On 26/01/2012, at 3:10 AM, Gould, James wrote:

> 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?

Possibly, though that is widening it as I was only thinking of registration data.  Specifically I meant an alternative to RFC 5733 that provides a syntax for a registry to specify what data is expected for their contact objects.  e,g.

	<field name="name" type="text" pattern="..." mandatory="yes" />
	<field name="voice" type="tel" mandatory="no" />

Using the HTML5 syntax for type, pattern etc so we don't need to reinvent it and so that a registrar can extract the data and directly create a web form from it.

>  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.

Reading your mapping below I would suggest that it might be useful split this out into different chunks and tackle each one separately.  My initial split would be

(a)  Registration data requirements
(b)  Nameserver data requirements
(c)  Nameserver configuration requirements
(d)  State machine details.  What states, how long in each one, etc
(e)  Services   

and my thoughts on doing these:

- (a) Is what I was on about above
- (c) I mentioned in my earlier post as 'delegations/warnings'
- (d) may be very ambitious, but then others have successfully done it in order to produce a fully customisable registry server (co.za for example!)
- (e) sounds impossible to standardise given how much our market is developing

cheers
Jay

> 
> 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
> 


-- 
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