Patrick,
This may be an excellent topic for a working session at the next IETF. It would be great to hear opinions from others on this topic, since there is obviously a gap in the interpretation of the greeting and login services as it relates to responses (command responses and poll response) provided by the server. Your description still leaves out a case, that I cannot prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one. How can the client ack the message if it doesn’t at least parse it for the message id? An EPP client should frame the responses per RFC 5734 and will most likely parse the response to determine the result of the command and in the case of a poll message parse the message id to send the subsequent poll ack. The client could use regular expressions to extract the information or could do a validating DOM parse and object unmarshalling to have something easier to work with. There is no way for the server to know the capabilities of the client other than using the login services. Both sets of clients can be fully supported if the server honors the login services sent by the client. If the client wants to retrieve everything from the server for later processing, then the client can simply mirror the greeting services into the login services. Clients that do unmarshall responses, will most likely use marshalling factories that will be used to dynamically create the login services. This way the server will not send a response that the client does not support and will not break the client. As for "A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem. Just because servers have been sending unsolicited extensions to clients does not make it correct or appropriate from a protocol perspective. I believe we have examples of EPP extensions (RFC 5910 and draft-ietf-regext-epp-fees) that includes language related to what the server should or should not due based on the client login services, so this should be understood. I believe where it is not well understood is the handling of poll messages, which would be the point in creating a new draft. If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor) then what should the registry do? Send the secDNS part of the domain:info or not? I believe not sending it creates more harm than benefits, even if the registrar did not specify it at login, but clearly this is the core point of our disagreement. The registry should not return the secDNS extension in the domain info response for a client that does support secDNS-1.0 (RFC 4310) or secDNS-1.1 (RFC 5910) according to section 2 of RFC 5910 (https://tools.ietf.org/html/rfc5910#page-4). There is similar language in the Registry Fee Extension related to inclusion of the fee extension in the command response (e.g., “does include elements in the response, when the extension has been selected during a <login> command”). The login services explicitly provide the object and command / response extensions supported by the client along with their versions, so why would the server not honor those services to determine if and what version of an extension to return to a client? The exchange of the server services in the greeting and the client services in the login allow the client and server to negotiate what extensions are supported on both sides. Inclusion of an extension outside of the negotiated services should result with an error on the server side and the server should not return an unsupported extension back in a response. The server does not know the capabilities of the client, where sending an unsolicitated extension may result in a client-side failure in the case for a validating client or a client that unmarshalls the response. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/22/18, 3:27 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Fri, Apr 20, 2018, at 16:06, Gould, James wrote: > Thank you for the detailed description of your reasoning. I will leave > it that we disagree on the purpose of the login services, the need for > the server to honor the login services for poll messaging, and the > impacts in returning unsupported responses or response extensions to > clients. Ok. > On the impact, there are two elements to consider including > first the XML parser in validating a response against the XML schemas, > and second is the unmarshalling of the XML to a representative object. > A client could disable the XML parser validation and move along to the > unmarshalling step. In the unmarshalling step the client would need to > deal with receipt of unsupported content. The client could throw an > exception because the XML (e.g., DOM tree) could not be unmarshalled, > ignore the unsupported content, or come up with some other > representation of the unsupported content (e.g., convert to list of XML > blobs or DOM objects). A client would need to proactively deal with the > unexpected if the server does not honor the login services of the > client. Your description still leaves out a case, that I can not prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one. In this case, there are absolutely none of the problem you expose: the registry has no extra work to do, the registrar has no extra work to do to understand messages in unknown namespaces, registrar is not blocked at all for any new namespace introduced, the registrar has no problem if the registry message does not validate per its own XML schema, the registrar does not have to be proactive it can deal with new cases and problems later, etc. I really fail to see the drawbacks but of course anyone is free to do differently and stick to validate and parse everything in band in real time. As for "A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem. > Since this is not a problem unique to draft-ietf-regext-change-poll, I > agree that it's best suited to be addressed in a separate Internet Draft > that addresses service-aware EPP poll messaging. I agree this should be a separate draft, to become eventually an Informational Standard or a Best Practice depending on its content. > Is there interest in such a draft by the working group? I am interested by the subject but disagree on the offered solution. Also, it may be useful to be able (as difficult as it may be) to understand a little more on the current situation, and to see how registries currently handle this problem. Note that this happens very early and not only from poll messages. If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor) then what should the registry do? Send the secDNS part of the domain:info or not? I believe not sending it creates more harm than benefits, even if the registrar did not specify it at login, but clearly this is the core point of our disagreement. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
