Re: Launch: availability and claims information

Depending on the backend architecture, it's possible that separating the
two will also put less load on the registry. I could imagine that a
registrar would perform availability checks for lots domains, but only do
claims check on a subset that the registrant expresses interest in.

Though I'll admit that should not be the primary consideration here.


On Thu, Apr 11, 2013 at 9:44 AM, Gould, James <[email protected]> wrote:

>   James,
>
>  I don't agree that the availability check and the claims check should be
> combined.  They have two separate purposes and therefore are handled via
> different verbs (check and claims check).  We discussed the separation of
> the two for a while in the Community Model, so I don't believe that we
> should consider attempting to combine them at this point.
>
>   -- ****
>
>
>
> JG****
>
>  ****
>
> ****
>
>  ****
>
> James Gould****
>
> Principal Software Engineer****
>
> [email protected]****
>
>  ****
>
> 703-948-3271 (Office)****
>
> 12061 Bluemont Way****
>
> Reston, VA 20190****
>
> VerisignInc.com
>
>   From: James Mitchell <[email protected]>
> Date: Tuesday, April 9, 2013 11:16 AM
> To: EPP Provreg <[email protected]>
> Subject: [provreg] Launch: availability and claims information
>
>   Jim et al,
>
>  It is my opinion that claims and name availability information should be
> available in one command/response. Registrars may want to know claims
> information at the time of availability (register a new domain search page)
> to 1) indicate a different price if claims is present or 2) indicate the
> name is subject to claims acknowledgement/extra processing, or 3) withhold
> the name from their name spinner because they have chosen not support
> claims.
>
>  I suggest the claims check command be extended to include an
> "standalone" attribute with boolean value true indicating availability
> information is not required, and false indicating that availability
> information is desired in addition to claims. Servers may choose to support
> only standalone=true, servers that support standalone=false must support
> standalone=true. I'm not too keen on the "standalone" name, so please make
> other suggestions.
>
>  I can contribute text if required.
>
>  Regards,
> James
>
>
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>
>

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