RE: [registrars] Discussion of EPP 1.0 Transition Issues

[Tim Ruiz <tim@xxxxxxxxxxx>]

<div>I'll kick off this discussion with my views.</div>
<div>&nbsp;</div>
<div>1.&nbsp;Agreed.</div>
<div>&nbsp;</div>
<div>2. Agreed.</div>
<div>&nbsp;</div>
<div>3. I don't necessarily agree. Right now, what is returned is
publically available through Whois. So I don't see the point in
restricting this. At the very least the create date, update date,
status, and registrar of record should remain available. Again, this is
publically available information. If&nbsp;a registrar&nbsp;is using the
DomainInfo command to mine data, removing the contact information
should help that. In any event, they will only move to mining Whois
data where tracking who is making the request will be more difficult,
especially if they are able to attack from multiple IP addresses.</div>
<div>&nbsp;</div>
<div>This information is used by some registrars to improve their customer
experience and confidence. For example, we use the status to determine
the transferability of a domain. We would prefer to let the customer
requesting the transfer know right up front that they cannot transfer
the domain in its current status and give some idea of what they may
need to do.</div>
<div>&nbsp;</div>
<div>4. I understand this to mean that the statuses and methodology of RFC
3731 section 2.3 must be implemented consistently by all registries. If
so, then I would agree.</div>
<div>&nbsp;</div>
<div>5. Agreed.</div>
<div>&nbsp;</div>
<div>6. If this is referring to the server response described in RFC 3730
section 2.9.2.4, I agree. If this is referring to the RECOMMENDation
that only the gaining and losing registrar be allowed to make
&lt;transfer&gt; queries, I would still agree.<BR><BR>7. I see little
if any benefit to knowing the ID of the next message on the queue.
Regardless of the RFC I would prefer that the &lt;poll&gt; response
continue to return the ID of the message being acknowledged.</div>
<div>&nbsp;</div>
<div>8. Agreed.</div>
<div>&nbsp;</div>
<div>Tim</div>
<div>&nbsp;</div>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT:
blue 2px solid"><BR>-------- Original Message --------<BR>Subject:
[registrars] Discussion of EPP 1.0 Transition Issues<BR>From: "Tim
Ruiz" &lt;tim@xxxxxxxxxxx&gt;<BR>Date: Tue, October 19, 2004 5:38
am<BR>To: Registrars@xxxxxxxx<BR><BR>All,<BR><BR>The following are
issues that apply specifically to the implementation<BR>of EPP 1.0.
There may be others that have been raised that I missed, so<BR>please
let me know. We should discuss these on the list and develop
a<BR>position on each sooner than later since the registries are
already in<BR>implementaiton mode. These positions could be presented
and discussed<BR>with the registries in Cape Town, but I would suggest
we request a<BR>conference call with the registries prior to Cape Town
if possible to<BR>present and discuss our positions.<BR><BR>1. The UTC
time format must be the mandatory time format for all dates<BR>and
timestamps generated in and through the EPP System.<BR><BR>2. Use of
unique client and server transaction ids must be possible.<BR><BR>3.
The output for not owned objects must be restricted if the request
is<BR>not authenticated by the auth-info code. The data to be
displayed<BR>without authendification must still be
determined.<BR><BR>4. The same unified object status must be available
to all objects<BR>across all registries.<BR><BR>5. The ISO-3166/1
standard must be used to reflect countries in objects<BR>where a
country is used.<BR><BR>6. The registrar id of the registrar who
initiated a transfer must be<BR>known at time of the
transfer.<BR><BR>7. A change to the EPP &lt;poll&gt; command response
calls for it to return<BR>the ID of the *next message* on the queue
instead of the ID of the<BR>message that is being acknowledged.
Regardless of the EPP 1.0 spec,<BR>does this really make any
sense?<BR><BR>8. External Hosts are described in RFC 3731. Although not
required by<BR>the RFC, it would seem to make sense that a Registry
provide a method<BR>of notification of Host name changes so that a
registrar may propagate<BR>that change within its own system as well as
with other registries that<BR>it may have registered it as an External
Host. It has been suggested<BR>that this might be done through the
&lt;poll&gt; command.<BR><BR>Tim </BLOCKQUOTE>