Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
"Gould, James" <jgould@verisign.com> Tue, 27 October 2020 14:37 UTC
Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621843A0B22 for <regext@ietfa.amsl.com>; Tue, 27 Oct 2020 07:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vqvGxXW3b4X for <regext@ietfa.amsl.com>; Tue, 27 Oct 2020 07:37:29 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFC93A0B1F for <regext@ietf.org>; Tue, 27 Oct 2020 07:37:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=10072; q=dns/txt; s=VRSN; t=1603809449; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=xDB+25kHoncACe1URd9rbtITxHWZp4VkmL2bazazE6Q=; b=QhL6qGrrftEU8LXXpJzyPEgXfEJF0+rpA+faMr9yoIOlplM48/rGUG0x /bhb/EgY7AgUkc3D+ui9fxMcRq70vqXHap0N+5IircbicnU0JioXsG/ct XMx5bXdcAaIbS405tvJwBalnylrR3gTaV6DQhrS+tOs8F09WmEI9l2AhM ebR7YGkGzBNfzO2mR04C+Lb4Q2o4wGqq5evKtkUYuID6OqhF9GKswip2U glreuTJAT5D20KssMqw5K1bMVTvlxueuTZJJwbqJq57qiKqwwRXX9DzuS RfUtOCf4qa7tHgYM0pIuOzZtAK0n0L1i74YCNSD3n7RPZH65wkNAP13qF w==;
IronPort-SDR: i2EOdvSgqgY+bvdvPuX0QrBKPii8zIFU191OmAd4opfQLwbvBDXTQZDEGdRwtli9ia7hYaaVvN YMbtVQKPt4qh6kPW1j6AOFLJ4BSRgTTN+wKq97Y0AASb9crpv2I6l3h9wLqz1IXrT8Tg2azgws wLMYOk2TPWoMbvhkYpSggZradpF28ivK2MzlMaJ1gA54p5oK6CpuCG66qPEkLCfKP44BmH7f+V EGF0DQ+1Cf1zm+UqhLc8NFSis7YRLMEdEpghZTmkFCcPo1DhTdW797QU+HGN6Z3qgOXGd/bUV1 /tg=
X-IronPort-AV: E=Sophos;i="5.77,424,1596513600"; d="scan'208";a="3331830"
IronPort-PHdr: 9a23:nPeo4xUReEJZ1NeMXcDxCNEs81vV8LGtZVwlr6E/grcLSJyIuqrYZRSCtadThVPEFb/W9+hDw7KP9fy5BipQsN3d6DgrS99lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrrwjdrMobjI9tJqs+1hfCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P286+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VDG/5KplVBPklCEKPCM//WrKiMJ/kbhbrQqhqRJh3oDUfI+bOvlwfqzfc9waRHZOUMleWCFaHoOzdI4PA/YdMetCrYTwoUYFoxukBQmrAePi0jFEiH7x3a0n1+QuDBnK1xEkEd0UtXTbss71OKkPWu2yzqnIwjLDb+5S2Tjg84XIbA4uoeuNXbJrcMrRxk8vGxnZgVWXrIzoJjWY3fkCvGaH9eRvT/6vi3I5pAFrpDii3sUhh4bUi44L1l3K+iR0zYY2KNC8R0B3fNCqHZRQui2GOYZ6X8wsTm51tSs11LELtoC2cTYXxZknyRDRa+CLf5aO7xn+WuiRJjJ4i2hkeLK5nxuy71avyvf9Vsmv0VZKoSxFktjKtn8RzRDc9s+HSv5l8ki92DaPzBzc6uZeLU8okqrbLoYtwr8umZoPv0TPBCj2mF/5jKKQa04q+fCo5vz6brn6vJOQKo15hw/kPqgzmsGyD/40PwcKUmSD5OiwyKfv8VD7TblWlPE6j6bUvZPAKcgGpaO0BRJe3Jw55BalFTim1cwVnXwALF1YZh2Kl5PpO1TSIPDgCve/nkisnC9rx//YOr3hBY3AI2Xfnrn5YLpy61ZSxgUywtxD+Z5YEK8BL+70Wk/rrNzUFAU2PBGuz+b5EtV9zYUeVXiTDa+eNaPeqV6I5uQxLOmQfIIZpSrxJ+I46/Psg3I1g0IRcKmn0JcNZ321GuxqI0CDbnrthtcBH30Kvg07TOHyil2CXjlTZ2u2X60h/Tw7FpypDZ3CRoC2gbyB0yG7EodKaWBBD1CACW3oeJmcW/cQdCKSJddsnCIEVbimTo8uzwquuBXkxrpgNOrU5jMXuIng1Nhz5u3TjQky+SZpAMuDy2uNVX17nnsURz8q26ByuVZ9xUmM0admjP1YCcde5/JXXQcmO57Q1et6C8r9WlGJQtDcAmqmRdCvGncaScgtzvcNZUdlA5Oug1qLixaqBLocjPqgA4Yo/4rf2XnpP4BxxiCCnOM7glYrUtdnNGC6iOh47QeZT9rTnkqUh7qCdKkA0mjK7mjVnkSUu0QNGiF3TKHJGTg9b07btp6xskHNSKKqBZw5PxFA0s+NLO1Bbdi/3gYOf+vqJNmLOzH5oGy3Hxvdnr4=
X-IPAS-Result: A2EvBADXL5hf/zGZrQpWBwMeATwMAgsVgU+BdYElgTQKhDKRE4N5li+BQD0LAQEBAQEBAQEBCAEfEAQBAQKBU4J1AheBcCY2Bw4CAwEBCwEBAQUBAQEBAQYDAQEBAoZKDII3Ins9DT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHAR8BBAEjETobAgEIGgISARMCAgIwFRACBAEJCYMmAYJcp2yBMoVXhHiBDiqFUhI8QoZygUI+gTgcgk0+hBAVGBcKJgECgk0zgiwEk1KkNAMHgmuIBIECghiJQ4YeFgmDF4EqiGODUZBpkVuBZIkBEoFjkRSELwIEAgQFAhWBWwaCBXAVOyoBgj4JRxcCDY5WgzqKVnQOJwMCBgEJAQEDCYwEDx6BBoERAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 27 Oct 2020 10:37:26 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.002; Tue, 27 Oct 2020 10:37:26 -0400
From: "Gould, James" <jgould@verisign.com>
To: "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
Thread-Index: AQHWq6DHvfSQl0/s1E6A0aOrvzSENKmqWQCAgAEtHwA=
Date: Tue, 27 Oct 2020 14:37:26 +0000
Message-ID: <EE0BE74D-4BBB-4C34-9EFF-E10DD21CAE2F@verisign.com>
References: <04DF4069-4B02-489C-BB6E-94DEB581F862@elistx.com> <27FB25BD-4DBC-4EA6-9DF1-1B7A92E77BB1@elistx.com> <ad955cf5-d963-5560-7616-4680c9b41a04@knipp.de>
In-Reply-To: <ad955cf5-d963-5560-7616-4680c9b41a04@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <26284BAC93CD89438672DB9F3D1AAB2A@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/d4P3lBYi24H577LJZiyZubkIprU>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 14:37:30 -0000
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 jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com> 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" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> 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: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: Thomas.Corte@knipp.de Software-Entwicklung E-Mail: Thomas.Corte@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1f0HYdHXFhIZdNtUuDPMth7JgdzR810M-AuwpsSOxavpswnXwC9uBX6r1GtF22pYXfEB0y1mxI9RZ3jf2OA9ozwodCluzWZ5AgWS6uqvsMLDFgkaDBf5I6HeYW5h3ZkkW_4u5oq_DMs0LNeq9Q0tPaXwrhDUjOcrm0mjqYSfxK52UH5o0vI6YorFS0ZmobmVj0CUyaJa0jbS3VsJ_s45PyGAQsrGfjxEgVXJ8temeReLsPKuDIwadLECZtkhIA4XxSxaNmggxeECgIz6jEmlvyKUOY4yDHqF3zQEgc5n4oq8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
- [regext] WG LAST CALL: draft-ietf-regext-unhandle… James Galvin
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Tobias Sattler
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Roger D Carney
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Mario Loffredo
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… James Galvin
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Thomas Corte
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Thomas Corte
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Martin Casanova
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Patrick Mevzek
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… James Galvin
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… Gould, James
- Re: [regext] WG LAST CALL: draft-ietf-regext-unha… James Galvin