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

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

Martin,

Yes, that is an excellent point that we need to consider for any poll message extension.  What should the server do with a poll message that the client does not support based on the login services?  We need to consider two poll extension cases:


  1.  Object Extension – This is the case for an extension like the Registry Maintenance Notifications for EPP (https://tools.ietf.org/html/draft-sattler-epp-registry-maintenance) that is being discussed on rr_ry_techops list.
  2.  Command Response Extension – This is the case for the Change Poll extension, where it extends the info response of EPP objects (domain, host, contact, …).

To be protocol compliant the server must not return an extension (Object or Command Response) that is not supported by the client based on the login services.  I really only see one solution that would apply to both types of extensions, which would be to return a successful EPP Poll Response with an appropriate message indicating the poll message namespaces that are not supported by the client logic services.  The client could add support for the poll messsage or choose to ack it to move to the next message in the queue.  The only element in the EPP response that we can use is the <msgQ> <msg> element.  You could leverage the <result><msg> as well, but I don’t believe that would help here.  I don’t advocate encoding something in the <msg> element, which is the point I made about including JSON in the <msg> element for the Registry Maintenance Notifications for EPP.  In this case, I don’t believe there is much of a choice to stay protocol compliant and to ensure that the poll queue can continue to be processed.  How about encoding the <msg> element as below when the server needs to return a poll message to a client that doesn’t support one or more extensions based on their login services?

msg = extension-namespaces “ not supported in login services”
extension-namespaces = extension-namespace / extension-namespace “,” extension-namespaces
extension-namespace = XML namespace of EPP extension


An example of a Change Poll <msg> element of a supported object (e.g., domain) is “urn:ietf:params:xml:ns:changePoll-1.0 not supported in login services”.  An example of a Change Poll <msg> element of an unsupported object (e.g., .NAME Email Forwarding object) is “http://www.nic.name/epp/emailFwd-1.0,urn:ietf:params:xml:ns:changePoll-1.0 not supported in login services”.  The full EPP response for the first Change Poll <msg> element is included below:





S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>

S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">

S:  <response>

S:    <result code="1301">

S:      <msg>Command completed successfully; ack to dequeue</msg>

S:    </result>

S:    <msgQ count="5" id="12345">

S:      <qDate>2000-06-08T22:00:00.0Z</qDate>

S:      <msg>urn:ietf:params:xml:ns:changePoll-1.0 not supported in login services</msg>

S:    </msgQ>

S:    <resData>

S:      <obj:trnData

S:       xmlns:obj="urn:ietf:params:xml:ns:obj-1.0">

S:        <obj:name>example.com</obj:name>

S:        <obj:trStatus>pending</obj:trStatus>

S:        <obj:reID>ClientX</obj:reID>

S:        <obj:reDate>2000-06-08T22:00:00.0Z</obj:reDate>

S:        <obj:acID>ClientY</obj:acID>

S:        <obj:acDate>2000-06-13T22:00:00.0Z</obj:acDate>

S:        <obj:exDate>2002-09-08T22:00:00.0Z</obj:exDate>

S:      </obj:trnData>

S:    </resData>

S:    <trID>

S:      <clTRID>ABC-12345</clTRID>

S:      <svTRID>54321-XYZ</svTRID>

S:    </trID>

S:  </response>

S:</epp>


Thoughts?

—

JG

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>
From: regext <[e-mail]> on behalf of Martin Casanova <[e-mail]>
Date: Tuesday, January 30, 2018 at 9:14 AM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt


Hi

Thank you for the new version 07 of the draft-ietf-regext-change-poll.

May I ask a question about it?

"RFC5730 states: The <svcs> element MAY contain an OPTIONAL <svcExtension> element that contains one or more <extURI> elements that identify object extensions to be used during the session."

The extension should be specified in the EPP Login command otherwise it will not be available for the client during that EPP session. I suppose this is also the case for this change-poll extension..

What happens if a client does not specify the change-poll extension in the Login command but starts consuming all its poll messages? Are the change-poll messages delivered just without the

<extension> <changePoll> element or are these poll messages retained until a change-poll enabled EPP-Session polls them?

Thank you.

Martin Casanova







On 29.01.2018 20:40, Gould, James wrote:

Hi,



I published the revised draft-ietf-regext-change-poll based on the feedback received during the WGLC.  Please provide any additional feedback on the list.



Thanks,



—



JG







James Gould

Distinguished Engineer

[e-mail]<mailto:[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/><http://verisigninc.com/>

On 1/29/18, 2:38 PM, "regext on behalf of [e-mail]<mailto:[e-mail]>" <[e-mail] on behalf of [e-mail]><mailto:[e-mail][e-mail]> wrote:





    A New Internet-Draft is available from the on-line Internet-Drafts directories.

    This draft is a work item of the Registration Protocols Extensions WG of the IETF.



            Title           : Change Poll Extension for the Extensible Provisioning Protocol (EPP)

            Authors         : James Gould

                              Kal Feher

           Filename        : draft-ietf-regext-change-poll-07.txt

           Pages           : 26

           Date            : 2018-01-29



    Abstract:

       This document describes an Extensible Provisioning Protocol (EPP)

       extension for notifying clients of operations on client sponsored

       objects that were not initiated by the client through EPP.  These

       operations may include contractual or policy requirements including

       but not limited to regular batch processes, customer support actions,

       Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid

       Suspension (URS) actions, court directed actions, and bulk updates

       based on customer requests.  Since the client is not directly

       involved or knowledgable of these operations, the extension is used

       along with an EPP object mapping to provide the resulting state of

       the post-operation object, and optionally a pre-operation object,

       with the operation meta-data of what, when, who, and why.





    The IETF datatracker status page for this draft is:

    https://datatracker.ietf.org/doc/draft-ietf-regext-change-poll/



    There are also htmlized versions available at:

    https://tools.ietf.org/html/draft-ietf-regext-change-poll-07

    https://datatracker.ietf.org/doc/html/draft-ietf-regext-change-poll-07



    A diff from the previous version is available at:

    https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-change-poll-07





    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org.



    Internet-Drafts are also available by anonymous FTP at:

    ftp://ftp.ietf.org/internet-drafts/



    _______________________________________________

    regext mailing list

    [e-mail]<mailto:[e-mail]>

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





_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

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



--

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone [phone], direct [phone]

[e-mail]<mailto:[e-mail]>, www.switch.ch<http://www.switch.ch>



Working for a better digital world