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
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
