Subject: [ietf-provreg] EPP domain:transfer

From: Gerhard Winkler <[email-masked]>
Date: Wed, 19 Oct 2005 15:16:40 +0200

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: Andrew Sullivan <[email-masked]>
Date: Wed, 19 Oct 2005 09:34:34 -0400

On Wed, Oct 19, 2005 at 03:16:40PM +0200, Gerhard Winkler wrote:

[. . .]
> find a nice solution for the two step transfer.

I think you ought to be able to do this.  As far as I know, all
ICANN-regulated registries do a two-step transfer.  When a transfer
request comes in, we return 1001 ("Command completed successfully;
action pending").  The transfer may be explicitly acknowledged with
an "op" attribute set to "approve" or "reject".  It seems to me that
what you need is an extension for the "approve" case, which can
contain the token from the registrant (that would prove that the
losing registrar has been contacted by the registrant, who has
approved the transfer).  Maybe I'm overlooking something in the rest
of your explanation?

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Gerhard Winkler <[email-masked]>
Date: Wed, 19 Oct 2005 16:57:13 +0200

> approved the transfer).  Maybe I'm overlooking something in the rest

For clarification (maybe I was too short in my explanation):
the token, generated by the registry, is sent to the registrant, and
for confirmation the registrant has to send the token to the
gaining registrar (who has initiated the transfer also).
The losing registrar doesn't play any role in our transfer process
(except of receiving notifications of course).

We have also considered to "misuse" the "approve", but from my
understanding it should be used by the losing registrar only.

I think a generic EPP client would run into some confusion, using the
"approve" in two different ways.

-Gerhard

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 Oct 2005 11:59:45 -0400

> (except of receiving notifications of course).

Ah, I did miss something, then, yes.

Well, you could do it a different way.  Scott's suggestion of using
an <update> command will work with the proposed updates to the
protocol; so that's one answer (it'd violate the current RFC, but
everyone seems to agree that the restrictions on objects in pending*
status are too tight, so Scott submitted some proposed changes).

A

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Oct 2005 14:46:20 +0200

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.

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Oct 2005 10:58:47 -0400

> business rules into the standard, then it is not worth it.

I don't see how the last sentence follows from the preceding one.
Standards are supposed to make _everyone's_ life (i.e. considered as
a complete set) simpler.  That might mean that some people's lives
actually get slightly harder.  That's part of the trade-off in
standards development, it seems to me.

> (meaning reuse of software) and sufficient.

A claim of impossibility is pretty strong.  It might be that people
don't think it's worth it; but I find it awful hard to believe that
it's impossible.  I know that Afilias has at least managed to
accommodate some variety of registration rules inside the standard.  

A

---

From: Patrycja Wegrzynowicz <[email-masked]>
Date: Thu, 20 Oct 2005 19:54:48 +0200

> (except of receiving notifications of course).

Hi Gerhard,

Scott's proposal sounds very fine for your case; although I'd like to 
put my 2 cents to your problem. ;)

1. Considering Scott's approach one MINOR note to mention:
<domain:update> command must be sent by the registrar which is
not the sponsoring client. It's only the minor note as according to EPP
standard the restriction of this action to the sponsoring client is only
recommended. However, worth to keep this in mind.

2. Your transfer process seems a lot like ours (.PL registry). .PL also
requires the registrant to confirm/authorize the transfer request.
Although the implementation is a bit different from yours proposal:
- the gaining registrar sends <domain:transfer> request
- the registry sends email with 'confirmation link' to the registrant
- the registrant clicks 'confirmation link' and then the transfer is done

As you see we decided to skip forwarding token forth-and-back in the
registry/registrar/registrant circle. From the semantic point of view
IMO it's more clear since such round-trip seems redundant. I see some
possible explanations of the 'token' approach... although it's more
question to you... what are your reasons behind having token approach
instead of, for example, direct confirmation?

