Re: LP naming convention

Wil Tan <[email protected]> 2011-04-15 14:12
> James Gould had voiced out a valid point, i.e. the elements are named
> in a lowercase-with-underscores rather than camelCase. The latter is
> more consistent with the rest of EPP, so I propose updating it to the
> following on the next iteration of the draft:
> 
> application_id => applicationID
> trademark_name => trademarkName
> trademark_number => trademarkNumber
> trademark_locality => trademarkLocality
> trademark_entitlement => trademarkEntitlement
> pvrc => PVRC (or stay all lowercase, I'm ambivalent)
> 
> Any comments or objections?

I agree very much with this change, even if it does not change anything
technically I think it is better to stay in line with the other EPP
drafts, and I wanted to suggest this but feared to be too much a
nitpicker, so thanks James to have raised the point :-)

On a related note, for me the 4 trademark nodes are atomic, as
reprensenting a single "entity". So for me it would make even more
sens to have a <trademark> node with the name, number, locality and
entitlement being children of it. I think it makes things clearer (as
to see what is related to the trademark per se, and what is related to
the trademark use in a given registry startup phase), and easier to
expand if needed later on.


I have no direct experiences with trademark claring houses, but I
agree their input here would be very much valuable. Also seeing what
was done for ENUM as Bernie suggested could be useful.

As for the the draft, some quick comments:

- §2 : Maybe add a not that an applicationID is like a domain ROID,
  the registry should make sure it is a unique number, which is needed
later on (see §3.2 comment below)

- §2.1 : I think the element is always useful, and it should not be
  derived from the time or the applicationID encoding.
It can of course not be a MUST, but I would think having its presence
as a SHOULD would be best.

- §2.2 : for <lp:status> I would advise using a scheme similar to
  <domain:status> such as having the string as an attribute so that
the node data is optional but could be a text in human form with more
info.

In order not to repeat problems with have with EPP, the draft should
clearly specify if and how registry can use other statuses (than those
defined in the draft) if they
need. The schema should be in such a way that adding new statuses is
easy, and can be done without breaking everything.

Also, yes, I think we should allow multiple statuses at a time.


- §2.3 I think a date is missing, either (trademark) application date or
  granted date, or both.

- §3.2 when the registry does a lp:info, the applicationID should be
  enough, as soon as the registry makes it unique
(same trademark used in 2 phases would have 2 applicationIDs)

The lp:phase should of course be in the registry reply.

In the registry reply I believe it to be strange that all nodes are
optional, except the applicationID.
If an applicationID exists it means something has been submitted so
not all elements later can be optional, at least one or some must be
defined.

- §3.2.1 I fail to parse the first sentence :
«    The client MUST ensure that any successful <info> command results
in a response that an <lp:infData> element is returned in the
response. »

Maybe it is completely clear for English speaker, in which case, can
you make it just a little simpler to non native English speaker ?

- §3.3 we take the case that 1 applicationID = 1 domain name

Are there cases where we should or can consider 1 applicationID = more
than one domain names ?
(either because multiple domain names can be derived from the same
trademark depending for example on canonicalisation rules, or
because the trademark owner gives a list of domain names ordered from
most prefered to least prefered, in case its first choice is alreay
taken)

Same remarks as before on all elements being optional: I think at
least one or some may be needed.

I'm uneasy with the registry reply, specifically the domain:creDate
and domain:exDate and also the 1000 result code.

Since there is further processing, I think we should have a 1001, not
a 1000.
Also, since the domain name is not really registered, the dates will
be wrong.
I know that at least one of them is mandatory, but I think in this way
this create a problem. Registrars will need to adapt their system.


There should be also some text about the domain:period asked by the
registrar: in some launch phases, the registry may mandate the initial
registration period, so some text should make clear what happens when
the registrar asks for another period than the one allowed by the
registry (is the operation accepted or refused ?)


- §3.3.2 : same problem for first sentence as §3.2.1 above

- §3.4 : same comment as above, the applicationID is enough in my view

I also think that the update section should more concentrate on
updating the info related to the application instead of the domain
name.
During the launch phases typically domain names are not published, so
there is no sens changing their nameservers.
Also for the contacts/registrants there may be registry policies
forbidding change because, for example, the registrant may be the
trademark owner or something like that.

On the contrary one may need to change data about the application,
such as adding the application granted date if it happens after the
initial submission, or add a new preverification code.

- §3.5 : as above, isn't the applicationID enough ?


Hope that helps,

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