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

["Gould, James" <[e-mail]>]

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

[e-mail]



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" <[e-mail] on behalf of [e-mail]> 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

      [e-mail]



    _______________________________________________

    regext mailing list

    [e-mail]

    https://www.ietf.org/mailman/listinfo/regext