Patrick,
This particular thread was started Martin Casanova, who brings up an excellent
point that needs to be considered. Martin, you may want to weigh on this.
I have the following questions and related thoughts:
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?
* I believe that the server should not return something that the client
does not include in the login services.
2. What is the purpose of the server’s greeting services and the client’s
login services?
* I believe that the server and client services are used to negotiate
the common set of supporting services. The client should not pass services
that the server does not support and vice-versa.
3. What do you do with validating clients?
* The Verisign EPP SDK is one implementation of a validating client, but
there can be others. A validating client would either need to be updated to
support the extension or turn off validation and be capable of processing a
message that it doesn’t support. If the protocol is followed, there should be
no issue with validating the XML per the supported XML schemas in either the
server or the client based on #2.
You are correct that there are a set of existing EPP extensions that do include
poll messages (e.g., RGP Poll Mapping, Low Balance Mapping, Launch Phase
Extension, and object mappings that support transfer poll messages like Email
Forwarding and Defensive Registration). This is based on the extensions
registered in the EPP Extension Registry
(https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml). With
the exception of the RGP Poll Mapping and the Low Balance Mapping, the poll
messages are associated with actions that the client previously took, so it’s
reasonable to assume that the client supports it. The Change Poll messages and
the Maintenance Notice poll messages (draft-sattler-epp-registry-maintenance)
are not associated with client actions, where there can be no assumption of
support. Based on past experience there have been no issues raised that I’m
aware in returning messages independent of what the client includes in the
login services, but I don’t believe we can blindly ignore the issue.
Since it looks like Patrick and I are most likely at an impasse, I ask the list
to weigh in on the two options that include:
1. Server does not consider the login services when returning poll messages.
Clients may be required to consume poll messages that they don’t support.
2. Server considers the login services and filters non-supported extensions
(object and command / response) from the poll message response with an encoded
<msgQ><msg> indicating the extension namepaces not supported. I include the
proposed ABNF for the <msgQ><msg> element below along with a sample of the
client’s lack of support of the Change Poll extension.
ABNF for the <msgQ><msg> element:
msg = msg-text *LWSP *(not-supported-service *LWSP)
msg-text = *VCHAR
not-supported-service = “<notSupported>” service-namespace “</notSupported>”
service-namespace = 1*VCHAR
Sample poll message of registry initiated domain update, where the client does
not support the Change Poll extension with the XML namespace
“urn:ietf:params:xml:ns:changePoll-1.0”:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1301">
<msg lang="en-US">
Command completed successfully; ack to dequeue</msg>
</result>
<msgQ id="202" count="1">
<qDate>2013-10-22T14:25:57.0Z</qDate>
<msg>Registry initiated update of domain.
<notSupported>urn:ietf:params:xml:ns:changePoll-1.0
</notSupported>
</msg>
</msgQ>
<resData>
<domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>domain.example</domain:name>
<domain:roid>EXAMPLE1-REP</domain:roid>
<domain:status s="serverUpdateProhibited"/>
<domain:status s="serverDeleteProhibited"/>
<domain:status s="serverTransferProhibited"/>
<domain:registrant>jd1234</domain:registrant>
<domain:contact type="admin">sh8013</domain:contact>
<domain:contact type="tech">sh8013</domain:contact>
<domain:clID>ClientX</domain:clID>
<domain:crID>ClientY</domain:crID>
<domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
<domain:upID>ClientZ</domain:upID>
<domain:upDate>2013-10-22T14:25:57.0Z</domain:upDate>
<domain:exDate>2014-04-03T22:00:00.0Z</domain:exDate>
</domain:infData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
Thanks,
—
JG
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 4/18/18, 2:19 AM, "regext on behalf of Patrick Mevzek"
<regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote:
On Mon, Apr 16, 2018, at 16:03, Gould, James wrote:
> Thanks for your thoughts of the 4 options presented for handling the
> returning of a poll message that the client does not support based on
> the client login services. To note, this is not specific to draft-ietf-
> regext-change-poll, so it is an important topic for defining a generic
> solution for all poll messages.
I agree, hence:
1) I change the subject
2) I am also wondering if we are not overdesigning something: obviously
this problem exists since the beginning of EPP and can only have grown much
worse with the additions of new registries, new registrars and new EPP
extensions... but as far as I know this subject has never been discussed
and no registrar came complaining about the issue
So, for this reason I am still inclined more toward "do nothing" and let
the registrars get all messages and deal with them.
> I re-reviewing the options, I believe
> option 4 is the only option that is protocol compliant
We will remain in disagreement.
> For option 4, I propose to
> define a simple <msgQ><msg> ABNF formatted message that indicates what
> poll message service namespaces (object or extension) are not supported
> are therefore not returned by the server.
I still stand the position that <msg> is defined for human consumption
and hence any "formatting" in it is at least violating the spirit of
the protocol. So I do not support that.
> A poll message may include
> multiple EPP services (object and extensions). It would be up to the
> server to filter the services not supported by the client and add the
> service namespace to the encoded <msgQ><msg> element.
So you are proposing that:
1) all registries change their software (filtering messages)
and
2) all registrars change their software, to parse the special format in
<msg>
I fear that this a lot of changes, and I am not really sure you can count
on them.
And starting with "registrar X did not implement parsing of messages in
namespace Y" you arrive to a solution that is "registrar X must parse specific
content inside <msg>".
If the registrar was not convinced to do the first point, I am not sure
it will get convinced to do the second one anyway. Hence I still think the
status quo is better and let the registries send all messages.
> JG-I don’t believe the server returning something that the client does
> support based on the login services as being protocol compliant. There
> is the issue of the message becoming a poison message for validating
> clients. The Verisign EPP SDK does support XML schema validation of the
> responses by default, where the server returning an XML namespace that
> is not configured on the client-side will result in an XML parser error
> and result in a poison poll message.
This is only one implementation possible.
Like I said previously, since these messages are by definition not realtime
I see no harms (and only benefits) for the registrar to get all messages,
store them, and parse them later. In that way there is no poison message,
and full dynamic support of all namespaces.
> The XML schema validation can be
> disabled, but it really should not need to be disabled if the server is
> protocol compliant.
Validating poll messages do not need to be done in real time inside the
transaction. It can be done asynchronously outside of it.
> JG-I agree that creating a new extension for this runs into the same
> issue of the client not supporting the new purpose built extension. I
> don’t view this as a realistic option.
You are creating a "mini" extension by embedding some format inside the
<msg> element.
> JG-I agree that this is not perfect, but it is the only option that is
> protocol compliant, that will not result in a poison poll message, and
> will enable the server to convey to the client the XML namespaces of the
> services (object and extensions) that they can request the attributes
> out-of-band using the message id.
I still think that sending all messages and letting the registrars validate
them out of the EPP session is the simpler solution.
Also, like I said, noone complained on all of this since EPP started, so
maybe affected registrars and registries should speak up...
--
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
