Patrick, I believe we're making the same points and again we can agree to disagree on the value and risk of draft-ietf-regext-unhandled-namespaces. I do need to clarify one thing, there was no specific changes needed on the client-side to support draft-ietf-regext-unhandled-namespaces other than ensuring that the draft-ietf-regext-unhandled-namespaces XML namespace is included in the login services. Inclusion of the draft-ietf-regext-unhandled-namespaces XML namespace in the login services is not required of the client, but does indicate to the server that the client does support monitoring the EPP poll messages and general EPP responses for unhandled namespaces. The other change that I implemented was to include tests that exercised the use cases outlined in draft-ietf-regext-unhandled-namespaces by explicitly removing XML namespaces from the login services and handling the lack of client support in the server for poll messages and general EPP responses. Clients should be capable of parsing and marshaling the <extValue> element regardless of whether or not draft-ietf-regext-unhandled-namespaces is supported.
The key change for the client is to recognize that support for a service is missing and to update the client to support it. The approach taken with draft-ietf-regext-unhandled-namespaces enables the information to be returned without the chance of breaking a validating client that doesn't support the service, ensures that a poison message doesn't stop the processing of the poll queue, and informs the client that they don't support a specified service. The extensibility of EPP provides the capability to address issues that were not foreseen at the time that the EPP RFCs were created, which is the case for draft-ietf-regext-unhandled-namespaces. -- 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/21/20, 5:26 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Wed, Oct 21, 2020, at 15:56, Gould, James wrote: > JG - I'm not clear of the risk of returning information in the > <extValue> element to clients. There won't be a schema validation > error like the case of returning a non-supported extension to a > validating client. There won't be a marshaling error for the client, > since unmarshaling the <extValue> in the <result> element should > already be supported. The most likely issue is that the client will > ignore the information, which does not pose an operational risk. That is purely a judgment call. The specifications say: this part is filled with content from client. This is clear and non-ambiguous. Hence a client parsing it is expecting to see there... data it already sent since it is the client, per the specification. You can say it is a bad client if it starts to misbehave because it sees other things there, but you can't also know or take into account all servers and clients out there, and their specificities. > I've > implemented draft-ietf-regext-unhandled-namespaces on the server side > and in a validating client within the Verisign EPP SDK, and I don't see > any potential risk for the client. Again, you take as granted that everyone will update their clients at the moment your specification becomes RFC (That won't happen as it doesn't happen for any RFC, no matter how good it is) or the fact that all clients work the same as yours. And for all clients not updated or doing things differently than yours, this draft may break them as soon as the EPP servers they connect to implement it. > Martin implemented > draft-ietf-regext-unhandled-namespaces in a Production server and > hasn't come across any reported client-side issues. A server can > choose to implement draft-ietf-regext-unhandled-namespaces and when > doing so should notify the clients ahead of time, so this is not > something that would be thrown onto clients without notice. Yes, in theory. In practice, deployments do not happen like that, unfortunately. I am just trying to give some data about past experiences. > A draft can be defined to > cover the usage of an existing element in the RFC for a specific > feature, No, you are explicitly redefining usage as described in RFC 5730. It looks minor in your eyes, not in mine, so our vision will remain separate. > JG - Yes for an error it makes sense to include the "client-provided > element". The case defined in draft-ietf-regext-unhandled-namespaces > is not an error and the use of the <extValue> element for this use case > is defined in draft-ietf-regext-unhandled-namespaces. ... and not defined in RFC 5730 which is the problem for every client out there that won't or can't or not yet upgrade to your specification. > The description > of the element does not prohibit the use of the element to address a > specific well-defined problem solved by > draft-ietf-regext-unhandled-namespaces. Yes, it does prohibit because it says "client provided" and you are putting things in it that are not "client provided". Your specification redefines core parts of the current EPP specification. And to be honest, one moment you say "RFC 5730 couldn't predict the need to handle undefined namespaces hence does not speak about them" (obviously) so that you can justify overriding one of its specification and here you say "RFC 5730 does not prohibit what this draft is trying to do (as if RFC 5730 could have known that in advance)". I believe this is one argument and its opposite so difficult to have both at the same time, but maybe I am just getting at my limits in English, which is very possible. > JG - We can agree to disagree on the value and risks associated with > draft-ietf-regext-unhandled-namespaces. The Document Shepherd can > include a reference to your disagreement in his writeup, but I don't > believe there is consensus to make a change. I am not saying otherwise and I sure don't expect a change because it is already presented as the best or unique solution on the problem, it has been discussed extensively and to me this specific solution creates its own set of problems, hence my disagreement. If I am the only one seeing that the text redefines RFC 5730 in different and incompatible ways, and the only one believing that not all clients will suddenly be upgraded to use this specification (as if all EPP servers out there will be updated...), then so be it, it does not really matter. Again, I am not trying to convince anyone, I know it won't happen, I just phrased my justifications on the problems I see. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1nXNUwUj1bmg9lEhAyYqquMiD-JFlTPDd1gC1zvdbtqA7FJHFLDnJ9Vv6gwNpNYReHy5QvN3lrHiuiayzO0XBgtuE0rL1wi4kX5tbIpHcD1zNczy78wF56_0w8HZfIlejuaTnlqPlKwGvQ5q607CwKUk9jK6EPwWMLJgrERkT6FjBogFZ7bfILKcy9cFMWX9dEMD9EupfFE8tDFRPBtmyK3MGa9sXTb7XxwHBf6eA8zyd_uqqlivqrUnaqQ2yyONk633DlGQPcMADuCofcYnJ7NYq5v6LiSjUBLtj3E8jYOg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
