The problem is that it's now a manual effort for each domain. I setup the
admin contact correctly in the API, and OpenSRS ignores it and makes the
admin contact = registrant.
The response from OpenSRS has been: "You can login and change it". True,
but I don't want to do this for hundreds of domains. I could write yet
another OpenSRS BOT to do it, but I shouldn't have to.
Regards,
Doug
William X. Walsh writes:
> Hello Doug,
>
> Then if you have their permission, whats the problem?
>
> Set yourself as Admin contact. You create the username and
> password,make the necessary change.
>
> If they know enough to create the registration and username and
> password, they know enough to manage their own domain. If you did
> that for them, then what exactly is the problem?
>
> Sunday, June 17, 2001, 7:57:50 PM, Doug Sisk wrote:
>
> > "William X. Walsh" wrote:
> >>
> >> Hello Doug,
> >>
> >> Sunday, June 17, 2001, 1:41:38 AM, Doug Sisk wrote:
> >>
> >> > This is just an asinine policy!
> >>
> >> > All it does is create work for the RSP. It obviously wasn't originally
> >> > intended to work that way - why would you even define an admin contact
> >> > in the api if you were never going to allow RSP's to set it.
> >>
> >> The admin contact can be whomever the owner chooses.
>
> > Yes, and the owner has given me that authority. Why does OpenSRS make
> > it difficult fot me to assert that authority?
>
> >> However, that person has the authority to completely change, transfer
> >> ownership, cause a deletion, etc.
>
> > Yes. The point ?
>
> >> The role of the admin contact is effectively as the owner of the
> >> domain name. This is a historical role.
>
> > Effective is not the same as "is".
>
> >> I've said for years that any ISP who registers names for clients and
> >> puts themselves down as Admin contact is at a very minimum committing
> >> a very questionable act, and at worst an unethical one, bordering on
> >> illegal when they use their position as admin contact to prevent the
> >> registrant from making a change that they seek to the domain (Such as
> >> switching providers, changing the contacts, changing the nameservers).
>
> > Tucows should have a zero tolerence policy on illegal activities. If a
> > reseller holds a domain hostage then boot the reseller.
>
> >> If I had a $1 for every domain I've seen held hostage by an
> >> unscrupulous ISP or webhost who made themselves the admin contact for
> >> customer domains, either because they believed they had the right to
> >> because the customer owed them money (which they don't have the right
> >> to do), or for some other imagined reason.....
>
> > So it's ok for NSI, and Tucows to hold the domain hostage if it's not
> > renewed on time?
>
> >> I really see no reason why the registrant should not be listed as the
> >> admin contact 100% of the time. For their own protection. Managing a
> >> domain name, especially an OpenSRS registered domain, is simple
> >> enough.
>
> > It may be simple enough for you and me, but my clients barely know what
> > a computer is. They want a one stop shop. Trying to explain how
> > everything works to them is like explaining Calculus to my 5 year old.
>
> > Regards,
> > Doug
>
> >> On that note, one thing I've been thinking about is adding context
> >> sensitive help links to the various portions of the same OpenSRS
> >> client interface. (You know, the little "?" links that pop-up a help
> >> window)
> >>
> >> Anyone interested in helping to come up with the text for the various
> >> sections?
> >>
> >> --
> >> Best regards,
> >> William X Walsh <[EMAIL PROTECTED]>
> >> Userfriendly.com Domains
> >> The most advanced domain lookup tool on the net
> >> DNS Services from $1.65/mo
>
>
>
> --
> Best regards,
> William X Walsh <[EMAIL PROTECTED]>
> Userfriendly.com Domains
> The most advanced domain lookup tool on the net
> DNS Services from $1.65/mo
>
