IETF Logo Mail Archive

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Tue, 14 July 2020 09:52 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 0DFF43A0882 for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 02:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, 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 b9EPwkoJp7jh for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 02:52:17 -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 35E5C3A0891 for <regext@ietf.org>; Tue, 14 Jul 2020 02:52:16 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4B5bQk6SJXz4v7Z; Tue, 14 Jul 2020 11:52:14 +0200 (CEST)
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 8B681719BA; Tue, 14 Jul 2020 11:52:14 +0200 (MESZ)
To: regext@ietf.org
References: <20200314164521.0B10EF406C9@rfc-editor.org> <ac9d9567-e847-8802-14e4-07c36e216c19@knipp.de> <5703B97E-20EF-4FCA-AA32-68AF595A088F@verisign.com> <04d5dfb5-d9ae-06a9-b137-4cedcefbc399@knipp.de> <9EF7EBBA-9E2E-4478-9F5B-1AC3C50191C5@verisign.com> <5f1f0f3f-d801-3591-68b6-f9ee044e3305@knipp.de> <36C57CBC-D931-4B87-B4DE-27A75CA28E38@verisign.com>
Cc: support@tango-rs.com
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Message-ID: <5f93bb04-16fd-8a9c-9a79-4a225e5d9563@knipp.de>
Date: Tue, 14 Jul 2020 11:52:14 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <36C57CBC-D931-4B87-B4DE-27A75CA28E38@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
Authentication-Results: kmx5a.knipp.de; none
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4B5bQk6SJXz4v7Z
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]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/gWV_3FKhKY3EiPrWvh6pCRr6yl0>
Subject: Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
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, 14 Jul 2020 09:52:19 -0000

James,

On 7/13/20 21:46, Gould, James wrote:

> Thomas, 
> 
> Signaling support for fee-1.0 in the login services is not material for this use case.  The key element is whether the create of the premium domain name will fail if the client does not know the correct fee and the fee extension is required to be passed on create.  I don't see a code breakage scenario here, but I don't know what mix of extensions you're dealing with.  

So, case in point: once we roll out support for fee-1.0, TANGO will also
keep supporting the older fee extension versions fee-0.8, fee-0.21 and
fee-0.23 (the RFC recommends to allow older versions to facilitate
migration to new versions).

Now, none of these old versions had the requirement to report "domain not
available" if no fee extension is included in a premium domain check.

So, registrars currently using fee-0.21 for example will expect
availability checks to truthfully report avail=1 for premium domains in
such a scenario. Just the fact that the registry system was updated to
also support fee-1.0 should not change the system's behavior from their
point of view, should it? Otherwise, they would be forced to change their
<domain:check> clients to include the fee extension to get the previous
availability results - to accommodate a change caused by a fee extension
version they don't even use.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: support@tango-rs.com
Germany

v2.23.0 | Report a Bug | By Email