ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] Final List of EPP 1.0 and other Issues for Registry Consideration

  • To: <Registrars@xxxxxxxx>
  • Subject: [registrars] Final List of EPP 1.0 and other Issues for Registry Consideration
  • From: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Date: Fri, 5 Nov 2004 13:33:50 -0600
  • Importance: Normal
  • Sender: owner-registrars@xxxxxxxxxxxxxx

All,

Below is the final list of EPP 1.0 issues. Please review. We will be
attempting to arrange a call with the Registry Constituency to discuss.

1. The UTC time format must be the mandatory time format for all dates and
timestamps generated in and through the EPP System.

2. Use of unique client and server transaction ids must be possible.

3. The output for not owned objects must be restricted if the request is not
authenticated by the auth-info code. The data to be displayed without
authendification must still be determined but should include at least the
information that is publicly available through Registry Whois, less the
contact data. 

4. The same unified object status must be available to all objects across
all registries as per RFC 3731 section 2.3.

5. The ISO-3166/1 standard must be used to reflect countries in objects
where a country is used.

6. The registrar id of the registrar who initiated a transfer must be known
at time of the transfer per RFC 3730 section 2.9.2.4 and the RECOMMENDation
that only the gaining and losing registrar be allowed to make <transfer>
queries.

7. A change to the EPP <poll> command response calls for it to return the ID
of the *next message* on the queue instead of the ID of the message that is
being acknowledged. Regardless of the RFC spec this does not make any
practical sense. The <poll> response should continue to return the ID of the
message being acknowledged.

8. External Hosts are described in RFC 3731. Although not required by the
RFC, it would seem to make sense that a Registry provides a method of
notification of Host name changes so that a registrar may propagate that
change within its own system as well as with other registries that it may
have registered it as an External Host. It has been suggested that this
might be done through the <poll> command.

9. Registries should post a <poll> message not only when a transfer is
initiated but also when it is ACK'ed, NACK'ed or AutoACK'ed.  The current
.ORG Registry implementation (for example) is deficient in this regard. They
post a <poll> message for AutoACK'ed events, but not ACK'ed or NACK'ed.

These are additional issues that we would like to discuss with the
Registries on the call if there is time, or at least have them on the agenda
for the Cross Constituency meeting with them in Cape Town:

1. It would be very favorable for all Registrars if they would get two
sandboxes (to be able to test transfers internally) which are a 100%
equivalent to the real system with exception of the grace periods.

2. It should be possible to determine a Registrar inside all Registry
systems by its IANA id.

3. The maintenance notifications should be standardized

4. All relevant information about an object must be available through the
EPP system. Out of band communication like having to use whois to get
contact information should not be necessary.

Tim






<<< Chronological Index >>>    <<< Thread Index >>>