Dear Patrick, On Mon, Aug 2, 2021 at 7:02 PM Patrick Mevzek <[email protected]> wrote:
> 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. > > Thanks for your letter! Let me remind you that the 1st version of the draft proposed an update to basic schemas to indicate that EAI addresses are valid. I like your proposal about redesigning the client schema, but I'd also remind that Contact is not the only object having an email attribute. The proposed solution, with all of its downsides, covers all such objects. You suggest the solution that will require explicit updating of all the objects. I wish that ICANN/Universal Acceptance people would participate in this discussion. -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
