Re: Launch Phase EPP Extension Version 02 Posted

Tran,

We must have been typing at the same time yesterday, since I got your
e-mail with the auction statuses after sending my message.

I recommend adding the pendingAuction status and merging the "auction
awarded" status into the existing allocated status and the "auction
rejected" status into the existing rejected status.  The description of
the pendingAuction status could be "application pending based on results
of auction".  The state transition section could add the optional
pendingAuction status between the validated status and the rejected,
allocated statuses.  What do you think of this?

Are there any other additional known statuses that we should add?

--
  
JG
 

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







On 8/17/12 2:21 PM, "Tran, Trung" <[email protected]> wrote:

>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