Hello Martin, On 10/17/18 17:50, Martin Casanova wrote:
> I would like to comment 4 statements(analogous) that were made in this > session: Overall, I agree that all four statements are problematic at best (details inline below). > 1. To make sure the server remains RFC compliant when sending poll > messages with extensions it should not accept sessions where the client > did not specify all server supported extensions. (Server supported > language: ABC, Client only A and B) > - This is a rather strict interpretation. Of what I heard, some > registries allow the session anyway This is what we're doing in our TANGO system. In today's environment with thousands of TLDs, it's unrealistic to demand that every registrar keeps track of every single new extension (or version thereof) introduced by a registry, which they would have to do (just to enable their client to log in) if the above was implemented. > but use only extensions of the common > subset of client login and greeting in their reposes. Other extensions > are omitted in responses. Commands of other extensions that the server > does not support are answered with 2307 "Unimplemented object service" > but for that to happen the session must have been established. Who is > handling it this way, lets say for the DNSSec extension? In an ideal world, this would be the case across the board. TANGO does that for the supported fee extension (responses won't contain it unless the registrar specified in in the EPP login), but e.g. never omits DNSSEC data from <domain:info> responses, even if the registrar didn't announce support for it. > 2. Poll Messages are informational. Nothing important should be sent over > this channel. > - I think this could hinder the further development of all poll message > related extensions. The importance of the whole poll mechanism is > undermined by saying that the information in poll messages is anyway only > optional to process and not so "important". Maybe we will have even more > important stuff to communicate in the future via this channel. (low > balance etc.) Transfer-out messages are important; not only do they enable registrars to maintain a proper inventory, they also allow registrants to react in time should a domain be transferred away illegitimately. Transfer-in messages are maybe slightly less important, since a client can always check for the outcome of a transfer after a timeout, but this kind of busy waiting isn't exactly state-of-the-art. Since there is no other way in EPP to get that kind of information, poll messages are essential and hardly just informational. > 3. Poll messages could be purged if they were not delivered after a > certain time. While this could be seen as a solution for getting rid of unparseable messages left in the queue by the registrar (blocking the reception of others), I'm against the concept in general. The queue should always be emptied at the discretion of the registrar. > 4. The problem of breaking clients should never occur in production > because clients can prepare them selfs in OT&E Again, with thousands of TLDs, it's ridiculous to assume that registrars can constantly test and re-test their client systems in time for production updates in all cases. Extensions, especially non-mandatory ones, should therefore be rolled out in a fashion that ideally doesn't affect the functionality of legacy clients not seeking the use any of the new features, even if they don't retest in OT&E. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
