Re: Launch Phase EPP Extension Version 02 Posted

Jim,
I agree with you and prefer option #3.  What are your thoughts on the auction related statuses that I sent out earlier?

Trung

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Gould, James
Sent: Thursday, August 16, 2012 6:18 PM
To: Keith Gaughan; [email protected]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

In reviewing the thread on the status element of the draft, these are the following options:

1. Keep the status element as a non-extensible enumerated list.  
2. Change the status element to use a enumerated list of status values as an attribute and allow for the element text to be free-form.  The free-form text could be returned to the registrant.  
3. Add an optional name attribute to the status element along with a "custom" status enumerated value to support sub-statuses or custom statuses similar to the approach taken in the draft with the phase element.  
4. Make the status element a token instead of a enumerated list.  I don't believe anyone really proposed this, but I left it in for completeness.  

I would like to have all of the possible known statuses defined in the draft, where if we did a good job in gathering them all, option #1 is the best.  If we don't do a good job of gathering them all then some form of extensibility like option #3 would be needed to enable adding the missing statuses without requiring the creation of a registry specific custom extension.  I believe option #2 is close to using the optional name attribute of option #3 as a sub-status with a slightly different intent of not using the value to drive client-side logic.  

Does anyone know of any concrete statuses that need to be added to help with options #1, #2, and #3?  I don't want the draft to make it too difficult for the clients to handle and I don't want it to be too restrictive to meet specific registry policies that would result in the creation of additional custom extensions.  I believe option #3 is a good compromise, but that's probably obvious since I was the one that originally proposed it.  

I would like to hear from the list if there are any additional options to consider and which option is preferred.  

Jim 

________________________________________
From: [email protected] [[email protected]] on behalf of Keith Gaughan [[email protected]]
Sent: Thursday, August 16, 2012 12:14 PM
To: [email protected]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted

On Thu, Aug 16, 2012 at 04:40:44PM +0100, Gavin Brown wrote:
> On 16/08/2012 16:35, Wil Tan wrote:
> > Yes, that's why I said it's not elegant, but my (possibly wrong) 
> > assumption was that the textual description won't be used by 
> > registrars for automation.
>
> It seems more likely to me that registries would decide to overload 
> this field and then compel registrars to create business logic to handle it.
>
> However, I don't think that his has happened with the <status> element 
> for domains, contacts, and hosts (unless someone wants to correct me), 
> so perhaps I am overstating the risks.

What's happened in those cases is that the registry operators create their own extensions to fit the extra semantics they--being the beautiful and unique snowflakes that they are--feel they absolutely can't possibly live without.

You're not at all overstating the risks. The thing that gets missed in this kind of discussion is that when a registry has discretion over the implementation of some element of EPP or a non-optional extension or object mapping, they effectively multiply the amount of work that needs to be done to implement that by the number of registrars integrated with them. The more that can be done so that registrars don't have to implement dozens of subtly-incompatible variations on the same spec.

K.

--
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/> 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 _______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg