RE: 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
[email protected]


-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of janusz sienkiewicz
Sent: Wednesday, December 03, 2003 1:41 PM
To: Patrick
Cc: [email protected]
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