Re: [regext] [check] <reason> always prohibited when avail="1" ?

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

I would be more concerned about injecting domain names into the check response that were not queried for in the command than the inclusion of the optional reason element to explain why the domain name was added.  I looked at the approach taken with a similar extension, which is the Related Domain Extension (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v01.html).  The Related Domain Extension doesn't extend the domain check command / response, but does extend the domain info command / response, by including an explicit element extension in the command to include the additional information in the response, and including the additional information in the extension instead of changing the response information in RFC 5731.  RFC 9095 is an Informational RFC and RFC 5731 doesn't explicitly disallow, with normative language, including additional domains in the response or including a reason for an available domain.  This would fall into the territory of a functional extension (https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-eai#section-4), but RFC 9095 is a command-response extension, where an extension should be only one type.  I would have recommended following the approach taken with the Related Domain Extension in this case to use a single type of extension and to not change the behavior of the RFC 5731 response elements.             

-- 
 
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 9/29/21, 7:37 AM, "regext on behalf of Thomas Corte (TANGO support)" <[e-mail] on behalf of [e-mail]> wrote:

    Hello,

    On 9/29/21 13:01, Stephane Bortzmeyer wrote:

    > RFC 5731 3.1.1 seems to clearly prevent a <reason> to be sent when
    > avail="1".
    > 
    > But RFC 9095 6.1.1 has an example with a <reason> for avail="1".
    > 
    > So, is it really forbidden to send a <reason> to the client when the
    > domain is available but you want to send some extra conditions?

    Technically, it seems to me that the check response in RFC 9095 violates
    RFC 5731 anyway, because it asks for returning check results in the check
    response for domain names which were not present in the check command,
    while RFC 5731 clearly requires the check response to contain "A
    <domain:name> element that contains the fully qualified name of the
    queried domain object."

    Semantically, including a reason for a domain name's availability feels
    pointless, and the authors of RFC 5731 seemingly thought so, too.
    Most EPP clients won't expect a reason to be present for avail=1 and will
    simply ignore it.

    To me, using the <reason> element to add *conditions* that must be met
    for the name to be available feels like a misuse of that element.

    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/1o2D30Rdgr4WB9Fk9Xg9fLhpUAVN-Y9xfouuDKQ143L2BAhvOWr-J96nH8DwVKUhiY6TUG147yoC_ot-kLG2eF0qW_DGEUWDCHy7JSZS6QDIdbu_GqNN2qTkhWLXAlKUfxuos35xAO4xc2AcqlRVxXSHJG8R2_F-ekRL6OjI1jD_E6xuLzG9vkOqA5LHr2e_Uit-OEjPMOq5DZg6mNhlciMplOVFzumAkdNwBrd9-77gYwuQxuqGz8EvVwdp-SPEm/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext