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

[Patrick Mevzek <[e-mail]>]

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]