On Mon, Aug 2, 2021, at 08:50, Gould, James wrote: > I believe the use of a predefined placeholder value is the best > approach to handle this transition corner case in the protocol, but I > would like to hear viable alternates from the working group to > incorporate into the draft.
I think I agree with Marco and Ulrich, I was already not happy by us allowing to use a placeholder value in login-security extension, and for the exact same reason I am not in favor of using another placeholder like that, no matter what it is or where it is. Why and what seems better to me? We use XML, we use XML namespaces and we version them even. What gain do we have with that if we don't leverage it? Placeholders are just a symptom of the fact that the current schema are not aligned with our current needs. This is "normal", EPP is old now, it has to change to adapt to current real life. Being blocked in old schemas is just technical debt, that we try to "encapsulate" by now putting "dummy" (another term for placeholder) values in places where the schema does not fit our needs. This lowers the value of using a schema in the first place. Yes, introducing contact-2.0 will be a huge task, but it is to me far better and fool-proof than using placeholders. We postpone that more and more but we just delay the inevitable (which could happen to be as well someone deciding to just redo EPP basically under some current in fashion technologies, aka JSON, which goal or side effect is exactly to get rid of all schemas and specifications) or just continue to fuel the fragmentation with many extensions working around deficiencies or missing pieces that should be in "core" schemas. Yes, a change like that won't be easy or immediate. Yet, at the same time, we currently allow to have, to my count, *18* XML namespace versions of the fee EPP extension (including the final 1.0 one which is far from being the most used one currently), and again to my count necessarily not exhaustive at least 7 of them are actively used by registries. Major pains for registrars obviously, yet it shows things work when leveraging the XML schema versioning, and if we don't then we just enshrine a situation with as many EPP as they are registries, each one using their own specific extensions, which makes "core" EPP basically unusable anywhere as is. Like in all other cases, I think it could help guide the discussion, if registries and registrars would come forward telling they are interested to implement this discussed extension or if they do not, why? That would allow to make sure the extension is designed to cover as many similar cases as possible, to lower risks of fragmentation. Also all of this is obviously related to Universal Acceptance, and at least in gTLD world, ICANN has a specific team/workgroup on that subject. -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
