To:
"Gerhard Winkler" <gerhard.winkler@univie.ac.at>, <ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Wed, 19 Oct 2005 09:50:40 -0400
Content-class:
urn:content-classes:message
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
AcXUr3h2p1xtJocYQXKlSlIt9TFPQgAAWhsg
Thread-Topic:
EPP domain:transfer
Subject:
[ietf-provreg] 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:gerhard.winkler@univie.ac.at] > Sent: Wednesday, October 19, 2005 9:17 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > 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: > gerhard.winkler@univie.ac.at > Vienna University Computer Center | > Universitaetsstrasse 7 | Tel: +43 1 4277 14035 > A-1010 Vienna, Austria | Fax: +43 1 4277 9140 > >