Re: Launch Phase EPP Extension Version 02 Posted

I agree with the advantages of having enumerated list of statuses.  However I can’t believe that we know enough about each registry policy that would take into account all of the different status variations.  So someone will end up using custom EPP extension to capture these other statuses that were not defined in this draft.

Concerning auction related statuses, we have used auction pending, auction awarded, and auction rejected.  If there are other ways to capture this info besides status, please let me know.

Trung


From: [email protected] [mailto:[email protected]] On Behalf Of Wil Tan
Sent: Thursday, August 16, 2012 11:35 AM
To: Gavin Brown
Cc: [email protected]
Subject: Re: [provreg] Launch Phase EPP Extension Version 02 Posted


On Fri, Aug 17, 2012 at 1:18 AM, Gavin Brown <[email protected]<mailto:[email protected]>> wrote:

On 16/08/2012 16:09, Wil Tan wrote:
> On Thu, Aug 16, 2012 at 10:03 PM, Gould, James <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>> wrote:
>
>     I agree that we should predefine as many known statuses as possible
>     in the draft as an enumerated list.  How about if we take the
>     approach of the launch phases with the inclusion of a "custom"
>     status and an optional name attribute that can be used for define a
>     sub-status of one of the enumerated statuses or used to define a
>     completely custom status?  We can expand the enumerated list now for
>     auction statuses if those statuses are known.  Trung, do you have
>     any specific statuses that should be added now?  Would this meet the
>     needs of a predefined list of statuses with some form of extensibility?
>
>
> Just as a data point, these were the statuses that Cloud Registry used
> when we last did our sunrise and land rush auctions. They were certainly
> adequate for us. Also, while not technically elegant, I suspect we can
> satisfy the majority of use cases by conveying fine-grained statuses
> with <launch:status> textual content:
>
>   <launch:status s="validated">auction in-progress</launch:status>
Wouldn't this effectively be another free text element that servers will
overload with their own special meanings? If anything that appears
inside that element requires client processing, registrars will be in
the same situation as I previously described.


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 would primarily be used for answering customer queries about "I applied for this domain, do I have it yet and if not, why not?" The enumerated "s" attribute values are what matters to the state machine, and it's important to keep it simple.

I agree that we should try to capture statuses that registries might need, rather than providing yet another extensibility point.

.wil

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