RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal

Jim and I had a long talk about his ideas before he sent them to the list.
I encouraged him to do so since I knew others were looking at ways to
implement RGP.

While I don't personally like the idea of adding new command verbs
(extending the protocol) for operations that seem (to me) similar to an
existing operation, I do think that Jim might be right about redemption not
really being an extension of renewal.  I'm thinking about the merits of
changing the extension from the <renew> command to the <update> command.
How would that sit with those of you who care about the RGP?

-Scott-

> -----Original Message-----
> From: Gould, James 
> Sent: Wednesday, November 26, 2003 3:46 PM
> To: '[email protected]'; Hollenbeck, Scott
> Subject: draft-hollenbeck-epp-rgp-01.txt comments/proposal
> 
> 
> Scott,
> 
> I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the 
> following comments:
> 
> 1. In the VNDS implementation, RGP does not have a renewal 
> feature, so if RGP was a Command-Response Extension, it would 
> be better suited for the domain:update command than the 
> domain:renew command.  
> 2. Since restore (request & report) functions more as a 
> Protocol Command than a Command-Response Extension, I believe 
> that it is better suited as a Protocol Extension.  The 
> namespace and XML schema could support both the restore 
> Protocol Extension and the Command-Response extension for the 
> domain:info response.
> 
> Based on the proposal of 2, the info response would include 
> the same extension as defined in draft-hollenbeck-epp-rgp-01.txt:
> 
>    S:    <extension>
>    S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    S:       rgp-1.0.xsd">
>    S:        <rgp:rgpStatus s="redemptionPeriod"/>
>    S:      </rgp:infData>
>    S:    </extension>
>  
> The restore extension would be moved up to a protocol 
> extension with some slight modifications:
> 
>    C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>    C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>    C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>    C:     epp-1.0.xsd">
>    C:  <extension>
>    C:     <rgp:restore xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    C:       rgp-1.0.xsd">
>    C:        <rgp:request/>  OR <rgp:report>...</rgp:report>
>    C:      </rgp:renew>
>    C:    <clTRID>ABC-12345</clTRID>
>    C:  </extension>
>    C:</epp>
> 
> The response would include no <resData> element.
> 
>   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   S:     epp-1.0.xsd">
>   S:  <response>
>   S:    <result code="1000">
>   S:      <msg>Command completed successfully</msg>
>   S:    </result>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp> 
> 
> By making the rgp:request and rgp:report protocol extensions, 
> there would be no coupling of either domain:update or 
> domain:renew behavior.
> 
> If anyone else is working on rgp, please respond with your 
> thoughts and comments.
> 
> Thanks,
> 
> 
> JG
> 
> James F. Gould
> VeriSign Naming and Directory Services
> [email protected]
> 
> 
> 
>