To:
"'janusz sienkiewicz'" <janusz@libertyrms.info>, Patrick <pat+ietf@patoche.org>
Cc:
ietf-provreg@cafax.se
From:
"Gould, James" <JGould@verisign.com>
Date:
Wed, 3 Dec 2003 15:31:07 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Janusz, The extension of the restore (I renamed it to be more generic) protocol extension would be similar to the extensibility built in the base EPP specification for command mappings, where the verbs (restore:request and restore:report) would be extensible by object specific tags. For example: 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: <restore xmlns:restore="urn:ietf:params:xml:ns:restore-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:restore-1.0 C: restore-1.0.xsd"> C: <restore:request> C: <domainres:request C: xmlns:domainres="urn:ietf:params:xml:ns:domainrestore-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domainrestore -1.0 C: domainrestore.xsd"> C: <domainres:name>example.com</domainres:name> C: <domainres:period unit="y">2</domainres:period> C: </domainres:domain> C: </restore:request> C: <restore:clTRID>ABC-12345</restore:clTRID> C: </restore> C: </extension> C:</epp> Both "urn:ietf:params:xml:ns:restore-1.0" and "urn:ietf:params:xml:ns: domainrestore-1.0" would be reported as a <svcExtension> in the <greeting> and the <login>. For example the greeting might look like the following: 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: <greeting> S: <svID>Example EPP server epp.example.com</svID> S: <svDate>2000-06-08T22:00:00.0Z</svDate> S: <svcMenu> S: <version>1.0</version> S: <lang>en</lang> S: <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI> S: <svcExtension> S: <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI> S: <extURI>urn:ietf:params:xml:ns:domainrestore-1.0</extURI> S: </svcExtension> S: </svcMenu> S: <dcp> S: <access><all/></access> S: <statement> S: <purpose><admin/><prov/></purpose> S: <recipient><ours/><public/></recipient> S: <retention><stated/></retention> S: </statement> S: </dcp> S: </greeting> S:</epp> This raises restore:request and restore:report to the same level as the core verbs. JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of janusz sienkiewicz Sent: Wednesday, December 03, 2003 1:41 PM To: Patrick Cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal Patrick, in your response you expressed strong support for protocol extension approach. As the chief reason for that you could imagine RGP syntax to be used for contacts or other objects. Since with protocol extension RGP request is not tied to a particular object mapping (domain or contact) how would use the syntax proposed by James? It is impossible without adding some real hacks into rgp syntax. Applying rgp syntax for other than domain objects actually strongly favors command response extension approach. Janusz Sienkiewicz