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

[Rick Wesson]

Tim,

What of the privacy policy stuff, will any registry be implementing a 
privacy policy. How will registries use the
new privacy elements for the contacts?

Will privacy enforcement be just for the whois or will it also be 
implemented in the info and transfer commands?

thanks,

-rick



Tim Ruiz wrote:

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