Subject: [provreg] Standard Extensions

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Jan 2012 12:50:11 +0000

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?

If there really is interest I will offer to help us get organized.

Scott

---

From: Keith Gaughan <[email-masked]>
Date: Wed, 18 Jan 2012 13:20:50 +0000

On 18/01/12 12:50, 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?
> 

I'm interested. I've already proposed the garbage collection mechanism and
both James Gould and I have proposed a mechanism for registrars to get
registry policy information, though I proposed it be done separately from
EPP (though ultimately linked to EPP, and possibly listed in the greeting),
and James proposed the use of an object mapping. Those two are things I
personally would like to see developed, and I'm planning on writing up an
I-D on the former at the very least.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Bruno Prémont <[email-masked]>
Date: Wed, 18 Jan 2012 14:36:01 +0100

On Wed, 18 Jan 2012 12:50:11 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?
> 

Another extension that could be useful and was requested by one of our
registrars would be for them to check their status.

It would need:
- their contact data, similar to aggregation of one or more contact
  objects [admin, tech, billing]
- their credit balance (the most important information)
  it should be possible to add extra information such as soft/hard
  limits and possibly some forecast of probable future needs).
- extra key/value pairs, preferably with a few pre-defined types
  (string, currency, number, array) for further information

-- 
Bruno Prémont <[email-masked]>
Ingénieur système et développements

Fondation RESTENA
6, rue Coudenhove-Kalergi
L-1359 Luxembourg

Tél: (+352) 424409
Fax: (+352) 422473
http://www.restena.lu     http://www.dns.lu

---

From: MICHAEL YOUNG <[email-masked]>
Date: Wed, 18 Jan 2012 07:48:39 -0600

Happy to help.  Some things on my interest list:

IDNs
Launch Activities
Possibly Trademark extensions and interactions with the Trademark
Clearinghouse
Possibly some work around compliance enforcement measures (in response to
abuse)

Michael Young

On 12-01-18 6:50 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

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

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Wed, 18 Jan 2012 13:50:29 +0000

Wasn't there already some work being done by Gavin Brown and Wil Tan on handling sunrises etc?

>> If there really is interest I will offer to help us get organized.

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 18 Jan 2012 08:50:48 -0500

> If there really is interest I will offer to help us get organized.

I don't know that there is, but if there is I think your offer is both
generous and useful.

Eric

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 18 Jan 2012 15:09:54 +0100

Definition on notifications from the registry to registrars. (Like i 
proposed i my earlier mail).

The earlier proposed sunrise-period extension

Most european registries have some kind of extension for VAT numbers 
and/or tax-id.

/Ulrich

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Jan 2012 14:19:30 +0000

Scott,

I mirror Michael's interest list with some small additions:

IDNs
Launch Activities (EPP mappings / extensions)
	1. Registrar to Trademark Clearinghouse
	2. Registry to Trademark Clearinghouse
	3. Registrar to Registry
Registry Mapping - Provide features and policies for a TLD or set of
TLD's.  
Consolidate / Standardize Custom Extensions - For example some of the ones
we have created:
	1. IDN Language Tag - Already being worked on with
draft-obispo-epp-idn-00.txt
	2. RGP Poll Mapping
	3. ConsoliDate Mapping
	4. NameStore Mapping - Renamed
	5. Low Balance Mapping
	6. WhoWas Mapping
	7. Client Object Attribute Mapping

I fully support this effort.

--
  
JG

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

---

From: Theo Kramer <[email-masked]>
Date: Wed, 18 Jan 2012 16:20:10 +0200

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

Zone policy definitions

-- 
Regards
Theo

---

From: Gavin Brown <[email-masked]>
Date: Wed, 18 Jan 2012 14:23:47 +0000

> Wasn't there already some work being done by Gavin Brown and Wil Tan on handling sunrises etc?

