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

[Thomas Keller]

Tim,

that all looks very good lets move on with this list.

Best,

tom

Am 05.11.2004 schrieb Tim Ruiz:
> 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
> 
> 
> 
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w