From: Hollenbeck, S. <sho...@ve...> - 2001-10-25 16:12:12
|
> -----Original Message----- > From: Jae Gangemi [mailto:jga...@re...] > Sent: Thursday, October 25, 2001 12:04 PM > To: 'Daniel Manley'; we...@ar... > Cc: 'epp...@li...' > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > and 04 > > > > i'd like to ask why this change was made. > > i thought it was better for the registry to return a unique identifier for > the contact handles that way there could NEVER be any type of conflict > between registrars. Primarily because machine-generated identifiers aren't typically easily-remembered by the humans who need to use them. There is no problem of conflict between registrars because the registry enforces identifier uniqueness. It's also consistent with the way EPP is dealing with other objects such as domain and host names. Yes, it does mean that a <check> may be required to see if an identifier is in use before it can be created, but again, this is consistent with the way the protocol deals with other object identifiers -- which should make it a little easier to write consistent code. -Scott- |
From: Jae G. <jga...@re...> - 2001-10-25 16:31:12
|
> -----Original Message----- > From: Hollenbeck, Scott [mailto:sho...@ve...] > Sent: Thursday, October 25, 2001 12:05 PM > To: Jae Gangemi > Cc: 'epp...@li...' > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > and 04 > Primarily because machine-generated identifiers aren't typically > easily-remembered by the humans who need to use them. There > is no problem > of conflict between registrars because the registry enforces > identifier > uniqueness. It's also consistent with the way EPP is dealing > with other > objects such as domain and host names. Yes, it does mean > that a <check> may > be required to see if an identifier is in use before it can > be created, but > again, this is consistent with the way the protocol deals > with other object > identifiers -- which should make it a little easier to write > consistent > code. actually - i don't agree w/ the fact that it makes coding any easier. i now have to worry about the possibility that the contact that the contact handle i am creating already exists in the registry, and i then i have to build logic into my program to continue to generate a new handle until one is found that doesn't exist. i don't see how this method make remembering identifies any easier then dealing w/ ones that are machine generated. i would wager to say that a lookup would have to be done reguardless of the method used in order to find out the handle for a particular contact. also - if registars do use a database sequence w/ some form of identifier appended (which is the easiest way to generate a handle, and then we're back to the machine generated issue), it would be possible for malicious ppl to start creating handles that would force other registrars to spend a lot of time finding a contact handle that does not exist. having the registry decide this handle for you eliminates all the above issues. i would rather deal w/ having to do a lookup for some information then having to worry about logic to generate a unique handle and the possibility of malicious ppl. -jae |
From: alan <al...@pa...> - 2001-10-25 16:48:44
|
I think if you mentally replace "contact:id" with "username" and replace "authInfo" with "password" it starts to make a lot more sense (Think "OpenSRS" instead of "RRP"). I believe the idea is to push the responsibility of coming up with a globally unique contact ID onto the registrant, not onto the registrar. In that case, the registrar doesn't care at all what ID the registrant uses- they simply act as a proxy between the registrant and registry, for that particular bit of information. I'm still not sure this makes coding any easier, because having to use 2 different protocols with 2 different registries (make that: 4 different protocols with 4 different registries, if you count .com and .co.uk) is always more complicated and confusing than using one protocol on all registries. On another note: Is it just me, or is the information on how to use the EPP standards and toolkits in the context of a specific registry very vague? We haven't started using the EPP toolkits yet. We're a perl shop, so it's not clear that we're going to use them at all. But it seems like there's an awful lot of discussion on this mailing list regarding the uncertainties and difficulties of using EPP with a particular registry, even though EPP itself is very well defined. Alan On Thu, 25 Oct 2001, Jae Gangemi wrote: > > -----Original Message----- > > From: Hollenbeck, Scott [mailto:sho...@ve...] > > Sent: Thursday, October 25, 2001 12:05 PM > > To: Jae Gangemi > > Cc: 'epp...@li...' > > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > > and 04 > > > Primarily because machine-generated identifiers aren't typically > > easily-remembered by the humans who need to use them. There > > is no problem > > of conflict between registrars because the registry enforces > > identifier > > uniqueness. It's also consistent with the way EPP is dealing > > with other > > objects such as domain and host names. Yes, it does mean > > that a <check> may > > be required to see if an identifier is in use before it can > > be created, but > > again, this is consistent with the way the protocol deals > > with other object > > identifiers -- which should make it a little easier to write > > consistent > > code. > > actually - i don't agree w/ the fact that it makes coding any easier. i > now have to worry about the possibility that the contact that the contact > handle i am creating already exists in the registry, and i then i have to > build logic into my program to continue to generate a new handle until one > is found that doesn't exist. > > i don't see how this method make remembering identifies any easier then > dealing w/ ones that are machine generated. i would wager to say that a > lookup would have to be done reguardless of the method used in order to find > out the handle for a particular contact. > > also - if registars do use a database sequence w/ some form of identifier > appended (which is the easiest way to generate a handle, and then we're back > to the machine generated issue), it would be possible for malicious ppl to > start creating handles that would force other registrars to spend a lot of > time finding a contact handle that does not exist. > > having the registry decide this handle for you eliminates all the above > issues. i would rather deal w/ having to do a lookup for some information > then having to worry about logic to generate a unique handle and the > possibility of malicious ppl. > > -jae > > _______________________________________________ > Epp-rtk-devel mailing list > Epp...@li... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
From: John P. <jp...@bl...> - 2001-10-25 16:57:57
|
Hello Alan, The coding variations have really been an issue for me, our interfaces are all custom PERL apps, we do not use the C or Java tools. So detailed docs are a must and basically we deal with support on a per registrar basis and the lack of documentation really shows. John ======================================================================== At 09:48 AM 10/25/2001, you wrote: >I think if you mentally replace "contact:id" with "username" and >replace "authInfo" with "password" it starts to make a lot more sense >(Think "OpenSRS" instead of "RRP"). I believe the idea is to push the >responsibility of coming up with a globally unique contact ID onto the >registrant, not onto the registrar. In that case, the registrar >doesn't care at all what ID the registrant uses- they simply act as a >proxy between the registrant and registry, for that particular bit of >information. > >I'm still not sure this makes coding any easier, because having to use >2 different protocols with 2 different registries (make that: 4 >different protocols with 4 different registries, if you count .com and >.co.uk) is always more complicated and confusing than using one >protocol on all registries. > >On another note: > >Is it just me, or is the information on how to use the EPP standards >and toolkits in the context of a specific registry very vague? We >haven't started using the EPP toolkits yet. We're a perl shop, so >it's not clear that we're going to use them at all. But it seems like >there's an awful lot of discussion on this mailing list regarding the >uncertainties and difficulties of using EPP with a particular >registry, even though EPP itself is very well defined. > >Alan > > >On Thu, 25 Oct 2001, Jae Gangemi wrote: > > > > -----Original Message----- > > > From: Hollenbeck, Scott [mailto:sho...@ve...] > > > Sent: Thursday, October 25, 2001 12:05 PM > > > To: Jae Gangemi > > > Cc: 'epp...@li...' > > > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > > > and 04 > > > > > Primarily because machine-generated identifiers aren't typically > > > easily-remembered by the humans who need to use them. There > > > is no problem > > > of conflict between registrars because the registry enforces > > > identifier > > > uniqueness. It's also consistent with the way EPP is dealing > > > with other > > > objects such as domain and host names. Yes, it does mean > > > that a <check> may > > > be required to see if an identifier is in use before it can > > > be created, but > > > again, this is consistent with the way the protocol deals > > > with other object > > > identifiers -- which should make it a little easier to write > > > consistent > > > code. > > > > actually - i don't agree w/ the fact that it makes coding any easier. i > > now have to worry about the possibility that the contact that the contact > > handle i am creating already exists in the registry, and i then i have to > > build logic into my program to continue to generate a new handle until one > > is found that doesn't exist. > > > > i don't see how this method make remembering identifies any easier then > > dealing w/ ones that are machine generated. i would wager to say that a > > lookup would have to be done reguardless of the method used in order to find > > out the handle for a particular contact. > > > > also - if registars do use a database sequence w/ some form of identifier > > appended (which is the easiest way to generate a handle, and then we're back > > to the machine generated issue), it would be possible for malicious ppl to > > start creating handles that would force other registrars to spend a lot of > > time finding a contact handle that does not exist. > > > > having the registry decide this handle for you eliminates all the above > > issues. i would rather deal w/ having to do a lookup for some information > > then having to worry about logic to generate a unique handle and the > > possibility of malicious ppl. > > > > -jae > > > > _______________________________________________ > > Epp-rtk-devel mailing list > > Epp...@li... > > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > >_______________________________________________ >Epp-rtk-devel mailing list >Epp...@li... >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel |
From: alan <al...@pa...> - 2001-10-25 17:06:42
|
I hope not to veer too far off topic for this list, but I think the concerns I have may also be of interest to other list readers even if they're not strictly EPP-toolkit related. Does your perl code try to build an object model similar to the EPP toolkit Java object model, or are you just creating and interpreting XML on the fly with a less object-oriented interface? We do not yet provide .com or .co.uk registrar service yet, so we have an opportunity to attempt to unify the backend registry interface across all registry-registrar protocols, allowing us to create one front end interface for all registries. Have you (or anyone else) attempted to unify this API across all EPP and non-EPP protocols? If so, what huge brick walls did you run into in the process? (I'm hoping to learn of the pitfalls I've missed so far, so I can avoid them altogether.) As for "support on a per-registrar basis" do you mean customer support, or internal/reseller programming support? Thank you for your any feedback you can provide. Alan On Thu, 25 Oct 2001, John Palmer wrote: > Hello Alan, > > The coding variations have really been an issue for me, our interfaces > are all custom PERL apps, we do not use the C or Java tools. So detailed > docs are a must and basically we deal with support on a per registrar > basis and the lack of documentation really shows. > > John > ======================================================================== > > At 09:48 AM 10/25/2001, you wrote: > >I think if you mentally replace "contact:id" with "username" and > >replace "authInfo" with "password" it starts to make a lot more sense > >(Think "OpenSRS" instead of "RRP"). I believe the idea is to push the > >responsibility of coming up with a globally unique contact ID onto the > >registrant, not onto the registrar. In that case, the registrar > >doesn't care at all what ID the registrant uses- they simply act as a > >proxy between the registrant and registry, for that particular bit of > >information. > > > >I'm still not sure this makes coding any easier, because having to use > >2 different protocols with 2 different registries (make that: 4 > >different protocols with 4 different registries, if you count .com and > >.co.uk) is always more complicated and confusing than using one > >protocol on all registries. > > > >On another note: > > > >Is it just me, or is the information on how to use the EPP standards > >and toolkits in the context of a specific registry very vague? We > >haven't started using the EPP toolkits yet. We're a perl shop, so > >it's not clear that we're going to use them at all. But it seems like > >there's an awful lot of discussion on this mailing list regarding the > >uncertainties and difficulties of using EPP with a particular > >registry, even though EPP itself is very well defined. > > > >Alan > > > > > >On Thu, 25 Oct 2001, Jae Gangemi wrote: > > > > > > -----Original Message----- > > > > From: Hollenbeck, Scott [mailto:sho...@ve...] > > > > Sent: Thursday, October 25, 2001 12:05 PM > > > > To: Jae Gangemi > > > > Cc: 'epp...@li...' > > > > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > > > > and 04 > > > > > > > Primarily because machine-generated identifiers aren't typically > > > > easily-remembered by the humans who need to use them. There > > > > is no problem > > > > of conflict between registrars because the registry enforces > > > > identifier > > > > uniqueness. It's also consistent with the way EPP is dealing > > > > with other > > > > objects such as domain and host names. Yes, it does mean > > > > that a <check> may > > > > be required to see if an identifier is in use before it can > > > > be created, but > > > > again, this is consistent with the way the protocol deals > > > > with other object > > > > identifiers -- which should make it a little easier to write > > > > consistent > > > > code. > > > > > > actually - i don't agree w/ the fact that it makes coding any easier. i > > > now have to worry about the possibility that the contact that the contact > > > handle i am creating already exists in the registry, and i then i have to > > > build logic into my program to continue to generate a new handle until one > > > is found that doesn't exist. > > > > > > i don't see how this method make remembering identifies any easier then > > > dealing w/ ones that are machine generated. i would wager to say that a > > > lookup would have to be done reguardless of the method used in order to find > > > out the handle for a particular contact. > > > > > > also - if registars do use a database sequence w/ some form of identifier > > > appended (which is the easiest way to generate a handle, and then we're back > > > to the machine generated issue), it would be possible for malicious ppl to > > > start creating handles that would force other registrars to spend a lot of > > > time finding a contact handle that does not exist. > > > > > > having the registry decide this handle for you eliminates all the above > > > issues. i would rather deal w/ having to do a lookup for some information > > > then having to worry about logic to generate a unique handle and the > > > possibility of malicious ppl. > > > > > > -jae > > > > > > _______________________________________________ > > > Epp-rtk-devel mailing list > > > Epp...@li... > > > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > > > > >_______________________________________________ > >Epp-rtk-devel mailing list > >Epp...@li... > >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > _______________________________________________ > Epp-rtk-devel mailing list > Epp...@li... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
From: John P. <jp...@bl...> - 2001-10-25 17:50:17
|
Hey Alan, Our system is a somewhat unique implementation from what I have seen on this list. We run two sided connections server/client apps that communicate over TCP/IP so we can connect to our connections from various machines (only the main server is on the registries firewall) and the parent server app manages timeouts, logging, and a pre-connection test before sending actual epp commands and re-connect if necessary. The layout is very low level, I effectively bridged the traditional code gap between PERL variables and XML to allow what I consider to be very easy programming. In the end I end up with a hash of result values I can easily test against, for example, say I create a contact: # Note: @contactinfo is an array of contact info my ($result,$details) = INFO::create('contact',\@contactinfo); $result has the result code to easily test success $details has the ram server XML On a client code level I do not want to parse raw XML, but it is there just in case, for easy client level processing I "xparse" that code into an easy to use hash... $detailed = INFO::xparse($details); So now I have a simple hash full of easily accessible XML results, here is an example of what that hash would contain... $detailed->{contactroid} = C1367992-LRMS $detailed->{msg_langenUS} = Command completed successfully $detailed->{resultcode} = 1000 $detailed->{svTRID} = SRW-3981590 A more elaborate output is returned by the info command: $id = 'C1367992-LRMS'; my ($result,$details) = INFO::info('contact',$id); $detailed = INFO::xparse($details); and the hash here has: $detailed->{contactauthInfo_typepw} = ?????? $detailed->{contactcc} = US $detailed->{contactcity} = Anytown $detailed->{contactclID} = 5203-BH $detailed->{contactcrDate} = 2001-10-25 17:35:54.0 $detailed->{contactcrID} = 5203-BH $detailed->{contactemail} = su...@bl... $detailed->{contactfax} = +1.1231231235 $detailed->{contactname} = Joe Smith $detailed->{contactorg} = Joe Inc. $detailed->{contactpc} = 92211 $detailed->{contactroid} = C1367992-LRMS $detailed->{contactsp} = CA $detailed->{contactstreet} = 555 Main St, Suite 8 $detailed->{contactvoice} = +1.1231231234 $detailed->{msg_langenUS} = Command completed successfully $detailed->{resultcode} = 1000 $detailed->{status} = ok $detailed->{svTRID} = SRO-1004031517072 Note: The date is altered into a form I can use. From my client scripts the coding is almost identical, just change the package to use based on extension, so far I have: NSI:: INFO:: BIZ:: NU:: TV:: CC:: BZ:: I hope this is helpful. John ======================================================================== At 10:06 AM 10/25/2001, you wrote: >I hope not to veer too far off topic for this list, but I think the >concerns I have may also be of interest to other list readers even if >they're not strictly EPP-toolkit related. > >Does your perl code try to build an object model similar to the EPP >toolkit Java object model, or are you just creating and interpreting >XML on the fly with a less object-oriented interface? > >We do not yet provide .com or .co.uk registrar service yet, so we have >an opportunity to attempt to unify the backend registry interface >across all registry-registrar protocols, allowing us to create one >front end interface for all registries. Have you (or anyone else) >attempted to unify this API across all EPP and non-EPP protocols? If >so, what huge brick walls did you run into in the process? (I'm hoping >to learn of the pitfalls I've missed so far, so I can avoid them >altogether.) > >As for "support on a per-registrar basis" do you mean customer >support, or internal/reseller programming support? > >Thank you for your any feedback you can provide. > >Alan > > > >On Thu, 25 Oct 2001, John Palmer wrote: > > > Hello Alan, > > > > The coding variations have really been an issue for me, our interfaces > > are all custom PERL apps, we do not use the C or Java tools. So detailed > > docs are a must and basically we deal with support on a per registrar > > basis and the lack of documentation really shows. > > > > John > > ======================================================================== > > > > At 09:48 AM 10/25/2001, you wrote: > > >I think if you mentally replace "contact:id" with "username" and > > >replace "authInfo" with "password" it starts to make a lot more sense > > >(Think "OpenSRS" instead of "RRP"). I believe the idea is to push the > > >responsibility of coming up with a globally unique contact ID onto the > > >registrant, not onto the registrar. In that case, the registrar > > >doesn't care at all what ID the registrant uses- they simply act as a > > >proxy between the registrant and registry, for that particular bit of > > >information. > > > > > >I'm still not sure this makes coding any easier, because having to use > > >2 different protocols with 2 different registries (make that: 4 > > >different protocols with 4 different registries, if you count .com and > > >.co.uk) is always more complicated and confusing than using one > > >protocol on all registries. > > > > > >On another note: > > > > > >Is it just me, or is the information on how to use the EPP standards > > >and toolkits in the context of a specific registry very vague? We > > >haven't started using the EPP toolkits yet. We're a perl shop, so > > >it's not clear that we're going to use them at all. But it seems like > > >there's an awful lot of discussion on this mailing list regarding the > > >uncertainties and difficulties of using EPP with a particular > > >registry, even though EPP itself is very well defined. > > > > > >Alan > > > > > > > > >On Thu, 25 Oct 2001, Jae Gangemi wrote: > > > > > > > > -----Original Message----- > > > > > From: Hollenbeck, Scott [mailto:sho...@ve...] > > > > > Sent: Thursday, October 25, 2001 12:05 PM > > > > > To: Jae Gangemi > > > > > Cc: 'epp...@li...' > > > > > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > > > > > and 04 > > > > > > > > > Primarily because machine-generated identifiers aren't typically > > > > > easily-remembered by the humans who need to use them. There > > > > > is no problem > > > > > of conflict between registrars because the registry enforces > > > > > identifier > > > > > uniqueness. It's also consistent with the way EPP is dealing > > > > > with other > > > > > objects such as domain and host names. Yes, it does mean > > > > > that a <check> may > > > > > be required to see if an identifier is in use before it can > > > > > be created, but > > > > > again, this is consistent with the way the protocol deals > > > > > with other object > > > > > identifiers -- which should make it a little easier to write > > > > > consistent > > > > > code. > > > > > > > > actually - i don't agree w/ the fact that it makes coding any easier. i > > > > now have to worry about the possibility that the contact that the contact > > > > handle i am creating already exists in the registry, and i then i have to > > > > build logic into my program to continue to generate a new handle until one > > > > is found that doesn't exist. > > > > > > > > i don't see how this method make remembering identifies any easier then > > > > dealing w/ ones that are machine generated. i would wager to say that a > > > > lookup would have to be done reguardless of the method used in order to find > > > > out the handle for a particular contact. > > > > > > > > also - if registars do use a database sequence w/ some form of identifier > > > > appended (which is the easiest way to generate a handle, and then we're back > > > > to the machine generated issue), it would be possible for malicious ppl to > > > > start creating handles that would force other registrars to spend a lot of > > > > time finding a contact handle that does not exist. > > > > > > > > having the registry decide this handle for you eliminates all the above > > > > issues. i would rather deal w/ having to do a lookup for some information > > > > then having to worry about logic to generate a unique handle and the > > > > possibility of malicious ppl. > > > > > > > > -jae > > > > > > > > _______________________________________________ > > > > Epp-rtk-devel mailing list > > > > Epp...@li... > > > > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > > > > > > > > >_______________________________________________ > > >Epp-rtk-devel mailing list > > >Epp...@li... > > >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > > _______________________________________________ > > Epp-rtk-devel mailing list > > Epp...@li... > > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > |
From: alan <al...@pa...> - 2001-10-25 18:20:29
|
(Speaking of Perl, does anyone have any details on the Perl version of EPP-RTK that's referred to on the sourceforge site? Is it in the works, or just an idea at this point?) John, Thanks for the details! More comments are inline below... > Our system is a somewhat unique implementation from what I have seen > on this list. We run two sided connections server/client apps that > communicate over TCP/IP so we can connect to our connections from > various machines (only the main server is on the registries firewall) > and the parent server app manages timeouts, logging, and a pre-connection > test before sending actual epp commands and re-connect if necessary. This sounds like what we want to do: run one server which keeps a bunch of registry sessions open to each registry, and then have our web servers contact that one server instead of going directly to the registries. The info you gave below is definitely helpful. It mostly matches what we intend to do. We want to take it one step further, though, and unify the registry connection API that the web servers use, so they can talk to all registries in the same way, even if in the back end we're using different protocols. In our model, when we construct an object in our generic registry communication class, it determines which registry it needs to talk to based on the TLD we're dealing with, and returns an object of a derived class corresponding to the particular registry. The derived classes share the same API, so after construction the web interface makes registry calls in a standard way, without having to care about which registry it's connected to. Some methods will be undefined or implemented differently for certain registries- for example, all the contact methods for an RRP-based (or other thin) registry will store and query contact info locally since it's not stored at the registry. But as I said, I'm afraid of the brick walls we'll run into during the development process. I expect that unifying return values will be difficult to do in a general and useful way. As will differences like Nominet's "everything is done in email" model. Are you using any good XML parsing/creation modules? We haven't decided which of the many modules looks best, yet. It looks like you're flattening your XML into a hash. How do you handle elements which have attributes as well as values? Just create another hash key for each attribute? Thank you for your time, Alan > The layout is very low level, I effectively bridged the traditional code > gap between PERL variables and XML to allow what I consider to be very > easy programming. In the end I end up with a hash of result values I > can easily test against, for example, say I create a contact: > > # Note: @contactinfo is an array of contact info > > my ($result,$details) = INFO::create('contact',\@contactinfo); > > $result has the result code to easily test success > $details has the ram server XML > > On a client code level I do not want to parse raw XML, but it is there > just in case, for easy client level processing I "xparse" that code into > an easy to use hash... > > $detailed = INFO::xparse($details); > > So now I have a simple hash full of easily accessible XML results, here > is an example of what that hash would contain... > > $detailed->{contactroid} = C1367992-LRMS > $detailed->{msg_langenUS} = Command completed successfully > $detailed->{resultcode} = 1000 > $detailed->{svTRID} = SRW-3981590 > > A more elaborate output is returned by the info command: > > $id = 'C1367992-LRMS'; > my ($result,$details) = INFO::info('contact',$id); > $detailed = INFO::xparse($details); > > and the hash here has: > > $detailed->{contactauthInfo_typepw} = ?????? > $detailed->{contactcc} = US > $detailed->{contactcity} = Anytown > $detailed->{contactclID} = 5203-BH > $detailed->{contactcrDate} = 2001-10-25 17:35:54.0 > $detailed->{contactcrID} = 5203-BH > $detailed->{contactemail} = su...@bl... > $detailed->{contactfax} = +1.1231231235 > $detailed->{contactname} = Joe Smith > $detailed->{contactorg} = Joe Inc. > $detailed->{contactpc} = 92211 > $detailed->{contactroid} = C1367992-LRMS > $detailed->{contactsp} = CA > $detailed->{contactstreet} = 555 Main St, Suite 8 > $detailed->{contactvoice} = +1.1231231234 > $detailed->{msg_langenUS} = Command completed successfully > $detailed->{resultcode} = 1000 > $detailed->{status} = ok > $detailed->{svTRID} = SRO-1004031517072 > > Note: The date is altered into a form I can use. > > From my client scripts the coding is almost identical, just change > the package to use based on extension, so far I have: > > NSI:: > > INFO:: > BIZ:: > > NU:: > TV:: > CC:: > BZ:: > > I hope this is helpful. > > John > ======================================================================== > > > At 10:06 AM 10/25/2001, you wrote: > >I hope not to veer too far off topic for this list, but I think the > >concerns I have may also be of interest to other list readers even if > >they're not strictly EPP-toolkit related. > > > >Does your perl code try to build an object model similar to the EPP > >toolkit Java object model, or are you just creating and interpreting > >XML on the fly with a less object-oriented interface? > > > >We do not yet provide .com or .co.uk registrar service yet, so we have > >an opportunity to attempt to unify the backend registry interface > >across all registry-registrar protocols, allowing us to create one > >front end interface for all registries. Have you (or anyone else) > >attempted to unify this API across all EPP and non-EPP protocols? If > >so, what huge brick walls did you run into in the process? (I'm hoping > >to learn of the pitfalls I've missed so far, so I can avoid them > >altogether.) > > > >As for "support on a per-registrar basis" do you mean customer > >support, or internal/reseller programming support? > > > >Thank you for your any feedback you can provide. > > > >Alan > > > >On Thu, 25 Oct 2001, John Palmer wrote: > > > > > The coding variations have really been an issue for me, our interfaces > > > are all custom PERL apps, we do not use the C or Java tools. So detailed > > > docs are a must and basically we deal with support on a per registrar > > > basis and the lack of documentation really shows. > > > > > > John <snip> > > > >Is it just me, or is the information on how to use the EPP standards > > > >and toolkits in the context of a specific registry very vague? We > > > >haven't started using the EPP toolkits yet. We're a perl shop, so > > > >it's not clear that we're going to use them at all. But it seems like > > > >there's an awful lot of discussion on this mailing list regarding the > > > >uncertainties and difficulties of using EPP with a particular > > > >registry, even though EPP itself is very well defined. > > > > > > > >Alan |
From: Daniel M. <dm...@tu...> - 2001-10-25 18:37:27
|
alan wrote: >(Speaking of Perl, does anyone have any details on the Perl version of >EPP-RTK that's referred to on the sourceforge site? Is it in the >works, or just an idea at this point?) > It's currently in the "idea" stages. Tucows concentrated on the Java version. Global Name Registry (.name) is the keeper of the C++ version. Both of these are very similar because they were based on the EPP IDLs that were created (found in CVS epp-rtk/idl). We were hoping that developers in the community would be willing to contribute and maintain implementations of the IDLs in other languages (C, Perl, PHP, etc...). The idea was to make the RTK interface similar no matter which language you developed in. If you've got a Perl version you're working on and are thinking of submitting it, would you mind if either myself, wessorh or vhokstad took a look? Dan |
From: alan <al...@pa...> - 2001-10-25 18:51:38
|
> alan wrote: > > >(Speaking of Perl, does anyone have any details on the Perl version of > >EPP-RTK that's referred to on the sourceforge site? Is it in the > >works, or just an idea at this point?) > > It's currently in the "idea" stages. Tucows concentrated on the Java > version. Global Name Registry (.name) is the keeper of the C++ version. > Both of these are very similar because they were based on the EPP IDLs > that were created (found in CVS epp-rtk/idl). > > We were hoping that developers in the community would be willing to > contribute and maintain implementations of the IDLs in other languages > (C, Perl, PHP, etc...). The idea was to make the RTK interface similar > no matter which language you developed in. > > If you've got a Perl version you're working on and are thinking of > submitting it, would you mind if either myself, wessorh or vhokstad took > a look? We're currently in the tail end of the design phase, so there's not much to look at right now. Also, our goals are different than those of the EPP-RTK project, so our project may not be a good match for EPP-RTK. Our goal for registry communication is to create a set of perl modules which allow us to talk to EPP, RRP, and "other" registries with a unified OO API. We hope that eventually all registries will settle on one standard, so we can rip out everything else; but we aren't counting on this in the short term. With that in mind: We didn't intend to create a perfect match for the EPP IDLs. Instead, we want to create a general enough interface that it can be applied to all registry protocols equally (though implementation may be missing or different for certain registries). I imagine there are people who would certainly find this useful, but as I said, I'm not sure it matches with the EPP-RTK's needs. I'll take a look at the IDLs and see how close they come to what we had in mind. Alan |
From: Anthony E. <ae...@si...> - 2001-10-25 22:18:23
|
on 10/25/01 1:51 PM, alan at al...@pa... wrote: >> alan wrote: >> >>> (Speaking of Perl, does anyone have any details on the Perl version of >>> EPP-RTK that's referred to on the sourceforge site? Is it in the >>> works, or just an idea at this point?) >> >> It's currently in the "idea" stages. Tucows concentrated on the Java >> version. Global Name Registry (.name) is the keeper of the C++ version. >> Both of these are very similar because they were based on the EPP IDLs >> that were created (found in CVS epp-rtk/idl). >> >> We were hoping that developers in the community would be willing to >> contribute and maintain implementations of the IDLs in other languages >> (C, Perl, PHP, etc...). The idea was to make the RTK interface similar >> no matter which language you developed in. >> >> If you've got a Perl version you're working on and are thinking of >> submitting it, would you mind if either myself, wessorh or vhokstad took >> a look? > > We're currently in the tail end of the design phase, so there's not > much to look at right now. Also, our goals are different than those > of the EPP-RTK project, so our project may not be a good match for > EPP-RTK. > > Our goal for registry communication is to create a set of perl modules > which allow us to talk to EPP, RRP, and "other" registries with a > unified OO API. We hope that eventually all registries will settle on > one standard, so we can rip out everything else; but we aren't > counting on this in the short term. > > With that in mind: We didn't intend to create a perfect match for the > EPP IDLs. Instead, we want to create a general enough interface that > it can be applied to all registry protocols equally (though > implementation may be missing or different for certain registries). > > I imagine there are people who would certainly find this useful, but > as I said, I'm not sure it matches with the EPP-RTK's needs. I'll > take a look at the IDLs and see how close they come to what we had in > mind. > FWIW - I have already developed such an API but in Java. You can take a look at it at http://urc.sf.net/. The API is called Generic Registry Interface (GRI). The Universial Registry Client is a GUI client which uses the GRI. Questions and comments are welcome. Sincerely, Anthony Eden |
From: Rick H W. <we...@ar...> - 2001-10-25 22:23:51
|
Anthony, are there any docs, or should we just read the source, which by the way all the .tar.gz links on http://urc.sourceforge.net/ are borken. -rick On Thu, 25 Oct 2001, Anthony Eden wrote: > > FWIW - I have already developed such an API but in Java. You can take a > look at it at http://urc.sf.net/. The API is called Generic Registry > Interface (GRI). The Universial Registry Client is a GUI client which uses > the GRI. Questions and comments are welcome. > > Sincerely, > Anthony Eden > > > _______________________________________________ > Epp-rtk-devel mailing list > Epp...@li... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
From: Anthony E. <ae...@si...> - 2001-10-26 00:29:25
|
Read docs/index.html and then check out the JavaDoc documentation in docs/api. There are download problems from the page I listed. You can go to http://sourceforge.net/project/showfiles.php?group_id=37995&release_id=57528 to download. I have to admit though that a lot of this is thrown together. I just released the first release a week ago and then went on vacation. I will do more work on it next week when I get back from my vacation. Sincerely, Anthony Eden on 10/25/01 5:23 PM, Rick H Wesson at we...@ar... wrote: > > Anthony, > > are there any docs, or should we just read the source, which by the way > all the .tar.gz links on http://urc.sourceforge.net/ are borken. > > -rick > > On Thu, 25 Oct 2001, Anthony Eden wrote: > >> >> FWIW - I have already developed such an API but in Java. You can take a >> look at it at http://urc.sf.net/. The API is called Generic Registry >> Interface (GRI). The Universial Registry Client is a GUI client which uses >> the GRI. Questions and comments are welcome. >> >> Sincerely, >> Anthony Eden >> >> >> _______________________________________________ >> Epp-rtk-devel mailing list >> Epp...@li... >> https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel >> > |
From: Rick H W. <we...@ar...> - 2001-10-25 18:44:40
|
If anyone that needs access to epp functional registries over perl5 can contact Rick Wesson at Alice's Registry via ri...@ar.... we may be able to assist you with perl5/epp issues. -rick On Thu, 25 Oct 2001, alan wrote: > On another note: > > Is it just me, or is the information on how to use the EPP standards > and toolkits in the context of a specific registry very vague? We > haven't started using the EPP toolkits yet. We're a perl shop, so > it's not clear that we're going to use them at all. But it seems like > there's an awful lot of discussion on this mailing list regarding the > uncertainties and difficulties of using EPP with a particular > registry, even though EPP itself is very well defined. > > Alan > > > On Thu, 25 Oct 2001, Jae Gangemi wrote: > > > > -----Original Message----- > > > From: Hollenbeck, Scott [mailto:sho...@ve...] > > > Sent: Thursday, October 25, 2001 12:05 PM > > > To: Jae Gangemi > > > Cc: 'epp...@li...' > > > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > > > and 04 > > > > > Primarily because machine-generated identifiers aren't typically > > > easily-remembered by the humans who need to use them. There > > > is no problem > > > of conflict between registrars because the registry enforces > > > identifier > > > uniqueness. It's also consistent with the way EPP is dealing > > > with other > > > objects such as domain and host names. Yes, it does mean > > > that a <check> may > > > be required to see if an identifier is in use before it can > > > be created, but > > > again, this is consistent with the way the protocol deals > > > with other object > > > identifiers -- which should make it a little easier to write > > > consistent > > > code. > > > > actually - i don't agree w/ the fact that it makes coding any easier. i > > now have to worry about the possibility that the contact that the contact > > handle i am creating already exists in the registry, and i then i have to > > build logic into my program to continue to generate a new handle until one > > is found that doesn't exist. > > > > i don't see how this method make remembering identifies any easier then > > dealing w/ ones that are machine generated. i would wager to say that a > > lookup would have to be done reguardless of the method used in order to find > > out the handle for a particular contact. > > > > also - if registars do use a database sequence w/ some form of identifier > > appended (which is the easiest way to generate a handle, and then we're back > > to the machine generated issue), it would be possible for malicious ppl to > > start creating handles that would force other registrars to spend a lot of > > time finding a contact handle that does not exist. > > > > having the registry decide this handle for you eliminates all the above > > issues. i would rather deal w/ having to do a lookup for some information > > then having to worry about logic to generate a unique handle and the > > possibility of malicious ppl. > > > > -jae > > > > _______________________________________________ > > Epp-rtk-devel mailing list > > Epp...@li... > > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > _______________________________________________ > Epp-rtk-devel mailing list > Epp...@li... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
From: Hollenbeck, S. <sho...@ve...> - 2001-10-25 17:09:47
|
> -----Original Message----- > From: Jae Gangemi [mailto:jga...@re...] > Sent: Thursday, October 25, 2001 12:33 PM > To: 'Hollenbeck, Scott' > Cc: 'epp...@li...' > Subject: RE: [Epp-rtk-devel] more detailed differences between EPP 02 > and 04 > > > actually - i don't agree w/ the fact that it makes coding any easier. i > now have to worry about the possibility that the contact that the contact > handle i am creating already exists in the registry, and i then i have to > build logic into my program to continue to generate a new handle until one > is found that doesn't exist. No, you should expect the _registrant_ (or other contact) to provide the identifier that they'd like to use, just as the registrant should be giving you the domain and/or host names that they'd like to register. That's what I meant by "consistent". Logically, think of registering a contact in the same way you'd register a domain or host name. You wouldn't expect a domain name to be registered like this: Registrant: I'd like to register a .com domain name. Registrar/Registry: OK, your unique domain name is "dygwqdyt43.com". If you're not going to register domains that way, I don't believe it makes much sense to register contacts that way, either. -Scott- |