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

"Gould, James" <jgould@verisign.com> Fri, 26 June 2020 14:47 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 3B5F63A0788 for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:47:01 -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 zZCebUT5IJ2v for <regext@ietfa.amsl.com>; Fri, 26 Jun 2020 07:46:58 -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 76FBF3A0778 for <regext@ietf.org>; Fri, 26 Jun 2020 07:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3162; q=dns/txt; s=VRSN; t=1593182818; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=2psIN7Wb7YzAgj9AV1poXZ0NYLL5D17fDp09WVlER8c=; b=Ht7f+rebXuBqzrdxCa5tgsaSU5hoPe4KJyrrfrlKKPue6exgFuH0E0OB baQWf3XfQVqIDKExIuCrvaWza2OEOLhnGQ6+Xn3AWXQPPX1S61RusVz6n FuhCNXg8sQ/qlaTb8gtjAlvFuoSmTDhzDe7BIxZc7HeVFPcwEN7Bq2fg6 r6t97hwUQxyYoaPpuhVypyHyY77e6yX7ZzhQm/f0bpN0gIq2bboBuW455 eawD2gNg6EvKFyDr5G2GxGRoXjLKF79YfPJOzAW/u34DPVBu5SgbYoeou sFpi0HFgDVyvliWGT2IsdRnFJhX0CcwyNdCO6RFVeJxO4MwTtxZ1BqHrx A==;
IronPort-SDR: /ui0PgFu+nioLwCHvasd3Yfv3hQ63ZlKNgLOFhdEt2F8Q+WS7K3aG/9JEnJpFdSwfbPPgF5Q6g Si2pXtqYKqw++NN9ZpbBeTuEY5UFbvSqaHpAeHhzq/GzeFbSXyxqvLwW6DglfWjfcaf+m4Ra8i HHuRlABF5l0KBe6FAh+kS1gtCSC84f1AfUTHDf6U3bB0y5SwsyDDv4CTB7AN0Vlm9Tgw3Tb2Ma HyCxu/O/BTceJ41n0lggLhjiy+Q1yYY7shXSH5f8jnyAt45OokDoVqVv2aSNIfygskNdWNY9c7 lVA=
X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="1921767"
IronPort-PHdr: =?us-ascii?q?9a23=3AzL/YxhbWtXOa/ysZycorp5f/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZpsy4Zx7h7PlgxGXEQZ/co6odzbaP7ua5CDVLsc7JmUtBWaQEbw?= =?us-ascii?q?UCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFR?= =?us-ascii?q?rlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRW7oR/MusQSnIduJaU8xg?= =?us-ascii?q?fUqXZUZupawn9lK0iOlBjm/Mew+5Bj8yVUu/0/8sNLTLv3caclQ7FGFToqK2?= =?us-ascii?q?866tHluhnFVguP+2ATUn4KnRpSAgjK9w/1U5HsuSbnrOV92S2aPcrrTbAoXD?= =?us-ascii?q?mp8qlmRAP0hCoBKjU09nzchM5tg6JBuB+vpwJxzZPIYI+bN/R+cKHSct0bRW?= =?us-ascii?q?VdUcheWDdMAp+nYIsKE+YNIfxVoov7qlATrRW+Hw6sBOb3xzNGh3H22rA60+?= =?us-ascii?q?A8Hg3ewQcuG8gBsHHKo9XuOqsZTOe4zKvHzTXEcvNW3Sry5ZPWch8/u/GMXK?= =?us-ascii?q?lwccveyUkpDQ/KklKQqYn8Mj6Ty+8CvHSV4fB6WuKzl24otRtxoj63y8oohI?= =?us-ascii?q?TEhJwZx1/E+ylkw4s7Kty1RkBnbdO5EpZdsyKXO5Z2T84jTWxltyg0xqAYtJ?= =?us-ascii?q?O6YCUHxpUqywDCZvCZc4aF5A/oWuiWITd9nn1lebS/ig6s8Ue+0O38V9K00F?= =?us-ascii?q?dFripDk9nMsGwC2wbP5ciAT/tw+Fqq1zWX1w3L9+1IPVo4mbfZJpMv2LI8i5?= =?us-ascii?q?oevErZEiL5m0j6lLKaelk+9uS16enrfq/qqoKTOoJ3kA3yL6cjl8qiCuoiKA?= =?us-ascii?q?cORXKU+eGk2b3m+k32XatFg+UtkqncrJDaPcMbprOlAwNN0oYs9RK/DzC+3d?= =?us-ascii?q?kFgXcJNE9JdxKfgYbmOl7CPO30Ae2hg1uwlzdr3ejGMqf7DZrQNHTDjq3hfa?= =?us-ascii?q?1760JG1AUzytVf64pVCrEHPv3zRlf8uMHEAhMjLgC5wejqBM9g2o4eV2+DGK?= =?us-ascii?q?CUPaDKvV+N/O0vIu2MZIEPuDb6Lvgo//zujXA+mV8AeammwIAaaG6mEfR8Ik?= =?us-ascii?q?WZenvsgtgHEWsQogU+S+nqhEWYUTFPf3ayQ7485jYjBYy4DYfDQYWtj6aa3C?= =?us-ascii?q?uhAJBWYXpGCkySHnrzdIWEXfYMaDqKIsN7jzMLS6CrS5U92hG2qA/6171nI/?= =?us-ascii?q?LO+iIGupLsytd05/HImBEz6zN0E8qd33uKT2FukWNbDwMxiepDoUt4w0zF+q?= =?us-ascii?q?9in/FwFtpS/+sPXgpwfcrgz+t/Asu0cQXbYtqhS1CnWs3gDTxnCpp72dIBbl?= =?us-ascii?q?ZhM9Svkh6F2DClSfdBjbGECYwo2qPRw3a3INxynSXozq4k2hMJRdZLOSnupK?= =?us-ascii?q?d6+hOZT9rLnEKEk6qCa6kG3TXM+2HFxm2L6hILGDVsWLnICChMLnDdqs70sx?= =?us-ascii?q?vP?=
X-IPAS-Result: =?us-ascii?q?A2ElBADtCfZe/zCZrQpdA4EJgUqDGYEzCoQmkG4lg3OWE?= =?us-ascii?q?4E/PQsBAQEBAQEBAQEHAR8QBAEBAoRFAheCFSU2Bw4CAwEBCwEBAQUBAQEBA?= =?us-ascii?q?QYDAQEBAoYXByYMgjcieDwJPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQUCCAdNB0cBHwEEASMRUwICAQgaAh8HAgICGRcVEAIEARKDJ?= =?us-ascii?q?gGCXK1JgTKKawWBCSqFM0aHB4FCPoE4DBCBT34+gQSDIRgXChkNgk0zgi0Ek?= =?us-ascii?q?i+GZZtfAweCW4hHkHUdhAybAZFIiD4SgUiQGoQdAgQCBAUCFYFaC4F+cBVlA?= =?us-ascii?q?YI+CUcXAg2LOoJ7H4M6ilZ0DiYDAgYBBwEBAwmOYYERAQE?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 26 Jun 2020 10:46:56 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%6]) with mapi id 15.01.1913.005; Fri, 26 Jun 2020 10:46:56 -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] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
Thread-Index: AQHWS8BAxPyuP9a+wUiwqG3Zbf/+Y6jq8cYAgABJhAD//758AA==
Date: Fri, 26 Jun 2020 14:46:56 +0000
Message-ID: <5AC84F96-3A68-4657-AB2D-34F094FFC0ED@verisign.com>
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> <07e7b73b-3d87-c8bc-1d19-f783f1b02879@knipp.de>
In-Reply-To: <07e7b73b-3d87-c8bc-1d19-f783f1b02879@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <76F573AC92B35D429220D9A993B7A5A5@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/YTuh2Vrz-B3EUDKewiUD6GkD4w0>
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:47:02 -0000

Thomas,

Yes, to cover the corner case, avail="0" is the best response when the client does not include "create" in the fee extension of the check command of a premium domain name.  Without knowing the create fee of the premium, the create will likely fail, thus avail="0" is the correct answer.  The intent of the language in the RFC was to cover the broader case of a client that doesn't pass the fee extension at all in the check command, but your corner case is applicable.    

-- 
 
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 6/26/20, 10:41 AM, "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> wrote:

    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