On 19.11.20 16:37, Gould, James wrote:
Klaus,
[...]
2. Implicit Replacement Based on Login Services – Inclusion of the
namespace URI in the greeting and login services indicate support
for EAI addresses implicitly. This would be treated similar to an
EPP extension with the namespace URI in the greeting and login services.
[...]
It sounds like you’re proposing the use of the second option. I believe
that inclusion in only the greeting and logic services is too course
grain, since the registry systems can support many TLDs and many EPP
objects, each with different levels of support for EAI addresses.
Option 3 would be a lighter weight method that is an object-level
indicator and option 1 would be the most explicit to indicate which
email element is replaced by use of the placeholder text with the
extension email element. The use of email addresses apply to multiple
EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension
registered in the EPP Extension Registry
(https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).
Hi James,
you are right, my proposal matches option 2. I didn't know that this was
discussed already. In respect to option 3 I really think that if EAI
support shall be specific to object types then it would be better to
release updated specifications of these objects, maybe with new URIs if
necessary. This would be my general preference, as I noted in my
previous e-mail.
Having extensions that influence the interpretation of certain elements
in objects or other extensions has the problem that it increases the
complexity over time, makes it less understandable and makes it more
difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1)
are a good counter example for how it should work. I guess that nowadays
no active EPP server or client is unable to use version 1.1, thus 1.0
support could be theoretically removed from the implementations.
Maybe one could find additional improvements to the contact object to
justify an update. For example, fixing the disclosure settings. While
their use have become questionable in the context of data protection
regulations like the GDPR anyway, they have the slight design problem
that one cannot set and remove specific disclosure settings at the same
time. Or one could consider to add a language field, which could be
helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer
related e-mails. Maybe there are other aspects with which registrars,
resellers and end users are unhappy.
Regards,
Klaus
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
