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

["Gould, James" <[e-mail]>]

Thomas,

The versions of the fee extension that you reference have similar language associated with returning avail="0" for premium domains:

1. fee-0.23 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-08#section-4
2. fee-0.21 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-05#section-4
 
In both cases it reads:

   The server MUST return avail="0" in its response to a <check> command
   for any domain name 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 domain name.

The very old fee-0.8 version specifies in https://tools.ietf.org/html/draft-brown-epp-fees-05#section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this extension must be used.", which provides flexibility for the server to normalize the behavior as defined in draft-ietf-regext-epp-fees-05, draft-ietf-regext-epp-fees-08, and RFC 8748.  

This use case was discussed at length in the working group, where returning a premium domain name as available without the required fee to use on create will result in a failure downstream.  This is the reason for the language starting in draft-ietf-regext-epp-fees-04.     

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 7/14/20, 5:52 AM, "regext on behalf of Thomas Corte (TANGO support)" <[e-mail] on behalf of [e-mail]> wrote:

    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: [phone]
    Martin-Schmeisser-Weg 9                       Fax: [phone]
    D-44227 Dortmund                       E-Mail: [e-mail]
    Germany
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://secure-web.cisco.com/1tS78h3zvnAPOtomCdUHVDM7D17WfX22p7Pd6zVlMsgS7lzILKOFXHeNh8Isr52cCXcvBSyQkAjKy5zjYK_vBbzpvnNtdI0R5NVrFQzRfv8jgv9C-99xdcmRQKwkeUqvWb4lnu8Tw8WH4t_lgA2ZF8VF4zgoPcDVKXKjN7HgN1owdVTlosmxBYewNDGlYXWIXhTuj4owNa0-n7d-SrGRBiT1FzRcNuu_UpoGGAx_fcq6fRKp8O3O3l_i7I9UzKI0fDJ2m4-Zj8evpLArNgCwbUuU_H8ynwmD9WouiD4aDy68/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext