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 jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 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)" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> 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: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
