Subject: [ietf-provreg] RE: EPP domain:transfer

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 19 Oct 2005 09:50:40 -0400

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-masked]] 
> Sent: Wednesday, October 19, 2005 9:17 AM
> To: Hollenbeck, Scott; [email-masked]
> 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-masked]
> Vienna University Computer Center  |
> Universitaetsstrasse 7             |  Tel: +43 1 4277 14035
> A-1010 Vienna, Austria             |  Fax: +43 1 4277 9140
> 
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 20 Oct 2005 10:05:53 -0400

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephane Bortzmeyer
> Sent: Thursday, October 20, 2005 8:46 AM
> To: [email-masked]
> Subject: [ietf-provreg] Re: EPP domain:transfer
> 
> On Wed, Oct 19, 2005 at 03:16:40PM +0200,
>  Gerhard Winkler <[email-masked]> wrote 
>  a message of 130 lines which said:
> 
> > Are there any ideas how this transfer problem could be solved still
> > using the EPP RFCs?
> 
> What's the purpose of this? Intellectual exercice? Standards are
> supposed to make life *simpler*. If you need a lot of work to fit your
> business rules into the standard, then it is not worth it.

As I said yesterday, one potential solution is quite easy to specify.

> EPP is a bad standard because it is not possible, giving the variety
> of registration rules, to have a standard which is both standard
> (meaning reuse of software) and sufficient.

Given that there is no standard set of registration rules, the first
part of the statement above is disingenuous at best.  The complete
problem is unsolvable by definition because there is no standard set of
registration rules; only parts of the problem can be solved.  What's bad
is asserting that solutions to smaller parts of the problem are
something more than they were designed to be.

-Scott-