RE: <check> Response Attribute

["Eva Stengård" <eva.stengard@nrm.se>]

Hi,
as I haven't been on this list that long and unfortunatly haven't had time to catch up
with all the backlog please forgive me if I revisit issues you already have covered
in length.

Following the discussion it seems to me that the interpretation of the <check>
command in many cases is "Can I register this object?". Though, reading the
draft-spec it seems to me that the <check> command just tells me if the object
exists in the repository or not (="Does this object exist?"). The result can only be 
yes or no in my opinion. However, this in itself is not enough if my purpose with 
the <check> have been to determine if I can create a domain object or make a 
transfer so I can understand the "maybe" suggestions.

Further down I'll list some additional information that I think could be provided 
in a <msg> element in case of <obj:name> as I believe that a certain number 
of standard respons messages can be useful even if the need for non-standardised
messages remains. 

First I'll give you some background. 

I'm writing this from the perspective of a sponsoring organization, in a sense 
"new kids on the block" but the construct itself already exists for some ccTLDs. 
Those of you that have been following the ICANN process may have noticed 
the following from the published parts of the agreements (.museum agreement 
the only complete so far):

- sponsoring organization is to be separated from registry operator,
- sponsoring organization is to accredit registrars (minimum number specified),
- sponsoring organization is responsible for upholding the policies for the domain (i.e. determining if the registrant may register in the TLD and if the proposed domain name conforms to present name rules),
- Public WHOIS has a new data element "ENS Identity", that's a handle from the sponsoring
organization, at least in the .museum case,
- In addition to UDRP a CEDRP, challenges to registrations in violation of charter, 
is introduced (during which registrar transfers are blocked for all names held by
challenged registrant). 

As I see it there are several consequences of this for an automated system involving 
sponsored TLDs (sTLDs), some of which may be subject to separate discussions, 
such as how to handle a possible three-party dialogue. Though many sTLDs may
be to small to justify implementation of an automated system such as EPP we should 
expect some to be large enough.

I'm making a number of assumptions as the basis for my proposals:
- a registry may operate more than one TLD (including mixtures of ccTLDs and gTLDs),
- there's not necessarily a strict implementation of "one server - one TLD",
- a registrar may be accredited to some but not all TLDs the registry operator 
handles in the system (<check> however is open to all authorized clients),
- some sponsoring organizations may permit tentative registrations pending
eligibility verification others may not do so,
- some (if not all) registries/ sponsoring organizations will require deposits from 
registrars or impose credit limits,
- some sponsoring organisations may limit the number of names per registrant,
- in some TLDs the registrant base may be divided in subgroups that are subject 
to different naming conventions,
- client equals to registrar,
- human errors occur.

If a <check> command looking like the exemple in the draft (epp-04, p.21) is sent the
response may IMHO include the following one or more <msg> element(s):

"Active"
"Reserved" [1]
"Defensive" [2]
"Pending ENS verification" [3]
"Pending Name verification" [4] 
"Pending UDRP resolution"
"Pending CEDRP resolution"
"Pending delete"
"Pending release"
"Name include reserved label"
"Name in violation of naming convention" [4]

as the client is known to the server the following information could also 
be provided if applicable

"Registrar not accredited for TLD"
"Registrar financial limit reached/exceeded"

If the <check> also includes an ENS identity element more information may 
be provided such as the following:

"ENS Identity don't exist" [5]
"ENS Identity not valid" [6]
"Registrant name limit reached/exceeded"
"Name in violation of naming convention" [4]

I realize that the listings above are incomplete and will be subject to
implementation decisions. The first decision is of course if such 
messages should be included at all in a <check> respons or if all
such responses should be sent when an transforming action is
taking place. Those of you operating registries should be able to
determine the load impact on the server, I can't. At some stage
the <info> command probably makes better sense to provide 
further information but can only be used if the initial <check> 
returned "+" as in "the object exists".

Notes:
[1] Reservation by ICANN or sponsoring organization.
[2] Defensive following IP claims or UDRP resolutions etc.
[3] Only if the sponsor allow tentative registrations of domain names prior to
elibility clearence.
[4] In many cases the proposed name itself isn't enough to determine 
compliance but may be resolved if the ID of the registrant is provided. 
Sometimes even this will not be enough, hence "Pending name verification".
A little less specific "Pending verification" for both ENS and name 
verification is also possible. 
[5] Human error or registrants trying to pull a fast one may result in this.
[6] In case the registrant have been challenged through CEDRP and lost the
right to register in the TLD or have failed to renew/ uphold the right in such 
cases the sponsor requires periodic eligibility checks.

All this said, it remains to be seen if the museum TLD will ever be part of an 
EPP environment.
I hope I'm not to far out on the limb with this.

/Eva

Eva Stengård
Project Associate
stengard@musedoma.org
MuseDoma
The Museum Domain Management Association

Please note that anything expressed here is the personal opinion of the 
writer and does not in any way represent an official statement or 
commitment from MuseDoma.