We still intend to develop the LaunchPhase extension draft, but both Wil
and I are very busy right now. Apparently there's a new gTLD round!

One other thing on my wishlist for EPP is an extension to add a
legal/personal attribute to contact objects, for EU data protection laws.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Howard Eland <[email-masked]>
Date: Wed, 18 Jan 2012 08:26:15 -0600

I'll be glad to help as well.

-Howard Eland
Afilias

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 18 Jan 2012 15:50:10 +0100

I am happy to help but want live extensions harmonized and standardized before we add even more bloat to the protocol.

   Patrik

---

From: Keith Gaughan <[email-masked]>
Date: Wed, 18 Jan 2012 16:47:58 +0000

> I mirror Michael's interest list with some small additions:

<snip>

> 	2. Registry to Trademark Clearinghouse

Wil Tan's work covers at least the Registrar to Registry part of this well
enough.

> 	2. RGP Poll Mapping

Might it be best to fold this into a revised version of RFC 3915?

> 	5. Low Balance Mapping

This might be best generalised into an account information mapping. It'd be
nice to be able to programmatically update various notification addresses
and balance watermarks in addition to querying or being notified of the
balance.

K.

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Jan 2012 16:56:45 +0000

> Wil Tan's work covers at least the Registrar to Registry part of this

I believe Wil's work is a good starting point, but it is highly dependent
on the flow of sunrise and the rights periods.  All 3 interfaces are
dependent on each other based on the TMCH flow that has yet been fully
defined.  

> Might it be best to fold this into a revised version of RFC 3915?

I originally asked for this to be in RFC 3915 but there was objection to
it, so I had to create my own custom extension.  Combining these would be
a good item to discuss.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 19 Jan 2012 01:10:51 +0100

Hollenbeck, Scott <[email-masked]> 2012-01-18 13:51
> 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 funct…
 
First and foremost, finding an incentive for current registry
operators to implement those extensions instead of their own
proprietary, otherwise we will just have even more extensions and even
less consolidations.
To me, it looks more difficult and more important, than creating the
extensions themselves.

At the very minimum any new extension created that is a factorisation
of extensions already existing should have a section explaining how it
will replace the current existing ones.

You will also soon, I think, hit the kind of question like "is this
not a limit of the protocol, and should'nt the protocol itself be
amended" aka EPP v2.0 ?
I'm thinking for example about result codes that each registry extend
in some way with new values, more or less properly...
Same for object status.

And for something a little more new, handling of contacts and DNSSEC
related content during a domain:transfer.

As for the extensions themselves, the whole section 3 of
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt
may give ideas.
Or the source of the opensource client that made me write this draft
in the past, which contains numerous current registry extensions.

HTH,

-- 
Patrick Mevzek

---

From: Mike O'Connell <[email-masked]>
Date: Thu, 19 Jan 2012 13:15:00 +0200

We (.co.za EPP) have had a few requests for the credit balance from our registrars too, as well as the ability to fetch an invoice or statement (which I think should remain out-of-band).

Leading from that I think a synchronization extension would be very helpful which could possibly include:

  Domain Listing: I know domain listing functions have come up before but the sheer volume is staggering. 
    What about fine tuning a listing to search by contact and/or creation date? 
    Or retrieving the data in batches and fetching the delta at the end?

  Contact Listing: To list all contacts associated with the registrar as well as very basic information. 

These commands would only be run by a registrar to retrieve their own objects.

--

Michael O'Connell

---

From: Mike O'Connell <[email-masked]>
Date: Thu, 19 Jan 2012 13:18:08 +0200

> related content during a domain:transfer.

This would be extremely handy, if we can specify the future contact and DNSSEC information when performing the domain:transfer we would save on contact GC (touchy subject). I'll happy assist here...

--

Michael O'Connell

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Jan 2012 12:17:05 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Patrick Mevzek
> Sent: Wednesday, January 18, 2012 7:11 PM
> To: [email-masked]
> Subject: Re: [provreg] Standard Extensions
> 

