To:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Mon, 1 Dec 2003 07:43:43 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
[ietf-provreg] 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: 'ietf-provreg@cafax.se'; 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 > jgould@verisign.com > > > >