Subject: [provreg] Splitting the launch phase block in 2 parts

From: "Jan Jansen" <[email-masked]>
Date: Mon, 18 Apr 2011 21:17:21 +0200 (CEST)

Dear all,

Thank you for this extensive and detailed effort
to make the EPP scheme ready for 'sunrise'.
Trying to extend the EPP scheme to provide means to
incorporate validating services is a complicated matter.

We will have to distinguish  two different phases
1. Sending in info to show a certain right
2. Applying for an extension linked to the right

Actually these phases can be interchanged and often
a code is used to link the 2 different phases.

As examples :
.eu provided a code to a sunrise application that
could be used to send in documentary evidence
.co allowed to specify a code to register a name
in sunrise that was verified against a clearing house

If you want the EPP model to be extended to also
include the data to show a certain 'right' than
you will need a lot more than just a name, number
and country. (Such as type of right, if the right
has been given in concession, ...)
Despite me being around IP lawyers for quite some
time now, I always get the comment that I'm a
technical guy and see this things way to simple.

These are of course general remarks and I'm not
certain how to get them into an EPP schema. But
perhaps we should divide in an
<lp:right> section (denoting the right) and an
<lp:application> section (denoting the domain
name application).

The latter will be most easy to fill and could
(should?) contain : domain name, phase,
application id and/or pvrc.
The first (lp:right) is more difficult. It will
probably vary much from registry to registry.
It depends on which rights you will allow to
be applied for (eg: official TM, province/city/...,
local business and many others).

On a much lighter note I would like to change the
wording in the transition state from 'cancelled'
to 'rejected' since for me 'cancel' involves an
active action on the registrar side and this seems
to be a much more 'passive' state change from the
registrar view point.

Thank you all for putting your energy into this project.

Jan Jansen

---

From: Wil Tan <[email-masked]>
Date: Sun, 1 May 2011 03:45:10 +1000

Thanks for your comments, Jan.

> 2. Applying for an extension linked to the right
Agreed, and the LP extension is indeed meant to cover a stripped down
version of the latter i.e. simply "applying for a domain without the
guarantee that it will be allocated."

An implementation could then choose to either:
1. not accept any other field (as in the case of land rush type launch
scenarios)
2. accept only a pre-verified code (pvrc) where it is used by the registry
to validate against a third party (probably trademark clearing house) using
an out-of-band mechanism.
3. accept either the pre-verified code or the set of fields that the
applicant may use to claim the right to a mark.

> could be used to send in documentary evidence

This, as I understand, would mean that the "sending in documentary evidence"
step is out-of-band. In that case, this extension can be used as in #1
above.

> in sunrise that was verified against a clearing house
This is one of the primary use cases of the extension.

> technical guy and see this things way to simple.
This is where we really need the help of the trademark community i.e. people
like yourself and the IP lawyers you're referring to ;-)

Ideally, we'd define a set of elements to cover the majority of the use
cases and make them most/all optional, and let the implementation decide
what is required by policy.

> <lp:application> section (denoting the domain
I think grouping the trademark-related fields into a parent element was also
suggested by Patrick Mavzek. I agree it's more logical to group them
together. I'm not sure if there's much to be gained from having the
<lp:application> container though.

> local business and many others).
Indeed. It is a tricky balancing act to have something generic enough for a
wide spectrum of use cases and yet maintaining simplicity and providing
semantically correct fields.

> to be a much more 'passive' state change from the
This makes sense. Unless anyone objects, I will change it in the next
iteration of the draft.

.wil