We've actually considered that question more than once in recent years. I'm still unconvinced that there's a need to reopen the core protocol, especially for niche data structures that can be specified in an extension. I don't yet see the benefit outweighing the cost. Having said that, maybe it makes sense to create a standard extension for additional result codes and status values.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Jan 2012 11:21:00 -0500

>To me, it looks more difficult and more important, than creating the

I think that is a very important point.  In Oct 2009 I began a short 
look into EPP 2 after comments at a CENTR Tech meeting.  There was a 
"bar bof" at the IETF in March 2010 and a follow up discussion at the 
CENTR Tech meeting in May 2010.  (Dates given to set date context.) 
At the follow up, the consensus was that the cost to upgrade from an 
EPP 1 to an EPP 2 was not worth any perceived benefit.

I'm not saying there will never be a need for EPP 2 but Patrick is 
very right.  We have to justify the move to an upgraded EPP, not just 
define a new EPP version.  Analogously, DNSSEC stalled until 
Kaminsky's work increased the "perceived benefit".  DNSSEC didn't 
change and the basic problem it was meant to solve didn't change, but 
the perception of the benefit shifted.  And, to borrow from IPv6, we 
need to consider the transition from EPP as it is today to any follow 
on version.

And I should add this.  Before significant work happens on this list, 
the list has to be publicized as widely as needed.  Part of what was 
learned in 2009-2010 was that once the WG that used to cover this 
list was closed, few newcomers learned of the list.  I'm not saying, 
don't do work but keep in mind there may be interested and informed 
parties that are not aware of this discussion.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 19 Jan 2012 16:49:11 +0000

>> To me, it looks more difficult and more important, than creating the

That reminds me of this: http://xkcd.com/927/

> I think that is a very important point.  In Oct 2009 I began a short look into
> EPP 2 after comments at a CENTR Tech meeting.  There was a "bar bof" at the
> IETF in March 2010 and a follow up discussion at the CENTR Tech meeting in May
> 2010.  (Dates given to set date context.) At the follow up, the consensus was
> that the cost to upgrade from an EPP 1 to an EPP 2 was not worth any perceived
> benefit.
> 
> I'm not saying there will never be a need for EPP 2 but Patrick is very
> right.  We have to justify the move to an upgraded EPP, not just define a new
> EPP version.  Analogously, DNSSEC stalled until Kaminsky's work increased the
> "perceived benefit".

Any new extension or object mappings we come up with do have one advantage
given ICANN's new gTLD program. ccTLDs and gTLDs differ in that ccTLDs have
captive national audiences and can largely do what they like. gTLDs are
different: as they're global, they lack the inherent registrant audience of a
new ccTLD would have. Thus any new gTLD is going to be competing with other
new gTLDs for registrar mindshare. Speaking as a registrar, we're more likely
to integrate our systems with registries that require less work no our part,
thus fewer proprietary extension and object mappings they have, the more
likely a registrar is to go to the trouble of integrating their systems.
That's our "perceived benefit". It's the same reason incumbents in the gTLD
arena have a built-in advantage: registrars will likely have already
implemented their proprietary extensions, so the barriers to integration are
lower.

Of course, things are going to be a bit more complex than that, and ease of
integration isn't the only factor that's going to sway which new gTLDs
registrars deal with, but it's a powerful incentive nonetheless.

K.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 19 Jan 2012 12:39:04 -0500

On 1/19/12 11:49 AM, Keith Gaughan wrote:
> ... the consensus was
>> benefit. ...

YMMV, but there may a fundamental difference of interests between
registrars selling VGRS inventory and hoping to cover as many other
protocol-and-logically distinct sources of inventory at the lowest
cost and registrars (possibly co-owned by registry market entrants)
hoping to cover some distinct sources of inventory, and incidentally
also selling inventories for which protocol-and-logic clients exist.

