Re: Another look at the data model for launch phase registrations

Wil Tan <[email protected]> 2011-06-16 15:47
> >      * MUST have 1 or more <status> codes from the set: [pending,
> >        validated, invalid, cancelled, allocated] (Q: possibly others?)
> 
> I'm ambivalent about allowing the status field to be extended. These status
> values suited our use case fine, but others may have a need for a different
> set of values.

I would prefer to have the extension being as extensible itself as
possible.
Fixed list of status code in EPP is one of the most visible problems,
as nearly all registry need to extend that list in some way.
So I would argue: provide a set of "sensible" (aka currently known)
status codes, but make the schema in such a way that other status
could be added.
Extended statuses could be mandatory to follow a specific form (to
separate them from standard ones, and from one registry to another),
such as the often used "X-" prefix, or following the contact srids
having some sort of registry id being prepended or appended to the
status, or available along it.

Also, allowing a free text to be attached to a status is useful for
providing extra information.

> 
> >      * MUST have a <phase> from the set [SR, LR] (Q: should we let
> >        servers define further phases?)
> >
> 
> I think <phase> should be optional, and it should just be free form. I can
> definitely see use cases for mini launch phases such as "2char-release".
 
Same comment as previously: I would prefer not free form but instead
a list of current sensible values (but without the need to compress
them to 2 chars, "sunrise" is ok and better in my view than SR), and a
way to easily extend them without having to redefine the extension.

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