From: Joseph Yee <joseph....@gmail.com> Sent: Friday, October 4, 2024 9:29 AM To: regext@ietf.org Subject: [EXTERNAL] [regext] Re: I-D Action: draft-ietf-regext-epp-eai-22.txt
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi all, I read the recent (v22) EPP EAI draft and support the direction it's taking. Regarding client (registrar) who interfaces with the contact object (info or update) but doesn't signal support of the extension, has there thought of 'telling' registrar that there are additional emails not shown to them? Thinking of servers (registry) MAY send additional information through the poll queue if clients and servers support it. [SAH] Thanks for the question, Joseph. While it’s possible for an <info> response to a non-supporting client to be followed up with a queued message, what’s the real value? As currently implemented by registrars, contact objects are basically client-specific. The fact that a contact object has been extended by client A won’t really matter to client B. If client B supports the extension, they’ll see the additional email info. If client B doesn’t support the extension, they won’t see it – and it won’t matter because they can’t process the additional address anyway. If the queries happen as part of a transfer process, client B will very likely create new contact objects as part of the transfer, and the ability to support that second address will be lost because the new client doesn’t support the extension. On the other hand, there might be value in client B warning the human user that support for their second address will be lost if the transfer takes place because client B doesn’t support the extension. That may be worth doing, or at least noting in the draft. Scott
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