Consensus among legacy-centric-registrars isn't in itself attractive
to a registry operator sharing no fate with legacy registry operators,
and adequately served by OT&E interoperable registrars.

Eric

---

From: "Ning Kong" <[email-masked]>
Date: Fri, 20 Jan 2012 11:18:22 +0800

> 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?
I'm very interested in developing EPP extensions for IDNs (especially for
variant IDNs) in order to simplify the synchronization of some or all the
attributes among variant IDNs. I'd like to write such drafts based on the
ideas of draft-kong-epp-cdn-mapping-00 and
draft-kong-epp-cdn-dnssec-mapping-00.

> If there really is interest I will offer to help us get organized.
Thanks, Scott.
You know, there are a few guys interested in EPP extensions for variant IDNs
on this list. So I was going to organize a bar bof @ IETF 83 to discuss EPP
extensions for (variant) IDNs. But I would be glad if there could be a more
general bof to discuss EPP extensions.

Cheers,
Ning

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 24 Jan 2012 00:59:12 +0100

Hollenbeck, Scott <[email-masked]> 2012-01-19 13:18
> Having said that, maybe it makes sense to create a standard extension for additional result codes and status values.

I believe so.

And then, if you make it happen that everyone switch from their
current homegrown version to this extension, you may find out that all
registries or almost all of them need this extension, which in a way
shows that the feature should be in the core protocol.
But things will technically work out the same way while in an extension.

*If* everyone switches to it.

Which I'm far to believe.

Hence another argument to include it in some EPPv2 if there is some
work on that one day, because then the feature will be "free" when you
switch to this version, no more extension. And in that way it is
really an incentive (one extension less to code for registrars).

-- 
Patrick Mevzek

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 24 Jan 2012 11:59:53 +0000

> Sent: Monday, January 23, 2012 6:59 PM
> To: [email-masked]
> > Having said that, maybe it makes sense to create a standard extension
> for additional result codes and status values.
> 
> I believe so.
> 

I'm with you on the switching part, but I'm not convinced that there really is significant demand. How many registries are using custom result codes and status values?

Scott

---

From: "Gould, James" <[email-masked]>
Date: Tue, 24 Jan 2012 13:04:46 +0000

We haven't had the need for an extension for result codes or status values
for root, .com, .net, .edu, .cc, .tv, .jobs and our additional services
(name suggestion, whowas, etc.).  For .name we only needed to include a
sub-result code of 2305 "Object association prohibits operation" on the
create response of domain and emailfwd for providing more clarity on which
object prohibits the operation (1 "Corresponding service exists" or 2
"Conflicting defensive registration exists").  I'm not sure if any of the
Registrars for .name are utilizing this feature of the "Personal
Registration" extension to drive their client-side logic.  In general we
stick with the result codes and status values defined in the RFC's.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 1/24/12 6:59 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>I'm with you on the switching part, but I'm not convinced that there
>really is significant demand. How many registries are using custom result
>codes and status values?
>
>Scott

---

From: Jay Daley <[email-masked]>
Date: Wed, 25 Jan 2012 13:02:10 +1300

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

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

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 25 Jan 2012 01:01:42 +0100

Hollenbeck, Scott <[email-masked]> 2012-01-24 13:01
> How many registries are using custom result codes and status values?

Indeed, I rewrote myself saying almost any registry, because I had in
mind VeriSign which does not need custom codes.

However as an EPP client implementor I've seen registries using their
own result codes/status values in such ways:
- either just adding items to the associated lists, breaking the EPP
  XML Schema validation (for the brave souls doing it live)
- or adding "sub" values, that is besides standard ones
- or creating a true EPP extension, in the RFC 3735 sense, with new
  values.

Looking at my code I see at least the following:
.FR
.AT / IENUMAT
.BE
.EU
.LU
.NO
.NL
.CA

but I'm not really keeping track of list of specific statuses, so
there may be some more, maybe some registrars could provide more info.

