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

On Thu, 2011-06-16 at 23:45 +1000, Wil Tan wrote:
>         
>              * MUST have 1 or more <status> codes from the set:
>         [pending,
>                validated, invalid, cancelled, allocated] (Q: possibly
>         others?)
> 
> 
> I like Jan's suggestion to rename "cancelled" to "rejected" to be
> consistent with the action in transfer operations (though they're
> different things.)

No objection from me.

> 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.

There are definite benefits to having a fixed list of codes: mainly it
makes things easier for registrars who don't need to write so many
"case" statements in their switches. I seem to remember someone
suggesting a text attribute providing explanatory text, this might
provide a way to signal further information if needed.
 
>              * 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".

Agreed.

>              * if phase=SR, MAY have one or more <claim> elements. a
>         <claim>:
>                      * MUST have a boolean "preVerified" attribute
>                      * if preVerified=1:
>                              * MUST have a <pvrc> element
>                              * MAY have a <issuer> element. an
>         <issuer>:
>                                      * identities a contact object in
>         the
>                                        registry
> 
> 
> I'm not sure we need to dictate a particular way in which a registry
> may identify an issuer. It could well be a static published list of
> identifiers for the accepted issuers. Must it be a contact object?

Using a contact object solves the scenario where a registry might not be
aware of all the authorities that might issue something that is the
basis of a claim. For example, CentralNic is currently preparing for a
sunrise in which applicants can apply for a domain name based on a
German registered company name: in Germany, there is no central register
of companies, instead you go to your local court, so there are hundreds
(if not thousands) of legitimate authorities, and it would be difficult
for us to know of them all.

Using a contact object means that if needed, the client can provide all
the information that a validation agency might need to verify the claim:
not just the name of the issuing authority, but its address and other
contact information.

If a registry's policy restricts claims to a single issuing authority,
then it's simple for them to create a contact object corresponding to
that authority, and require all registrars to use that contact object's
ID when submitting their application. But it also allows for an "open"
model as I described above, without duplicating the fields from a
contact object into the extension.

>                              * MUST have a <claimCountry> from the ISO
>                                3166-alpha2 set
> 
> Shouldn't this be the "WIPO Standard ST.3"
> <http://www.wipo.int/export/sites/www/standards/en/pdf/03-03-01.pdf>
> list?

Using it here would make the "claimCountry" element name inaccurate.
This list seems to be ISO 3166-alpha2 plus a number of 2-character codes
identifying international trademark bodies such as WIPO. Since these
bodies don't issue trademarks themselves, I don't see what benefit we'd
get if we used it instead of 3166.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

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