Subject: [provreg] Another look at the data model for launch phase registrations

From: Gavin Brown <[email-masked]>
Date: Tue, 14 Jun 2011 14:33:02 +0100

Hi all,

I've been cogitating on the sort of data model that would meet our
requirements, based on the discussions on this list and also with other
people in the trademark world.

I'm proposing a new data model for "sunrise" phases, where applicants
generally have a claim over a string based on a trade mark, which may be
registered with a national authority, or a "common law" trademark such
as a company name.

The model is flexible in that multiple claims may be submitted - as
Jothan suggested previously - and the specific nature of each claim may
be described. Applicants can also signal which authority has registered
their claim by using normal contact objects to identify trademark
offices, company registers, and so on.

Here's a rough description of the model. I've included some example
request frames below. Comments appreciated.

The <create> element of the <extension> element:

      * MUST have an <applicationID>, assigned by the server when the
        application is created
      * MUST have 1 or more <status> codes from the set: [pending,
        validated, invalid, cancelled, allocated] (Q: possibly others?)
      * MUST have a <phase> from the set [SR, LR] (Q: should we let
        servers define further phases?)
      * 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
                              * identifies the name, address, contact
                                information of the issuing authority
                              * MAY be created by the client (ie open
                                approach) or the server (ie closed
                                approach), depending on server policy
              * if preVerified=0:
                      * MUST have at least one:
                              * <claimName> identifying the text string
                                in which the applicant has a claim,
                              * OR
                              * <claimNumber> identifying the registered
                                trade mark
                      * MAY have a <claimType> from the set [registered,
                        unregistered] ("unregistered" covers company
                        names and "common law" trademarks)
                      * MUST have a <claimCountry> from the ISO
                        3166-alpha2 set
                      * MAY have <claimRegion>. a <claimRegion> may
                        contain the name of a city, state, province or
                        other region in which the claim is valid
                      * MAY have an <issuer>. an <issuer>:
                              * identities a contact object in the
                                registry
                              * identifies the name, address, contact
                                information of the issuing authority
                              * MAY be created by the client (ie open
                                approach) or the server (ie closed
                                approach), depending on server policy
                              * MAY have a <claimEntitlement> from the
                                set [owner, successor, licensee] (Q: any
                                others?)

Example <domain:create> request with an application with pre-verified
claim:

	<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
		<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
			<!-- domain create stuff -->
		</domain:create>
		</create>
		<extension>
		<create xmlns="[whatever]">
			<phase>SR</phase>
			<claim preVerified="1">
				<pvrc>abc-12345</pvrc>
				<issuer>CLEARINGHOUSE-CONTACT-ID</issuer>
			</claim>
		</create>
		</extension>
		<clTRID>abc-12345</clTRID>
	</command>
	</epp>

Example <domain:create> request for a registered trademark with an
application with unverified claim:

	<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
		<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
			<!-- domain create stuff -->
		</domain:create>
		</create>
		<extension>
		<create xmlns="[whatever]">
			<phase>SR</phase>
			<claim preVerified="0">
				<claimName>Example Corp.</lp>
				<clamNumber>TM-1234321</claimNumber>
				<claimType>registered</claimType>
				<claimCountry>US</claimCountry>
				<issuer>USPTO-CONTACT-ID</issuer>
			</claim>
		</create>
		</extension>
		<clTRID>abc-12345</clTRID>
	</command>
	</epp>

Example <domain:create> request for a German company name with an
application with unverified claim:

	<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
		<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
			<!-- domain create stuff -->
		</domain:create>
		</create>
		<extension>
		<create xmlns="[whatever]">
			<phase>SR</phase>
			<claim preVerified="0">
				<claimName>Example GmbH.</lp>
				<claimType>unregistered</claimType>
				<claimCountry>DE</claimCountry>
				<claimRegion>Bayern</claimRegion>
				<issuer>MUNICH-COURT-CONTACT-ID</issuer>
			</claim>
		</create>
		</extension>
		<clTRID>abc-12345</clTRID>
	</command>
	</epp>

Example <domain:create> request for a British company name with an
application containing two different claims:

	<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<command>
		<create>
		<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
			<!-- domain create stuff --t>
		</domain:create>
		</create>
		<extension>
		<create xmlns="[whatever]">
			<phase>SR</phase>
			<claim preVerified="0">
				<claimName>Example Ltd.</lp>
				<claimType>unregistered</claimType>
				<claimCountry>UK</claimCountry>
				<issuer>COMPANIESHOUSE-CONTACT-ID</issuer>
			</claim>
			<claim preVerified="1">
				<claimName>Example</lp>
				<claimType>registered</claimType>
				<claimCountry>UK</claimCountry>
				<issuer>UKIPO-CONTACT-ID</issuer>
			</claim>
		</create>
		</extension>
		<clTRID>abc-12345</clTRID>
	</command>
	</epp>

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

---

From: Wil Tan <[email-masked]>
Date: Thu, 16 Jun 2011 23:45:58 +1000

Hi Gavin,

Thanks for taking the time to design this. Looks good in general. I really
like the choice of terms like "claims" Some nits / discussion points:

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

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

>                              * identities a contact object in the

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?

>                      * MUST have a <claimCountry> from the ISO

Shouldn't this be the "WIPO Standard ST.3" <
http://www.wipo.int/export/sites/www/standards/en/pdf/03-03-01.pdf> list?

>                              * identities a contact object in the

As above. IMHO an opaque identifier may be good enough here.

>                <domain:create
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>                <domain:create
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>                <domain:create
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>                <domain:create
> xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>

-- 
Wil Tan
CTO
Cloud Registry <http://www.cloudregistry.net>

---

From: Gavin Brown <[email-masked]>
Date: Thu, 16 Jun 2011 15:41:56 +0100

On Thu, 2011-06-16 at 23:45 +1000, Wil Tan wrote:
> 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.
 
> 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.

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

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