Hello, On 5/22/18 14:23, Gould, James wrote:
> Patrick, > > Referring to the language in the RFC is the starting point in the > discussion related to defining the problem that may or may not require a > solution. I disagree that we should look at the various implementation > policies implemented in the wild by registries and registrars to develop > the appropriate interpretation of the RFC. I see three options with the > interpretation of the RFC: > ... > 3. There is a problem and a common solution is required > 1. The RFC does not support servers returning services that the > client does not include in the login services and a common > solution is required. It’s pretty straight forward for the > server not to return an extension in the response to an object > command (e.g., domain create), so the real problem is associated > with the poll messages. > 2. With this option, we can start the discussion on defining a > common solution for the handling of poll messages that the client > does not support based on the login services. > > > > I believed I jumped to a proposal for a common solution without > determining whether the problem is important enough to address. I do not > agree with option 1 based on what is defined in RFC 5730, so it comes > down between option 2 and 3. I agree with option 3 only. Our registrar client systems use a validating parser for registry responses, and it's always a major pain to fix issues when unexpected XML namespaces start showing up. That being said, for some registries (such as Afilias) it seems to be a challenge to even produce schema-compliant server responses when it comes to the standard EPP RFC schemas. Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
