Patrick,
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 re-reviewing the options, I believe option 4 is the only option that is
protocol compliant and that would not result in a poison poll message. I
provide a response to your feedback embedded below prefixed with "JG-". 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. 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. The <msgQ><msg> element is defined as
mixed with a sequence of any elements that skip processing, which means that we
can mix XML with text without causing negative side effects on the client-side.
Any attributes for a non-supported service (object or extension) can be
retrieved from the server out-of-band using the message identifier (<msgQ> "id"
attribute). I propose supporting a list of <notSupported> XML elements
appended to the end of the <msgQ><msg> text. Each <notSupported> element
contains the XML namespace of the EPP service (object or extension) that is not
supported by the client. The ABNF for the <msgQ><msg> element is:
msg = msg-text *LWSP *(not-supported-service *LWSP)
msg-text = *VCHAR
not-supported-service = “<notSupported>” 1*VCHAR “</notSupported>”
The following is an example of a Change Poll Message where the client does not
support the Change Poll Extension:
<?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>
The following is an example of a Change Poll Message where the client does not
support the Domain Mapping and the Change Poll Extension to show the many case:
<?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:domain-1.0
</notSupported>
<notSupported>urn:ietf:params:xml:ns:changePoll-1.0
</notSupported>
</msg>
</msgQ>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
What do you think of this proposal?
—
JG
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 4/5/18, 3:12 AM, "regext on behalf of Patrick Mevzek"
<[email protected] on behalf of [email protected]> wrote:
On Wed, Jan 31, 2018, at 18:11, Gould, James wrote:
> Yes, there is no great solution to the problem of including extensions
> (object or command-response) in poll messages to clients that don’t
> support the extension as indicated by their login services. So, to
> clarifying for the list, there are 4 options that include:
I favor option 1 (return the extension independent of the login services)
from your list.
And now for my detailed rationale about that:
- the list of extensions at greeting/login time do not convey enough
semantics, like for example which extension is mandatory for login (especially
complicated when the registry offers at the same time multiple versions of the
same extension). The registry can only react by refusing the login, hopefully
with a good enough error message, but nothing is guaranteed here.
So for now, this kind of information is lost in documentation (James,
another useful data item to have in the Registry Mapping in fact).
- the registrar has to specifically acknowledge a message, after having
seen it; so the responsability is on him.
- poll results, aka notification messages are by definition not real time:
a registrar could as well download them all, store them locally in some way and
parse them later, including later when he has a software capable of
understanding them
- some registries let registrars choose, out-of-band, which kind of
notification messages they wish to receive; hence when this feature exists it
should again be the burden of the registrar to make sure it receives the
notification it needs to receive.
- giving the registrar all messages, irrespective of its choices at login
time, is also the case giving less work to the server.
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. The
XML schema validation can be disabled, but it really should not need to be
disabled if the server is protocol compliant. The Verisign EPP SDK is one
example of a validating client that would have an issue with the server
returning a poll message independent of the login service. I don’t view this
as a realistic option.
> 2. Return an Error (e.g., 2307 “Unimplemented object service”) to
> Poll Request for Unsupported Poll Message
This would be hugely detrimental for registrars because this would block
all of their queue for one message about something maybe that they explicitely
do not care about and have not implemented the relevant extension.
JG-I agree that this will result in blocking the queue, which I refer to as a
poison poll message. I don’t view this as a realistic option.
> 3. Return a Successful EPP Poll Response with an Extension Element
> that Indicates Lack of Client Support
If this means the original message is lost, I think it is a show stopper.
And if the registrar was not inclined to code a parser for some registry
notification that forces the registry to respond with this case, why should we
imagine that he would have coded the parser for this new extension also?
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.
> 4. Return a Successful EPP Poll Response with an Encoded <msgQ><msg>
> Element Indicating Lack of Client Support
Same remark. Also <msg> is defined as a human-readable element content,
hence
I do not think it is good to overload it with other data in it formatted
in some way. XML is a format, if you need to carry some formatted things it
should be using XML elements/attributes, and not be serialized in some way in a
string 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.
--
Patrick Mevzek
[email protected]
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
