I agree: move on, and make this discussion a new work item for the group. It was an interesting discussion by the way...
My opinion: First of all, I don't know about real world examples of issues concerning unsupported extensions by one of our registrars. When we introduce new extensions, or update existing ones, this is all communicated long in advance to all of our registrars so they can prepare the change. They have plenty of time to implement the extensions, and if they don't implement them, I guess they just ignore it (non-validating clients). There's no such thing as a client which all of a sudden must support or handle new extensions. Now to answer the questions: 1. Do you believe that it is protocol compliant for the server to return something that the client did not explicitly include in the login services? No. As Postel said: "be conservative in what you do". The client says it does not understand it, so be kind and don't return it. 2. The purpose of the server's greeting service and the client's login services: It's not a negotiate. It's informational, and in case of the login svcs it's a kind request to only "talk the languages" of the supported extensions. Should a server return an error when it receives a request containing extensions it does understand, but which are not mentioned by the client? No, even not for extensions it does not understand. 3. Validating clients: clients should be permissive in what they accept. A client must interpret the server's response as good as possible (i.e. ignoring XSD violations, use of non-supported schema's, ...). What about poll responses potentially containing extensions not supported by the client? Because of (3) that should not be a problem, but since in my opinion a server should be conservative (to be able to serve both validating and non-validating clients), it should send the response in another way. This is in my opinion a task for the working group. (Top of mind suggestion: encode part of the response which is not understood as a CDATA block) kind regards Pieter > On 04 May 2018, at 20:27, Roger D Carney <rcar...@godaddy.com> wrote: > > Good Afternoon, > > +1. > > We agree that that we should move forward with the current > draft-ietf-regext-change-poll draft and move this discussion along another > path. > > > Thanks > Roger > > > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James > Sent: Friday, May 04, 2018 9:16 AM > To: James Galvin <gal...@elistx.com> > Cc: Patrick Mevzek <p...@dotandco.com>; regext@ietf.org > Subject: Re: [regext] Poll messages with unhandled namespaces (was Re: I-D > Action: draft-ietf-regext-change-poll-07.txt) > > Jim, > > My recommendation is to move forward with draft-ietf-regext-change-poll and > to leave the EPP server sending unsupported responses (mapping extension and > / or command response extensions) to a client based on the login services up > to a separate draft. > > This comes down to the interpretation of how the server should handle the > login services of the client in creating responses. EPP extensions like the > DNSSEC extension (RFC 5910) leverages the login services in the migration > from RFC 4310 to RFC 5910, since the info response may include the DNSSEC > extension if there is DNSSEC data. The inclusion of the DNSSEC extension and > the version of the DNSSEC extension is based on the login services. Similar > functionality exists within draft-ietf-regext-epp-fees in determining if and > which version of the extension to return to the client. Poll messages are > unique since they are inserted ahead of time by the server without knowledge > of what the client does support, and therefore runs the risk of coming across > a message that the client does not support based on the login services. > Clients may or may not be able to handle the parsing and unmarshalling of > unsupported extensions sent by the server. For poll messaging this is of > particular interest, since a client may have an issue acknowledging the > unsupported poll messages to get to the rest of the messages in the queue. > This would represent a poison message in the poll queue. > > Based on the thread, there are separate thoughts related to whether it is > fine for the server to send a response that contains an extension that was > not included in the client’s login services. I believe that the greeting > services and the login services are used to negotiate the set of extensions > that client are server can use. What should the EPP server do with > unsupported extensions in any EPP response and with poll message EPP > responses in particular? This is a broader topic than > draft-ietf-regext-change-poll, so I recommend that we don’t attempt to solve > the problem specifically for draft-ietf-regext-change-poll but more > generically across all of the extensions in a separate draft. > > > — > > JG > > <image001.png> > > James Gould > Distinguished Engineer > jgo...@verisign.com <x-msg://4/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > From: James Galvin <gal...@elistx.com <mailto:gal...@elistx.com>> > Date: Friday, May 4, 2018 at 9:31 AM > To: James Gould <jgo...@verisign.com <mailto:jgo...@verisign.com>> > Cc: Patrick Mevzek <p...@dotandco.com <mailto:p...@dotandco.com>>, > "regext@ietf.org <mailto:regext@ietf.org>" <regext@ietf.org > <mailto:regext@ietf.org>> > Subject: [EXTERNAL] Re: [regext] Poll messages with unhandled namespaces (was > Re: I-D Action: draft-ietf-regext-change-poll-07.txt) > > The chairs would appreciate a suggestion from those in this discussion as to > what you would like to do next? <> > The change-poll document has been in WGLC that has now expired. However, you > have identified a technical issue but you have not been clear as to whether > you want a change in the existing document or you want a new work item for > the working group? > > What would you propose? What do others think? > > Antoin and Jim > > > > > On 23 Apr 2018, at 9:27, Gould, James wrote: > > 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 > <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 <mailto:jgo...@verisign.com> > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com <http://verisigninc.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 > <mailto:regext-boun...@ietf.org%20on%20behalf%20of%2...@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 <mailto:p...@dotandco.com> > > > _______________________________________________ > > regext mailing list > > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext> > > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > <https://www.ietf.org/mailman/listinfo/regext>_______________________________________________ > 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
