Speaking as a working group participant:
Good point. So are you suggesting that we should do something similar
in the EAI document?
I’m not opposed to doing this if others agree it would be worthwhile.
I’m still on the side of doing “nothing”, but I won’t object if
this suggestion gets support.
Jim
On 2 Dec 2024, at 9:23, Gould, James wrote:
Servers have the option to support unsupported clients already with
the implementation of the Unhandled Namespaces RFC 9038 that I don’t
believe needs to be covered in draft-ietf-regext-epp-eai. The server
cannot return the extension as is in the info response or a poll
message to comply with EPP RFC 5730 for the non-supporting client.
The Unhandled Namespaces RFC 9038 provides the only compliant option
to return additional information. Considering the lack of contact
transfers, the server will not likely include
draft-ietf-regext-epp-eai as a use case to return additional
information to a non-supporting client.
We discussed the case of non-supporting clients in EPP with the Change
Poll Extension in RFC 8590 that led us to create the Unhandled
Namespaces RFC 9038.
--
JG
[cid87442*image001.png@01D960C5.C631DA40]
James Gould
Fellow Engineer
jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: James Galvin <gal...@elistx.com>
Date: Monday, December 2, 2024 at 8:55 AM
To: Joseph Yee <joseph....@gmail.com>
Cc: "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org>,
"a...@gulbrandsen.priv.no" <a...@gulbrandsen.priv.no>,
"regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] [regext] Re: WGLC: draft-ietf-regext-epp-eai (was:
WGLC: draft-ietf-regext-rdap-rir-search-09)
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.
Speaking as a working group participant:
Sorry to be late to this specific discussion but I agree with Arnt and
don’t believe any changes are necessary to the existing document.
At least among gTLDs, the contact objects are typically not
transferred. Combine that with the fact that a registrant has gone to
the new registrar and entered contact information directly. Thus, if
the gaining registrar does not support EAI then the registrant has not
entered that information and there is no conflict. In addition, this
would apply to all information in the contact object so the additional
email address is not special in this regard.
Since the base EPP does not make this point I don’t feel that we
should make this point in this document. It might be an interesting
comment to add to an update to EPP since it does apply generally,
although I’m not convinced of that either; I’m suggesting we talk
about it then.
Jim
On 21 Nov 2024, at 15:54, Joseph Yee wrote:
inline
On Wed, Nov 20, 2024 at 7:29 AM Hollenbeck, Scott
<shollenbeck=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>>
wrote:
-----Original Message-----
From: Arnt Gulbrandsen
<a...@gulbrandsen.priv.no<mailto:a...@gulbrandsen.priv.no>>
Sent: Monday, November 18, 2024 11:15 AM
To: regext@ietf.org<mailto:regext@ietf.org>
Subject: [EXTERNAL] [regext] Re: WGLC: draft-ietf-regext-epp-eai
(was: WGLC:
draft-ietf-regext-rdap-rir-search-09)
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.
Hollenbeck, Scott writes:
Please note that I have a comment from Joseph Yee that needs to be
addressed if there's no objection to do so.
Why does it need to be addressed?
EPP doesn't even try to tell you that a contact object will be
invalidated if the
domain is transferred, or that a contact object is referenced by
extension
objects that you can't see because you haven't declared support for
that
extension. What makes this case worth addressing?
[SAH] Give that reasoning, probably nothing. Maybe Joseph can add
more.
It's a nice-to-have reminder, and as discussed, it's a MAY for
registry to consider.. After all, this one contains an email address.
-Joseph
Scott
_______________________________________________
regext mailing list -- regext@ietf.org<mailto:regext@ietf.org>
To unsubscribe send an email to
regext-le...@ietf.org<mailto:regext-le...@ietf.org>
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
