David, Thank you for your review feedback. All of the nit updates have been made in draft-ietf-regext-unhandled-namespaces-06. The only change from what you proposed was to use “implementing” instead of “doing” in “the server should consider implementing the following”. The corresponding wording change will be made in “the client should consider implementing the following”. I looked at the indentation of all of the examples and I found a couple other issues that were addressed in draft-ietf-regext-unhandled-namespaces-06.
Thanks, -- JG [cid:image001.png@01D6CC9D.559C0B70] 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/> From: regext <regext-boun...@ietf.org> on behalf of "Smith, David - Dulles" <dsmith=40verisign....@dmarc.ietf.org> Date: Thursday, December 3, 2020 at 2:04 PM To: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] [regext] Shepherd's nits on draft-ietf-regext-unhandled-namespaces Hi – As the document shepherd for draft-ietf-regext-unhandled-namespaces, I reviewed the text of the draft and had the following feedback for consideration. It’s grouped by document section or page number. Abstract "server tof determine" -> "tof" typo 2. Unhandled Namespaces Original: "The unhandled namespaces problem exists when the server has information, that it needs to return to the client, that is not supported by the client" Proposal: "The unhandled namespaces problem exists when the server has information that it needs to return to the client but the namespace of the information is not supported by the client" 3. Use of EPP <extValue> for Unhandled Namespace Data Original: "caused a server error condition, and the <reason> element" Proposal: "caused a server error condition and the <reason> element" Original: "When a server has data to return to the client, that the client" Proposal: "When a server has data to return to the client that the client" [Page 8] The example includes a server response where the <secDNS> child elements are not indented but should be. 4. Signaling Client and Server Support Original: "in the server's Greeting extension services, can expect" Proposal: "in the server's Greeting extension services can expect" Original: "in the client's <login> Command extension services, can expect" Proposal: "in the client's <login> Command extension services can expect" 5. Usage with General EPP Responses Original: "MAY include it under in the <extValue>" Proposal: "MAY include it under the <extValue>" 7.1. Client Implementation Considerations Original: "Ensure that the login services is accurate with what is supported by the client." Proposal: "Ensure that the client presents the complete set of what it supports when presenting its login services" Original: "The unhandled namespace can be implemented" Proposal: "The unhandled namespace should be implemented" 7.2. Server Implementation Considerations Original: "the server should consider the following" Proposal: "the server should consider doing the following"
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
