Probably a question to chairs, what is the status of this draft and what process this draft needs to go through? Does it need another last call and/or shepherd write-up?
Thanks Joseph On Wed, Oct 9, 2024 at 2:06 PM Joseph Yee <joseph....@gmail.com> wrote: > 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
