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.
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)
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
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.
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.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
