IETF Logo Mail Archive

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

Thomas Corte <Thomas.Corte@knipp.de> Tue, 27 October 2020 15:55 UTC

Return-Path: <Thomas.Corte@knipp.de>
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 40D7D3A0FAE for <regext@ietfa.amsl.com>; Tue, 27 Oct 2020 08:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.144
X-Spam-Level:
X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 GM4aBHBd1P1r for <regext@ietfa.amsl.com>; Tue, 27 Oct 2020 08:55:48 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [IPv6:2a01:5b0:0:29::63]) (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 8B47B3A0F74 for <regext@ietf.org>; Tue, 27 Oct 2020 08:55:48 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4CLGWk3Szwz4tyG for <regext@ietf.org>; Tue, 27 Oct 2020 16:55:46 +0100 (CET)
Received: from dhcp203.intra.dtm.knipp.de (dhcp203.intra.dtm.knipp.de [195.253.2.203]) by hp9000.do.knipp.de (Postfix) with ESMTP id 12B4570FA9 for <regext@ietf.org>; Tue, 27 Oct 2020 16:55:46 +0100 (MEZ)
To: regext@ietf.org
References: <04DF4069-4B02-489C-BB6E-94DEB581F862@elistx.com> <27FB25BD-4DBC-4EA6-9DF1-1B7A92E77BB1@elistx.com> <ad955cf5-d963-5560-7616-4680c9b41a04@knipp.de> <EE0BE74D-4BBB-4C34-9EFF-E10DD21CAE2F@verisign.com>
From: Thomas Corte <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <950b3464-2a19-a959-b4f7-0652c2bfa58b@knipp.de>
Date: Tue, 27 Oct 2020 16:55:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <EE0BE74D-4BBB-4C34-9EFF-E10DD21CAE2F@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
X-Rspamd-Server: v1117
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; LOCAL_WL_IP(0.00)[195.253.2.54]
X-Rspamd-Queue-Id: 4CLGWk3Szwz4tyG
Authentication-Results: kmx5a.knipp.de; none
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/dWJmCxQzjx3wLUG-3YspwkFlkLo>
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 15:55:50 -0000

Hello,

On 10/27/20 15:37, Gould, James wrote:

> 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?

Sounds reasonable to me. With the current EPP RFCs, there's really no
"100% clean" solution here, but the approach makes a good effort to
somehow convey that there's data available without disrupting client
implementations.

If a registry really wants registrars to understand and process their
custom poll messages, it can still resort to simply reject the <login>
command if it doesn't contain the namespace in question.

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

v2.23.0 | Report a Bug | By Email