Best,
Patrycja

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 20 Oct 2005 11:57:14 -0700 (PDT)

I haven't really participated here and mostly watched out what so far...
But it seems to me if some can not find the current standard acceptable
because of some of the built-in rules, perhaps the correct step is to 
reexamime and decide what are the most basic process for registration
common to all and move the rest othe current EPP that is TLD centric
into extensions (with capability to allow EPP server to advertise the 
extensions and sets of rules it supports and clienttelling what set of 
rules/extensions it would be using).

Just something to think about if you ever want to work on next version
of this protocol (which could be made quite compatible or very similar
for the current set of rules even if some of those would be extensions).

---

From: "Michael Young" <[email-masked]>
Date: Thu, 20 Oct 2005 15:50:04 -0400

>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.
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.

I guess I have a different view than this.

I would describe EPP as a decent attempt to provide some consistent behavior
for registry clients in the industry.

If it doesn't suit your purposes then you can certainly volunteer to improve
it.  The help would be appreciated.

Michael Young

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Oct 2005 10:11:50 +0200

On Thu, Oct 20, 2005 at 03:50:04PM -0400,
 Michael Young <[email-masked]> wrote 
 a message of 20 lines which said:

> If it doesn't suit your purposes then you can certainly volunteer to
> improve it.

I already said that it is not possible.

---

From: Eugenio Pinto <[email-masked]>
Date: Fri, 21 Oct 2005 12:26:35 +0100

> instead of, for example, direct confirmation?
Hi!

We, at the .PT Registry, are doing the same way as described in point 2.

It seemed to be the best aproach to us.

Best Regards,

Goncalves Pinto

---

From: Eugenio Pinto <[email-masked]>
Date: Fri, 21 Oct 2005 13:11:46 +0100

Hi all,

I would like you to consider doing a webpage for the ietfprovreg wg with 
the purpose of developing EPPv2

It would represent the EPPv2 working base and it would have someting like:

  - The entire list of TLD's with a description of the working done in 
EPP for each TLD, that could include:
       *if they are running EPP (or a test bed) or not
             If so what were the necessary extensions to the protocol 
(it could be a draft)
       *if they are intended to implement EPP or not
             If so what is the estimated time delay to do so
             If not, the reasons for that.
       *if they think implementing EPP in them Registry is impossible 
and why (it could be a draft)

             For those who think that it doesn't worth it, I only have a 
rhyme from a portuguese poet:

                "(...)Tudo vale a pena
                Quando a Alma não é pequena(...)"

             Which means all the effort worth it if you don't have a 
closed soul (something like that)

I think if we can do such a collection of information it would be much 
easier to accomplish all the extensions in the new version of EPP

And it could have another facility: to provide a base of knowing what's 
the perfect time to begin doing that effort of accomplishing all the 
extensions (it would be done only if there was a sufficient and relevant 
working base to do so)

Maybe a service like that could break the inertia that's present in a 
great number of the Registries..

Best Regards,

Goncalves Pinto

---

From: Gerhard Winkler <[email-masked]>
Date: Mon, 24 Oct 2005 10:41:01 +0200

>  > (except of receiving notifications of course).

Hi Patrycja!

> recommended. However, worth to keep this in mind.

That's the point where I feel uncomfortable.
It's not very nice to implement a policy checking module for access rights
where every business case is handled in one way except one single
transaction which is handled in another way.
But it's manageable to implement.

> - the registrant clicks 'confirmation link' and then the transfer is done

This is exactly what we are currently doing.

> instead of, for example, direct confirmation?

One advantage for the gaining registrar is to control the point in time
when the transfer is passed. The gaining registrar is able to initiate
other transactions without polling the registry for the current status
of the transfer immediately.

From the semantic point of view you can see it also the other way round.
The registrant gives authorization to the registrar for a transaction.
This can be embeded in a more complex process at the registrars side.

kind regards
-Gerhard