Thomas, Unfortunately returning an error would not enable the client to consume the poll message, which would result in a poison poll message and a large client impact. Use of draft-ietf-regext-unhandled-namespaces within an error response for a poll message would break the processing of poll messages and would still not provide information that was provided by the client, since the poll message is supplied by the server. I don't believe blocking the poll queue with a poison message is a desired end state, since an unsupported message (e.g., change poll message) may not be of interest to the client but other supported messages like transfer poll messages are. The client can decide on the poll message of interest by supporting the extensions that they're interested in without blocking the poll queue and without the server breaking compliance with the RFC by blindly returning the poll message independent of the client login services.
As noted previously, when the <extValue> was defined in EPP RFC 5730, the description of the element never considered this use case. draft-ietf-regext-unhandled-namespaces defines a new usage of the <extValue> element, which is a form of extension and thus the reason why there is a namespace in the server greeting to indicate that the server supports it. As you indicate that there is no real technical impact to the client other than they may not be aware of the extra content in the poll message; although there is a predefined reason that the client can key off of defined within draft-ietf-regext-unhandled-namespaces. A compromise is to formally define the original intent of the <extValue> element, as defined in RFC 5730, and be explicit that draft-ietf-regext-unhandled-namespaces extends its usage to cover this use case within section 3 "Use of EPP <extValue> for Unhandled Namespace Data". To address the concern for the client potentially ignoring the content returned by the server per draft-ietf-regext-unhandled-namespaces, text could be added to recommend that the server monitor for the usage of draft-ietf-regext-unhandled-namespaces in both General EPP Responses and Poll Message EPP Responses to inform the client out-of-band of their lack of support for a particular extension. In addition, it could be recommended for the client to monitor for the usage of draft-ietf-regext-unhandled-namespaces to proactively identify extensions that they need to add support for. An Implementation Considerations section could be added for this. Thoughts to this compromise? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 10/26/20, 12:39 PM, "regext on behalf of Thomas Corte" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: Hello, On 10/26/20 15:01, James Galvin wrote: > Current consensus is to seek publication. However, we are a relatively > small group and we would like all comments considered by multiple > people. Would others please indicate their point of view in the active > thread between James and Patrick? As both an EPP client (and server) developer, I think that both James and Patrick make valid points, though I tend to agree more with Patrick's point of view. I'd fully agree with Patrick that the draft is somewhat abusing the <extValue> mechanism, as it was clearly designed in RFC 5730 to communicate "error diagnostic information", with the <value> containing a "client-provided element (including XML tag and value)". In fact, from this wording one could even derive that it's *not* proper server behavior at all to include anything in the <value> element that didn't also appear in the client's EPP command, which this draft is asking servers to do. One the other hand, I'd agree that it's probably the only place where non-parsed XML can be included in responses, which is the only way to keep the server's responses from violating the contract by including namespaces not listed as supported by the client. In our own current client implementation, we're only consulting the <extValue> content if the result code indicates an error. I'd assume that many clients do it this way, which is why I doubt that the inclusions defined by the draft will do any real harm or even cause confusion. However, at best this means that clients will completely ignore the unhandled data, i.e. simply ignore the (apparently empty) poll messages and acknowledge them without processing. While this is nice in terms of not blocking any other (understood) poll messages, it also poses the problem that important poll messages may go unnoticed, potentially for extended periods of time, which may (depending on the nature of the messages) be a greater operational risk than blocking further polling. If an unhandled namespace simply showed up (violating the contract), at least my validating EPP client would croak, and I'd be forced to take action (ideally by adding support for the namespace and resume polling then). I know it's late in the game to come up with suggestions, but anyhow: a compromise to solve this, at least for the polling issue, *could* be to use <extValue> as described, but to return an *error response* (with a special result code) instead of a success response to the <poll> command. This could (somewhat) justify the use of <extValue>, while still alerting the EPP client about something that it might be missing. Of course, this would still mean that polling of further messages would come to a halt until the issue is fixed on the client side. Best regards, Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: thomas.co...@knipp.de Software-Entwicklung E-Mail: thomas.co...@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1f0HYdHXFhIZdNtUuDPMth7JgdzR810M-AuwpsSOxavpswnXwC9uBX6r1GtF22pYXfEB0y1mxI9RZ3jf2OA9ozwodCluzWZ5AgWS6uqvsMLDFgkaDBf5I6HeYW5h3ZkkW_4u5oq_DMs0LNeq9Q0tPaXwrhDUjOcrm0mjqYSfxK52UH5o0vI6YorFS0ZmobmVj0CUyaJa0jbS3VsJ_s45PyGAQsrGfjxEgVXJ8temeReLsPKuDIwadLECZtkhIA4XxSxaNmggxeECgIz6jEmlvyKUOY4yDHqF3zQEgc5n4oq8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
