Subject: RE: [ietf-provreg] Implementation Report Findings

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 22 Aug 2006 07:06:06 -0400

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]] 
> Sent: Tuesday, August 22, 2006 4:50 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] Implementation Report Findings
> 
> although this feature is obviously not implemented anywhere, 
> I personally would 
> not remove it, simply because of the symmetry and the "E" in 
> EPP. Being 
> implemented somewhere is not a good indication of being worth 
> to be supported in 
> future versions of the protocol anyway. For example, the "ok" 
> status value is 
> likely implemented by all registries, but it is factually 
> completely useless, as 
> there would be no loss of information if it is simply omitted.

We don't have a choice, Klaus.  From section 4.1.2 of RFC 2026, second
paragraph:

"In cases in which one or more options or features have not been
demonstrated in at least two interoperable implementations, the
specification may advance to the Draft Standard level only if those
options or features are removed."

Others have confirmed that implementations exist.  Now we need the
"demonstrated" part.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 22 Aug 2006 13:53:01 -0400

Great -- thanks for confirming!

-Scott-

> From: Elias Sidenbladh [mailto:[email-masked]] 
> Sent: Tuesday, August 22, 2006 10:11 AM
> To: Hollenbeck, Scott
> Subject: RE: [ietf-provreg] Implementation Report Findings
> 
> I have now tested the Net::DRI domain_transfer_start function 
> against our EPP-Server and it worked fine.
> 
> Regards,
> Elias Sidenbladh
> --
> Internet Infrastructure Foundation (former NIC-SE)
> Tel:+46-8-4523536
> Mob:+46-734-315309
> Fax:+46-8-4523502
> Email:[email-masked] 
> 
> Hollenbeck, Scott wrote:
> > > From: Elias Sidenbladh [mailto:[email-masked]]
> > > Sent: Tuesday, August 22, 2006 7:18 AM
> > > To: Hollenbeck, Scott; Asbjorn S. Mikkelsen; [email-masked]
> > > Subject: RE: [ietf-provreg] Implementation Report Findings
> > > 
> > > Our inhouse registrar (not in production yet) uses 
> > Net::DRI, we have 
> > > also automated the tests of the EPP-server using 
> Net::EPP::Client. 
> > > Don't know if that counts...
> > 
> > It could, as long as the two implementations were developed 
> > independently.  Can you confirm that this specific feature 
> > was tested successfully, Elias?
> > 
> > -Scott-
> > 
> 
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 22 Aug 2006 13:52:34 -0400

Excellent -- thanks for confirming!

-Scott-

> From: Asbjorn S. Mikkelsen [mailto:[email-masked]] 
> Sent: Tuesday, August 22, 2006 10:09 AM
> To: Hollenbeck, Scott
> Scott,
> Using a slightly modified version of the code from the c++ version of
> the SourceForge epp-rtk project against the .name OT&E:
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>      epp-1.0.xsd">
>   <command>
>     <transfer op="request">
>       <domain:transfer
>            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
>            xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
>            domain-1.0.xsd">
>         <domain:name>asm.name</domain:name>
>         <domain:authInfo>
>           <domain:pw roid="1529404CONTACT-NAME">as8n59f</domain:pw>
>         </domain:authInfo>
>       </domain:transfer>
>     </transfer>
>     <clTRID>ABC-12345</clTRID>
>   </command>
> </epp>
> 
> Where "as8n59f" is the password for the contact object, not the domain
> object.
> 
> Returned:
> 
> <?xml version="1.0"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>      epp-1.0.xsd">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <domain:trnData
>            xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
>            xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
>            domain-1.0.xsd">
>         <domain:name>ASM.NAME</domain:name>
>         <domain:trStatus>pending</domain:trStatus>
>         <domain:reID>XXXXXXX1</domain:reID>
>         <domain:reDate>2006-08-22T13:53:21.0000Z</domain:reDate>
>         <domain:acID>XXXXXXX2</domain:acID>
>         <domain:acDate>2006-08-27T13:53:21.0210Z</domain:acDate>
>         <domain:exDate>2007-02-11T12:07:44.0000Z</domain:exDate>
>       </domain:trnData>
>     </resData>
>     <trID>
>       <clTRID>ABC-12345</clTRID>
>       <svTRID>3196766-1156254801065</svTRID>
>     </trID>
>   </response>
> </epp>
> 
> 
> Please let me know if this is sufficient. If not, I can liaise with
> Patrick to test the same with his client against the .name production
> system.
> 
> 
> Cheers,
> 
> Asbjorn
> 
> 
> On Tue, 2006-08-22 at 08:23 -0400, James Gould wrote:
> > Scott,
> > 
> > The VeriSign EPP SDK supports passing of the roid with 
> transfer requests
> > which was used for testing the feature against the NAME Registry.
> 
> 
> -- 
> Asbjorn Steira Mikkelsen <[email-masked]>
> CTO
> The Global Name Registry, Limited
> _____________________________________________________
> 
> Information contained herein is Global Name Registry Proprietary
> Information and/or Registry Sensitive Information and is made 
> available
> to you because of your interest in or affiliation with our 
> company. This
> information is submitted in confidence and its disclosure to 
> you is not
> intended to constitute public disclosure or authorization for 
> disclosure
> to other parties. Should you have received this email and are not an
> intended recipient, please delete this email in its entirety. Global
> Name Registry is registered with the Office of the UK Information
> Commissioner.
> 
> 
>