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

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Fri, 10 July 2020 09:48 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 683393A0044 for <regext@ietfa.amsl.com>; Fri, 10 Jul 2020 02:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bAtxV2ZAXasj for <regext@ietfa.amsl.com>; Fri, 10 Jul 2020 02:48:07 -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 B8FBE3A0063 for <regext@ietf.org>; Fri, 10 Jul 2020 02:48:06 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [IPv6:2a01:5b0:0:25::36]) by kmx5a.knipp.de (Postfix) with ESMTP id 4B37Wm19dqz4vDD for <regext@ietf.org>; Fri, 10 Jul 2020 11:48:03 +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 ED69D719A3 for <regext@ietf.org>; Fri, 10 Jul 2020 11:48:02 +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>
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <5f1f0f3f-d801-3591-68b6-f9ee044e3305@knipp.de>
Date: Fri, 10 Jul 2020 11:48:02 +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: <9EF7EBBA-9E2E-4478-9F5B-1AC3C50191C5@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: 4B37Wm19dqz4vDD
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:2a01:5b0::/32, country:DE]; LOCAL_WL_IP(0.00)[2a01:5b0:0:25::36]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/QR8Wn49ZnvvEZPqLAdUdlodrojc>
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: Fri, 10 Jul 2020 09:48:09 -0000

Hello,

On 6/26/20 16:18, Gould, James wrote:

> The goal is to cover the case of a client not passing the fee extension at all, with the assumption that the fee extension would reference the create command.  It's simpler to make the case based on the existence or non-existence of the fee extension in the check command, but there may be cases were the renew fee matches the create fee.  It's up to the server to determine whether a particular domain will fail on create without the client having the correct non-standard fee.  I realize that there are corner cases where the client may know the fee, based on assuming that the create fee matches the renew fee, or the fees are provided out-of-band to EPP, but to cover the intent of the RFC the safest approach is to return avail="0" for a premium domain if the fee extension is not passed in the check command.
> 
> The server MUST return avail="0" in its response to a <check> command
> for any object in the <check> command that does not include the
> <fee:check> extension for which the server would likewise fail a
> domain <create> command when no <fee> extension is provided for that
> same object. 

Another clarifying question: the above only needs to happen if the client
at least signaled its general understanding of the fee-1.0 extension in
the EPP <login> command, correct?

Otherwise (i.e., if the server needs to report premiums as unavailable
even to clients who are not aware of fee-1.0), this RFC would be asking
for a change in a server's behavior just by virtue of introducing support
for fee-1.0, which would mean that clients not using any fee extension
(or an older version which didn't yet have this requirement) would see an
unexpected code-breaking change, no?

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: Thomas.Corte@knipp.de
Germany