<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] Final List of EPP 1.0 and other Issues for Registry Consideration
- To: Tim Ruiz <tim@xxxxxxxxxxx>
- Subject: Re: [registrars] Final List of EPP 1.0 and other Issues for Registry Consideration
- From: Thomas Keller <tom@xxxxxxxxxx>
- Date: Mon, 8 Nov 2004 09:44:52 +0100
- Cc: Registrars@xxxxxxxx
- In-reply-to: <025801c4c36e$60ccf440$102c12ac@jomax.paholdings.com>
- Organization: Schlund + Partner AG
- References: <025801c4c36e$60ccf440$102c12ac@jomax.paholdings.com>
- Sender: owner-registrars@xxxxxxxxxxxxxx
- User-agent: Mutt/1.5.5.1i
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|