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

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Fri, 26 June 2020 14:41 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 170893A0764 for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:41:29 -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 r2SeDtPWuVzw for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:41:27 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [195.253.6.99]) (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 B3F5B3A0598 for <regext@ietf.org>; Fri, 26 Jun 2020 07:41:26 -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 49tfhh59gFz4vDL; Fri, 26 Jun 2020 16:41:24 +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 741D171918; Fri, 26 Jun 2020 16:41:24 +0200 (MESZ)
To: "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <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>
Autocrypt: addr=Thomas.Corte@knipp.de; prefer-encrypt=mutual; keydata= mQGiBDtvzjIRBAD2csyfVM8EPe+Pd/iYhwDP7fHAMCoZNsPBId4UrOQraKflyVCq2aOMVofw G2ayL377DewD+Va2GYgNes7a1bVLc0KxUCfvCKm3mLcBd8ScWaPurWMinTFHMBDm0CVIbIM6 P22HEqQ5w38W/yaisitIstU4MV9MLYttbUIZg75MvQCg/xNEFuhmmmp9hYnopxoyniDkovUD /iv7jhPtn4M/bOxCcSBYE1lJ6kILe1Z3rc5N9Ymr7uzUOffTt9JDqq9/2MujKODo5KosNC+m r6F1XC1a7KvhhjBofGHxQt9YZtCmHmdgumg5XoKwuujYG9BT1oKxj5/rnRHwT8GzxLL0YyAp Sbu6UfpAjhHAFtiL5Bg9fpDA2OAHA/9P/aSSE/FG0Rh7i6t+jZe/BCX5i4rns3UmjW7pzj/e wZENsKST72x5YVvbtXzYw620v7EFmZB99+UftXg6ggZUHkaDllR9lN75s9ih8cWI5zhj6OA8 LGsc4CqudNa0TSFdHTaHOT8QJtfP8UFJYcJd2ahOPXDIcqGd2JdGPHXO4bQkVGhvbWFzIENv cnRlIDxUaG9tYXMuQ29ydGVAa25pcHAuZGU+iEsEEBECAAsFAjtvzjIECwMBAgAKCRDz5VkQ Ov//nJKaAJ4h/hksIIt3Zmkmwt7IT8VtwyYkcQCcDvapUlelcVQRKDB9cwPkZkwmQXO5Ag0E O2/OMhAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VHMGHOfMlm /xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMc fFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLW hsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIIAKOz DOAHt4rHGwJbacsUbB0O4Y7Wm5f1dEyMeh2IKWZB557W90PPMaJlKqc5BRImOgY6/mCaGY3i bn0axP/2zQe0yX1NCudPXLFzazztSBsaQeQGZ8fBo3RHMdG9QgI39KHvHRuyTJ2qiiUkB43R 5JP9uJcQ/ca9COBpFR6L05YMleh9du1EVKPoKUFjjIFrS8DTN3RuCMTvmey6U6NRyg6O6/4x VpNBZTrn4i9r3oZ0drd1UpdEuFvMpfKgch08W3EUfGQaqasrja77rwGWG1CIJfQrtgkfNiHj kX9uJRDGmKln8Q7xntQPFAx7kDId4ZcaWruEoK916HJbrmIWmWuIPwMFGDtvzjLz5VkQOv// nBECnWYAoIfyMQI8fKTCMc0pdvycfsbwCYA9AKCFE9M915HNchKGzKCxIQQbnLNXSA==
Message-ID: <07e7b73b-3d87-c8bc-1d19-f783f1b02879@knipp.de>
Date: Fri, 26 Jun 2020 16:41:26 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.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: 49tfhh59gFz4vDL
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/YmDsmjtZLKg-UUBsXKLEOttH2GA>
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, 26 Jun 2020 14:41:29 -0000

Hello James,

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

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

In my example, the fee extension was passed, but only asking for the
*renew* fee (which may be standard), not for the *create* fee (which may
be non-standard). Based on your answer above, the server would have to
return avail=1" then (because *some* fee extension was passed), however
the client would still be unaware that the create fee is non-standard.

If the "safest approach" is the goal here, it would probably be better
(albeit indeed more implementation effort) to not only require the fee
extension, but to specifically require the fee extension checking the
"create" price, no?

In this case, the RFC text may need a clarification, as it currently
doesn't reflect such a specific requirement. I'm aware this is a rare
corner case, but still one that should be covered.

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