Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

["James Galvin" <[e-mail]>]

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).  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
>
> [e-mail]
>
>
>
> 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" 
> <[e-mail] on behalf of [e-mail]> 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
>
>       [e-mail]
>
>
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext


> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext