inline On Mon, Oct 7, 2024 at 4:28 PM Hollenbeck, Scott <shollenb...@verisign.com> wrote:
> *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.* > > > > This is at least worth noting in the draft. I agree. Thanks Joseph > *Scott* > >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
