RE: EPP domain:transfer

You can easily define an authInfo extension and a domain <update>
extension to trigger the initial transfer request and token delivery to
the registrant.  That is, extend the <update> command to add features
(like maybe a new "transferRequested" status value) to support a token
delivery request.  Then the <transfer> is used as currently defined to
return the token in the <authInfo>.

Moving the transfer stuff out of the core is NOT a good idea.  It would
mean having to replicate all of the transfer stuff in the contact
mapping as well.

Contact me off-list if this isn't clear enough.  I can probably kludge
up some examples in a few minutes if that would help.

-Scott-

> -----Original Message-----
> From: Gerhard Winkler [mailto:[email protected]] 
> Sent: Wednesday, October 19, 2005 9:17 AM
> To: Hollenbeck, Scott; [email protected]
> Subject: EPP domain:transfer
> 
> 
> Hi Scott et al.,
> 
> in .AT we are currently discussing how different business 
> processes can
> be mapped on standard EPP. We didn't encounter many problems and
> most of our specialities can be solved with extensions.
> 
> One of the open things is the domain:transfer behavior. We 
> have a special
> process for this (see below) which cannot be mapped to the standard.
> 
> 
> For a domain transfer in .AT we need authorization of the registrant.
> Therefore we have designed a special process:
> - the registrar has to initiate a domain transfer
> - the registry sends a token to the registrant
> - the registrant has to forward this token to the registrar
> - the registrar has to send the token back to the registry in
>   combination with the domain transfer information
> 
> Due to this process we need two steps for the domain transfer
> (token request and transaction itself).
> 
> The token can be defined with EPP extensions easily. But we couldn't
> find a nice solution for the two step transfer.
> The problem is that transfer op-codes are defined in epp core
> (epp1.0) instead of domain-1.0.
> domain-1.0 doesn't know op-codes.
> 
> 
> epp-1.0 says:
>    <!--
>    The <transfer> command.  This is object-specific, and uses 
> attributes
>    to identify the requested operation.
>    -->
>      <complexType name="transferType">
>        <sequence> 
>          <any namespace="##other"/>
>        </sequence>
>        <attribute name="op" type="epp:transferOpType"
>         use="required"/>
>      </complexType>
>      
>   and:
>   
>      <simpleType name="transferOpType">
>        <restriction base="token">
>          <enumeration value="approve"/>
>          <enumeration value="cancel"/> 
>          <enumeration value="query"/>  
>          <enumeration value="reject"/>  
>          <enumeration value="request"/>  
>        </restriction> 
>      </simpleType>
>      
> 
> domain-1.0 says:
> 
>     <!--
>      Child elements of the <transfer> command.
>      -->
>        <complexType name="transferType">
>          <sequence> 
>            <element name="name" type="eppcom:labelType"/>
>            <element name="period" type="domain:periodType"
>             minOccurs="0"/>
>            <element name="authInfo" type="domain:authInfoType"
>             minOccurs="0"/>
>          </sequence>
>        </complexType>
>        
> 
> 
> Due to this fact its impossible to extend the transfer behavior to our
> needs. Trying to modify domain-1.0 only doesn't help very 
> much and even
> epp-1.0 cannot be left untouched.
> 
> 
> From our point of view there are two possible solutions for that:
> 
> The first one is to define a additional op-code "transfer op=init"
> within epp-1.0.
> This is not very nice because it doesn't solve the problem of 
> inflexibility
> of the transfer definition in epp-1.0.
> And - yes - it doesn't have very much to do with the transfer concept 
> mentioned in the RFC.
> 
> 
> The second solution would be the complete move of the 
> transfer definition
> to the domain-1.0 document.
> 
> something like this:
> 
>   <?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>
>         <domain:transfer op="request"
>          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>example.com</domain:name>
>    ...
> 
>  
> This approach would give much more flexibility for different 
> transfer scenarios, as they could be freely implemented within object
> namespaces.
> 
> 
> Are there any ideas how this transfer problem could be solved
> still using the EPP RFCs?
> 
> I wonder if there are other registries which encountered 
> problems due to the
> very hard definition of the transfer.
> 
> 
> 
> regards,
> Gerhard
> 
> 
> 
> -- 
> Gerhard Winkler                    |  E-Mail: 
> [email protected]
> Vienna University Computer Center  |
> Universitaetsstrasse 7             |  Tel: +43 1 4277 14035
> A-1010 Vienna, Austria             |  Fax: +43 1 4277 9140
> 
>