Re: Launch Phase EPP Extension Version 02 Posted

On Fri, Aug 17, 2012 at 1:18 AM, Gavin Brown <[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]>> 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