Hello, Back in July I sent group of emails with details seen in the wild that may need to be in the extension, or not. I am only responding to this one about the form in fact and not the content, because I was kind of surprised by various points in the replies I got like:
> How many registries do this (many, some, few, or just one)? This is the first time I see a count of registries being asked to finally decide how to implement something or not. In fact recent cases show that we did exactly the opposite: for the fee extension and the very late inclusion of the standard attribute, if we summarize things we had - one registrar asking for it but not really promoting it nor participating on discussions - 2 registries saying basically "it is optional, we will not use it, so we are neutral to it" - one client side implementor (me) and one registry saying: this lacks a true purpose and is dangerous for interoperability. Result: it passed, the attribute was added! Based on that, I do not see why now we should dictate what goes in or not based on how it is used in the wild. I think you have basically three options: - encode only exactly what core EPP documents allow - try to filter things and define those used often enough to warrant being included from those used by only "1" registry that are put aside and would need an extension - put everything in. We are not doing 1) because last time I read the specification there are things in it that are clearly not in EPP core documents (like "custom" contact types). We seem to be trying to do 2) which is very dangerous because it leads to questions like above and if you match that by the very low amount of exchanges on this list, I really fail to see how we can make sure to take the proper decisions as a group. And of course, by "extension" 3) would be as well difficult to reach. But at least my position is basicall a 2) without treating some cases as second class citizen just because they are rare or further away from "pure" EPP. Of course it would help if each registry participated and were champions for their own cases but obviously we are not there nor will we be in a short future. Or otherwise we really do 1) but then multiple things will need to be removed (custome contact types, privacy/proxy, etc. I listed some in my previous emails). So, I do not think it is useful for this working group that I reply extensively on each point, where I mostly detailed what is happening in the wild currently, that we may like or dislike on an engineer level, but then the question I think is really how much we want this "registry policy" extension to be implemented by many registries, and not by the ones closer to "standard" EPP. Even if I may not have phrased things good enough, I hope the above will have succeeded in trying to raise awareness about the so many different cases in the wild and the need to try to "accomodate" if we want success both in term of numbers of implementations and avoiding fragmentations (where multiple extensions exist to do exactly the same thing in fact). -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
