Ken,
I suggest you that send this message to the domain-policy@internic.net
mailing list. That is where they discuss issues like this.
By the way, this is not a new problem. It has always existed ever since
domain registrations started whay back when...
> -----Original Message-----
> From: Ken Alker
> Sent: Wednesday, January 26, 2000 4:34 PM
> To: dev-list@opensrs.org
> Cc: discuss-list@opensrs.org
> Subject: Fwd: the chicken or the egg
>
>
>
> >From: "Lars Hindsley" <info@spyproductions.com>
> >To: <dev-list@opensrs.net>
> >Subject: the chicken or the egg
> >Date: Wed, 26 Jan 2000 17:51:41 -0500
> >
> >We have a case here of what comes first...
> >
> >We have a form now incorporating all info including credit card info.
> >
> >We need to take into account that one of two things can fail.
> >
> >If you charge the card first and a domain fails, you have charged for a
> >domain they didn't get if you register the domain and the charge fails,
> >you are stuck paying for a domain you don't need.
> >Anybody know the solution? The fact is we already pace a user
> through the
> >whois.
> >It drops the domain into the form if it is available. Have we already
> >solved our problem?
> >
> >Best Regards,
> >Lars Hindsley | Project Leader
> > SpyProductions
>
> I believe you have solved your problem by checking whois first (1: check
> whois, 2: charge card, 3: register domain). The only drawback is that if
> the domain registered by someone else between the time you check
> whois and
> you submit the registration (which, granted, may only be a few seconds),
> you'll have to refund the customer. You'll also have to explain to the
> customer that their domain was taken only seconds before you were able to
> register it for them - a big problem from a customer service stand point.
>
> The only other solution would be to talk the Powers That Be into
> implementing a way to "hold" domains. Holding a domain for a
> minute or two
> would eliminate this problem.
>
> "Holding a domain" has another (very similar) benefit from a billing
> standpoint. [Below, assume an ISP is registering domains for its
> customers
> via opensrs]. If an ISP were allowed to "hold" a domain for say,
> a maximum
> of 24 hours, this would allow the ISP to lock the domain down before
> charging the card, then release the domain if the card doesn't go
> through. A 1-2 minute holding period would work just fine to eliminate
> your above issue in a fully automated environment. For an environment
> where an ISP wants to have a human check each registration before
> allowing
> it to go through, a 24 hour holding period would be more practical. In
> this way, the ISP has time to process a card or wait for a cash payment,
> review the format of the application, etc, but could HOLD the domain for
> their customer without the customer losing it. The ISP (via
> opensrs) would
> be responsible for releasing or verifying registration w/in the HOLD
> period. [This would obviously require a HOLD status to be maintained and
> acknowledged by all registrars including TuCows].
>
> With human processing and without a HOLD period, a customer can
> register a
> domain but the ISP can in not way guarantee that the customer
> will get the
> domain since anyone else could grab it before the ISP had time to check
> over the application, wait for payment, etc. (unless there is something I
> don't know about - and PLEASE correct me if I am wrong).
>
> My sysadmin argues that squatters may write a script that would keep
> domains on continuous HOLD. I feel that there must be some
> logical way to
> HOLD domains without the squatter problem. Does anyone have an
> answer to this?
>
>
>
> /************************************************************
> Ken Alker ken@impulse.net ham radio: KA6SDU
> Impulse Internet Services http://www.impulse.net
> Tri-County access: Santa Barbara, San Luis Obispo & Ventura
> Frame Relay / ADSL / ISDN / 56K / web hosting / co-location
> ************************************************************/
>
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:15 EDT