Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

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

Thomas,

Unfortunately returning an error would not enable the client to consume the poll message, which would result in a poison poll message and a large client impact.  Use of draft-ietf-regext-unhandled-namespaces within an error response for a poll message would break the processing of poll messages and would still not provide information that was provided by the client, since the poll message is supplied by the server.  I don't believe blocking the poll queue with a poison message is a desired end state, since an unsupported message (e.g., change poll message) may not be of interest to the client but other supported messages like transfer poll messages are.  The client can decide on the poll message of interest by supporting the extensions that they're interested in without blocking the poll queue and without the server breaking compliance with the RFC by blindly returning the poll message independent of the client login services.  

As noted previously, when the <extValue> was defined in EPP RFC 5730, the description of the element never considered this use case.  draft-ietf-regext-unhandled-namespaces defines a new usage of the <extValue> element, which is a form of extension and thus the reason why there is a namespace in the server greeting to indicate that the server supports it.  As you indicate that there is no real technical impact to the client other than they may not be aware of the extra content in the poll message; although there is a predefined reason that the client can key off of defined within draft-ietf-regext-unhandled-namespaces.  

A compromise is to formally define the original intent of the <extValue> element, as defined in RFC 5730, and be explicit that draft-ietf-regext-unhandled-namespaces extends its usage to cover this use case within section 3 "Use of EPP <extValue> for Unhandled Namespace Data".  To address the concern for the client potentially ignoring the content returned by the server per draft-ietf-regext-unhandled-namespaces, text could be added to recommend that the server monitor for the usage of draft-ietf-regext-unhandled-namespaces in both General EPP Responses and Poll Message EPP Responses to inform the client out-of-band of their lack of support for a particular extension.  In addition, it could be recommended for the client to monitor for the usage of draft-ietf-regext-unhandled-namespaces to proactively identify extensions that they need to add support for.   An Implementation Considerations section could be added for this.  Thoughts to this compromise?

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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

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

On 10/26/20, 12:39 PM, "regext on behalf of Thomas Corte" <[e-mail] on behalf of [e-mail]> wrote:

    Hello,

    On 10/26/20 15:01, James Galvin wrote:

    > Current consensus is to seek publication.  However, we are a relatively
    > small group and we would like all comments considered by multiple
    > people.  Would others please indicate their point of view in the active
    > thread between James and Patrick?

    As both an EPP client (and server) developer, I think that both James and
    Patrick make valid points, though I tend to agree more with Patrick's
    point of view.

    I'd fully agree with Patrick that the draft is somewhat abusing the
    <extValue> mechanism, as it was clearly designed in RFC 5730 to
    communicate "error diagnostic information", with the <value> containing a
    "client-provided element (including XML tag and value)". In fact, from
    this wording one could even derive that it's *not* proper server behavior
    at all to include anything in the <value> element that didn't also appear
    in the client's EPP command, which this draft is asking servers to do.

    One the other hand, I'd agree that it's probably the only place where
    non-parsed XML can be included in responses, which is the only way to
    keep the server's responses from violating the contract by including
    namespaces not listed as supported by the client.

    In our own current client implementation, we're only consulting the
    <extValue> content if the result code indicates an error. I'd assume that
    many clients do it this way, which is why I doubt that the inclusions
    defined by the draft will do any real harm or even cause confusion.

    However, at best this means that clients will completely ignore the
    unhandled data, i.e. simply ignore the (apparently empty) poll messages
    and acknowledge them without processing. While this is nice in terms of
    not blocking any other (understood) poll messages, it also poses the
    problem that important poll messages may go unnoticed, potentially for
    extended periods of time, which may (depending on the nature of the
    messages) be a greater operational risk than blocking further polling.
    If an unhandled namespace simply showed up (violating the contract), at
    least my validating EPP client would croak, and I'd be forced to take
    action (ideally by adding support for the namespace and resume polling then).

    I know it's late in the game to come up with suggestions, but anyhow:
    a compromise to solve this, at least for the polling issue, *could* be to
    use <extValue> as described, but to return an *error response* (with a
    special result code) instead of a success response to the <poll> command.
    This could (somewhat) justify the use of <extValue>, while still alerting
    the EPP client about something that it might be missing. Of course, this
    would still mean that polling of further messages would come to a halt
    until the issue is fixed on the client side.

    Best regards,

    Thomas

    -- 
    ____________________________________________________________________
         |       |
         | knipp |            Knipp  Medien und Kommunikation GmbH
          -------                    Technologiepark
                                     Martin-Schmeißer-Weg 9
                                     44227 Dortmund
                                     Deutschland

         Dipl.-Informatiker          Tel:    [phone]
         Thomas Corte                Fax:    [phone]
         Stellvertretender Leiter    SIP:    [e-mail]
         Software-Entwicklung        E-Mail: [e-mail]

                                     Registereintrag:
                                     Amtsgericht Dortmund, HRB 13728

                                     Geschäftsführer:
                                     Dietmar Knipp, Elmar Knipp

    _______________________________________________
    regext mailing list
    [e-mail]
    https://secure-web.cisco.com/1f0HYdHXFhIZdNtUuDPMth7JgdzR810M-AuwpsSOxavpswnXwC9uBX6r1GtF22pYXfEB0y1mxI9RZ3jf2OA9ozwodCluzWZ5AgWS6uqvsMLDFgkaDBf5I6HeYW5h3ZkkW_4u5oq_DMs0LNeq9Q0tPaXwrhDUjOcrm0mjqYSfxK52UH5o0vI6YorFS0ZmobmVj0CUyaJa0jbS3VsJ_s45PyGAQsrGfjxEgVXJ8temeReLsPKuDIwadLECZtkhIA4XxSxaNmggxeECgIz6jEmlvyKUOY4yDHqF3zQEgc5n4oq8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext