Patrick, I provide responses to your feedback below, prefixed with "JG - ". — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/11/19, 2:38 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Sun, Jan 6, 2019, at 23:02, Patrick Mevzek wrote: > Hello James and Martin, Thanks for your attention and comments to my email. I see that we are in disagreement, so I think it is not useful for me to go again over all points. My opinion still remains that at this stage the draft abuses RFC 5730 too much and needlessly because I believe there are other options that makes it more in line with RFC 5730 spirit. JG - We will agree to disagree on this one. In fact I believe that in its current form it will create an interoperability problem and hence it lowers its chance to be implemented by a huge range of registrars. It is not a problem for registries of course because on server side it is just the matter of creating some new nodes at some location in the frame. But a registrar has to handle many different EPP servers, some will have implemented this extension, some not. And hence why it does create an interoperability problem? Because: 1) if this extension is not explicitely announced at greeting time by the server (something you seem to be very much against) JG - How does announcing something in the greeting help out here, which at most would be a single namespace? By including a namespace in the greeting, what is expected if the client does not include that namespace in the login services? This represents a chicken and egg situation. The namespace does not define exactly which extensions and for what type of responses the server will apply draft-gould-casanova-regext-unhandled-namespaces to. That is why the policy of the implementation of draft-gould-casanova-regext-unhandled-namespaces is best suited in a policy extension of the Registry Mapping, where policy information can be made much clearer. We discussed creating an extension to communicate the unhandled namespaces issue at the REGEXT meeting, which was quickly eliminated because of the chicken and egg situation. There is a further issue that the BCP of draft-gould-casanova-regext-unhandled-namespaces does not fit any type of existing EPP extension (object, command / response, protocol) that would be communicated in the greeting. I don't believe the EPP greeting should be used to communicate a BCP or a policy. 2) and if you continue to use extValue/value + reason, the latter being for human consumption but you add a format in it with a SHOULD and opening problem with the lang attribute JG - Why is providing a recommended formatted human readable reason in the draft considered an interoperability problem? Having a consistent reason for the inclusion of the <extValue> element will provide clarity and should help with interoperability. If the lang attribute is causing concern, text can be added to also recommend using the default "lang" attribute value of "en". Since the draft has this defined as a SHOULD, a server implementer can choose to use a different reason in a different language. 3) THEN a client (registrar) CAN NOT depend on the reason content to find out about the namespace concerned (because the reason content is only a SHOULD and the specification does not deal with a lang different than "en" ... all points showing again that you should not abuse a human targeted field to put machine readable data in it) so it can instead just parse the content of <value> and take the first namespace it sees there BUT it has no idea if the content of <value> is something coming from your extension or something completely different (coming from the initial definition of <value> in RFC5730) so it will need to use heuristics instead of relying on determinism, or just drop all of it and not caring at all. JG - This reason is meant by RFC 5730 and by draft-gould-casanova-regext-unhandled-namespaces to be human readable and is not meant in any way for a software client to parse it and depend on it. There is absolutely nothing wrong with recommending a more consistent and more human readable reason in the draft. It is important for a client to understand if what comes back in value/extValue is due to what it has sent (original description of the fields in RFC 5730) or something completely different as in your extension. In its current form your extension leaves no way for a registrar to know without doubt in which case it is. I think that creating this interoperability problem just adds one more problem on top of the problem of handling unknown namespaces. Hence I will not be in favor of this extension going forward in its current shape. JG - I don't view the points that you raised as interoperability problems as noted above. I hope that I can change your mind in the future, since many options have been considered to address the unhandled namespace issue, and the approach in draft-gould-casanova-regext-unhandled-namespaces is the best of the options in my opinion. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
