Patrick, Thank you for your thoughts and feedback. I provide responses to your feedback embedded below.
-- 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 10/18/20, 10:07 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Fri, Oct 2, 2020, at 15:52, James Galvin wrote: > The following working group document is believed to be ready for > submission to the IESG for publication as a standards track document: > > https://secure-web.cisco.com/119Z6-9QCgolQ6IIOiTngyTDdKf1s3AaRBIxnoSkXH2U85ZP_AkwLkWZxbHfpOCtj0tOQgqGMA93ErjU_nX7UNe_uUkyJYV_6Do7PdfWfcCAJN7TaogAr1ErpuD8biWr-C7ZDwU0xROsE8h7FxzV3D01y4QmoAeeHGbG50UKbC7oFagBzR2dKXS3hv5-bVdXWwa2fkdW0SIVjPB3nL4n9CL6n1rTU5r0Z7PdqAUhJyS8zLeWg5leNiOHa686p1RLAFGuREUj-R-e-bziJjAlgVw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F This specification will create interoperability problems as drafted. Even if the server announces this extension, all current clients not knowing about it will have this new behavior forced on them, which contradicts what RFC 5730 says (see below). So the mechanism should be that the server does not enable this behavior until having explicit acknowledgement by the client that it is ok to do so. Considering a default opt-in puts all currently existing EPP clients at risk. JG - draft-ietf-regext-unhandled-namespaces addresses an interoperability issue with the server returning extensions that the client specified is not supported. The <extValue> element is already a feature supported by RFC 5730, so this is not something "forced on them". Consider the poll queue scenario, where the server does not know what the client supports when inserting the message, but will only know when the client consumes the message later. When asking for the poll message, should the server violate RFC 5730 by returning the message that contains an extension the client did not explicitly include in the login services? draft-ietf-regext-unhandled-namespaces provides an option to return the poll message without violating RFC 5730 based on what's specified in the login services using an existing protocol feature. This is not a new feature from a protocol perspective that will cause an interoperability issue. Especially since this specification redefines what is in RFC 5730, which says: Zero or more OPTIONAL <extValue> elements that can be used to provide additional error diagnostic information, including: * A <value> element that identifies a client-provided element (including XML tag and value) that caused a server error condition. Note the "client-provided element" and compare to this example in the draft: S: <extValue> S: <value> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>example.com</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: </domain:trnData> S: </value> <domain:trnData> was not client-provided, yet it is in extValue > value node. (so an existing client sticking to RFC5730 may see this content and believe it has made an error, and not understanding anything about the content provided since it is not at all a content coming from it, the client). It is also not really a "server error condition". The value/extValue of RFC 5730 have been stretched out as of their use in so many proprietary extensions, that I do not think it is a good idea to have standard even doing that. JG - Yes, the <extValue> is not being used for an client-side error condition in this use case and will not return client-side elements. The <extValue> is being used to indicate what response extensions could not be returned in their standard location due to lack of support by the client. There is no normative language in RFC 5730 that would prohibit the use of <extValue> for the use case covered in draft-ietf-regext-unhandled-namespaces. Going deeper, it is not even clear if RFC 5730 allows really a return code of success but still have value/extValue nodes. There may be nothing at it in the schema, but the text says: Success and failure results MUST NOT be mixed. [..] Zero or more OPTIONAL <value> elements [..] that caused a server error condition. Zero or more OPTIONAL <extValue> elements that can be used to provide additional error diagnostic information Note how both nodes are specifically tied to "errors". There may be clients out there that will consider value/extValue only for error return codes (>=2000) and will get confused when getting back 1000 but with extValue as this draft calls for. JG - RFC 5730 did not envision this case, which is the point with the standardization of draft-ietf-regext-unhandled-namespaces. This is not an error, so there is no mixing of success and failure results. draft-ietf-regext-unhandled-namespaces explicitly specifies the use of the <extValue> to address the mismatch of supported client and server extensions. Finally, It should certainly not be "Best Current Practice". It is neither proved to be "best" nor is it "current practice". JG - Thank you for your feedback on this. It was agreed to change the draft from a BCP to Standards Track based on a prior thread on the list. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1G70d8BFIRruB1gzgN4-l0VXcLRCOu5-Kkw155RE1urlw78x6COxKBNOVoKRD5d7gZRHjRtEaKwurVioHW6vjLWdedF59tepS4nOgAwDY53YAaaJ99XFQV4erv91A0jcXzvxlQ8_5CTfdCTgDlmfp2ZLEWB4TV4vGQxMh8Mbv6cnyzxKG7quFet4HcdzIgEjBrmnthnBXm8qRmSmXVt1637enoWqaiXOiciCJuraD95qGyU2defRxBMOLuRmsNYUnkIoOE76uJqu0wh_i4FPqfSoc4nDyyfR9DJIgHHU7gYE/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
