James, On Mon, Oct 19, 2020, at 08:31, Gould, James wrote: > 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".
You are misreading me or misquoting me. What your draft forces on is the use of extValue as NOT described by RFC 5730 hence putting all current clients at risk, because you "silently" change some core expectations of RFCs 5730+. I know the problem you are trying to address (I even think I was one of the people raising it in the first place but note that in 20 years or more that EPP exists, it obviously did not move people so much even if it is a real problem), I am just trying to explain that this draft creates an interoperability problem by just changing the semantics of RFC 5730 without letting clients decide if they want it or not, they are forced by the server, hence this default opt-in migration of the current park of EPP clients will create problems. > This is not a new feature from a protocol > perspective that will cause an interoperability issue. It is, because extValue is defined as containing *client* data that created an error, and you are stuffing it with *server* data. Plus the return code of 1000 + extValue case that I tried to explain, which doesn't seem to me really covered by existing RFCs, so you are just redefining things, hoping that all clients immediately will just implement your draft and hence everything is fine but unfortunately that is not what is going to happen... Maybe all of this is fine, redesigning EPP from scratch today, I could agree with all this. But I am just pointing out that specifications already exist and are NOT aligned with the way you try to use them in this draft. This is the interoperability problem, not the features themselves, the fact that you add them on top of things where they do not fit 100%. > 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. I believe there is and I quoted you so. Note the mention of "client-provided element", but you seem to just ignore that point. A specification can not list everything prohibited. It lists what is allowed (and it says clearly "client-provided element") and then as a safe view you can expect the rest not to be allowed. > 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. Which is the core of the problem and the interoperability risk. You redefine core parts of RFC 5730 without taking into accounts that clients may not be aware of your change (your draft) and hence will have problems if the server forces that new view on them, without any possible negotiation. At this point it seems we are just repeating our own arguments on both side, so I don't think either will move their position and we have to keep our disagreement, which is fine. I wanted to record my disagreement on this draft during WGLC, that is all. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
