Patrick, Thank you for your review and feedback. I provide answers to your feedback 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 4/27/20, 1:08 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Mon, Mar 16, 2020, at 09:28, Gould, James wrote: > > One question that was raised by Patrick Mevzek on the mailing list was > associated with signaling the implementation of a BCP by the server > that I believe would also apply to the client. This question applies to > the two REGEXT BCP drafts draft-ietf-regext-secure-authinfo-transfer > and draft-ietf-regext-unhandled-namespaces. Aside, for this last one that is using extValue I think the extValue should be more properly categorized to be related to this extension. Rationale: 1) even if you put a message in <reason>, this part is clearly for humans, so no software should have to rely on this content 2) extValue can be used for many things. In fact the way the draft is using it is kind of violating what RFC 5730 says about it: "A <value> element that identifies a client-provided element (including XML tag and value) that caused a server error condition." What will now be put there is NOT client-provided but server-provided. Which is also one of the reason why I have mixed feelings to handle unhandled namespaces that way even if there are no other proposals. So at least maybe something like: <extValue> <value xmlns:unhandled="...."> <unhandled:content> (here would appear the XML part that the server wants to give but can't because the associated namespace was not selected by client at login) </unhandled:content> </value> </extValue> Introducing new content can break existing client without proper signalling. You might say that if clients have to be updated to do that, they might as well be updated to correctly handle the unhandled namespace part, but as discussed previously already, things are not so simple in real life. JG - Providing an explicit reason as defined in the draft will enable the client to monitor for an unhandled namespace. In the Verisign EPP SDK, I was able to leverage the preformatted reason to easily pull out the namespaces that are unhandled in a utility method. I realize that the reason is meant to be human readable, but in this case it helps the client software to monitor for unhandled namespaces. By including the XML of the unhandled namespace in the <value> element, it provides the option for the client to record the unhandled information for later processing. Including additional XML around the unhandled XML doesn't really help the client. I found it extremely straight forward to filter the unhandled namespace XML for poll messages and for regular responses, and identifying the processing the unhandled namespaces in the client. I recommend that you try creating a client utility method for unhandled namespaces in your Perl EPP SDK to see how straight forward it is. Hopefully we can discuss your proposal at the WG meeting today. > The only existing signaling > mechanism in EPP is the use of the greeting and login services. A > namespace URI could be assigned for each BCP draft that is included as > an <objURI> or an <extURI> in the greeting to inform the client of the > support of the BCP by the server, and in the login command to inform > the server of the support of the BCP by the client. Between the two > options, I prefer the use of the <extURI>. The questions for the > working group include: > > > 1. Is signaling needed in EPP for the implementation of BCPs? I think so. JG - Agreed > 2. If signaling is needed: 1. Will the existing signaling mechanism > in EPP with the greeting and login services meet the purpose? There is currently no other option. Contrary to TLS handshake for example where each part is able to offer details on its capabilities before deciding to pursue the exchange or not, in EPP the client has to accept what the server says, or do nothing. JG - The only other option is to create an extension to serve the purpose of BCP signaling, but I believe the use of the login and greeting services meets the need. > 2. Of the two service URIs <objURI> and <extURI>, which is the > preferred URI to use? extURI is the only one matching semantically. RFC 5730 says: " One or more <objURI> elements that contain namespace URIs representing the objects that the server is capable of managing. " If the namespace URI is not about an object, then it shouldn't be an objURI. JG - Agreed > 3. What URI scheme should be used? > i. One proposal is to include bcp in the namespace, such as > “urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-<version>” and > “urn:ietf:params:xml:ns:epp:bcp:unhandled-namespaces-<version>”. The > <version> would be updated based on material updates to the BCP draft > and bumped to 1.0 after WGLC. I am not sure of what I think, but I am not immediately a huge fan of putting bcp in the namespace. I do not know if there are other examples in other working group/the IETF, but the main problem I see is that BCPs can change during time, and you won't be able to change the namespace once it has this in its name. JG - The bcp namespace in the URI is used to put the namespace URI in an appropriate category, which in this case is for EPP BCPs. If and when the BCP changes materially, the <version> will change in the URI. I updated the drafts with the following IANA URI registrations: urn:ietf:params:xml:ns:epp:bcp:unhandled-namespaces-0.1 urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1 If there is a material change to the drafts, the version will be bumped up to 0.2, and so forth. Once the drafts make it past WGLC, the version will be bumped up to 1.0. The scheme to use will be discussed during the WG meeting. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1PMmzE4sHShzbKuL_EXUWqSC_QxkcDWvlM-Tk56--L4aV_dm4ocjqrL8-a0oFf0_v9A9F6ME0GtBZgcg5_7cst45bMqG72i9lOtG2lOxm5UtGj4FhY2zscg4JMynPQApfhCCtnHJEOrsObvM5pcDgiaj0A2GulS7cQFivv3-Y-Wrw02gKYjGakpP53TwoN7Oib1AgGQ0uZUgeKfivWKwTm-tkxv3uz3cyPCMCYUJK0SbP50qfDlcWYp2OwrLKkjJGSkIcKqpJJ0IY_dsV3LoxcJqQSBtX0KZCPWDLnkek1pg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
