Re: <check> Response Attribute

[Daniel Manley <dmanley@tucows.com>]

Maybe this situation is what's causing a ruckus:

With Versign's com/net/org RRP registry, doing a check on "dan.ca" 
returns the message "Invalid Attribute Value".  So not only is it 
telling me that "dan.ca" is not available, but that the domain name is 
invalid.  EPP's <check> command can't do this because the command is 
designed in such a way to check more than one object at once and give 
+/- flags for each.  The response code reports the overall success of 
the command.  I would imagine that most EPP registries would say that a 
domain in the wrong TLD is not known to the registry (semantics of "not 
known" vs. "not available [from this registry]").

So in gaining the ability to check more than one object, EPP's <check> 
loses the ability to validate a domain name (or rather to report on 
validation of the name).

Yet another alternative:  Perhaps <check> should allow for an "op" like 
transfer.  Values could include "normal" (the default), "extended", 
"validate".  The extended and validate op's could be limited to one 
object per check command to minimize load of the extra work.  Extended 
check would return an additional "reason" attribute for objects known to 
the registry (we've already been over this discussion).  Validating 
checks would verify various things: TLD/SLD permission checks, etc...

Dan


Eva Stengård wrote:

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