Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt

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

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

[e-mail]



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

      [e-mail]



    _______________________________________________

    regext mailing list

    [e-mail]

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