-- 
Patrick Mevzek

---

From: Gavin Brown <[email-masked]>
Date: Wed, 25 Jan 2012 09:43:35 +0000

> 	- but not XML-Dsig – complete disaster (http://www.cs.auckland.ac.nz/~pgut001/pubs/ xmlsec.txt)

I had a stab at an Internet-Draft for this:

https://raw.github.com/jodrell/draft-brown-eppSig/master/draft-brown-eppsig.txt

There's PHP code that implements signing and validation here:

https://github.com/jodrell/draft-brown-eppSig/tree/master/tests

it uses XML-DSig, which I accept has some issues.

G.

---

From: "Gould, James" <[email-masked]>
Date: Wed, 25 Jan 2012 14:10:37 +0000

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
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

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

>	- SAMLv2.0 HTTP POST 'SimpleSign¹ Binding
>	- 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.  
>
>- 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
>
>
>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

---

From: Theo Kramer <[email-masked]>
Date: Wed, 25 Jan 2012 16:32:07 +0200

> servers send rather than the protocol.

and

>> description the servers send rather than the protocol.

+1 - the co.za (and .za) team would be prepared to provide input into this model.

-- 
Regards
Theo

---

From: Jay Daley <[email-masked]>
Date: Thu, 26 Jan 2012 13:48:08 +1300

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

> 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

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

---

From: Jay Daley <[email-masked]>
Date: Thu, 26 Jan 2012 14:32:48 +1300

> 3.  Change the command extension mechanism to use SubstitutionGroup to give first class extensions.  

To explain this a bit better, here is some XML Schema:

  <!-- New types and elements to support substitutionGroup -->

  <complexType name="abstractCommandType" abstract="true"/>
  
  <!-- We need an element here that is the target of a substitutiongroup attribute later on -->
  <element name="abstractCommand" type="epp:abstractCommandType" />
    
  <complexType name="commandType">
    <sequence>
      <element ref="epp:abstractCommand"/>
      <element name="extension" type="epp:extAnyType"
        minOccurs="0"/>
      <element name="clTRID" type="epp:trIDStringType"
        minOccurs="0"/>      
    </sequence>
  </complexType>

  <element name="check" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="create" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="delete" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="info" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="login" substitutionGroup="epp:abstractCommand" type="epp:loginType"/>
  <element name="logout" substitutionGroup="epp:abstractCommand" />
  <element name="poll" substitutionGroup="epp:abstractCommand" type="epp:pollType"/>
  <element name="renew" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>
  <element name="transfer" substitutionGroup="epp:abstractCommand" type="epp:transferType"/>
  <element name="update" substitutionGroup="epp:abstractCommand" type="epp:readWriteType"/>

  <complexType name="readWriteType">
    <complexContent>
      <extension base="epp:abstractCommandType">
        <sequence>
          <any namespace="##other" />
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  
  <complexType name="loginType">
    <complexContent>
      <extension base="epp:abstractCommandType">
        <sequence>
          <element name="clID" type="eppcom:clIDType"/>
          <element name="pw" type="epp:pwType"/>
          <element name="newPW" type="epp:pwType"
            minOccurs="0"/>
          <element name="options" type="epp:credsOptionsType"/>
          <element name="svcs" type="epp:loginSvcType"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  
  <complexType name="pollType">
    <complexContent>
      <extension base="epp:abstractCommandType">
        <attribute name="op" type="epp:pollOpType"
          use="required"/>
        <attribute name="msgID" type="token"/>
      </extension>
    </complexContent>
  </complexType>
  
  <complexType name="transferType">
    <complexContent>
      <extension base="epp:abstractCommandType">
        <sequence>
          <any namespace="##other"/>
        </sequence>
        <attribute name="op" type="epp:transferOpType"
          use="required"/>
       </extension>
    </complexContent>
  </complexType>

cheers
Jay