[regext] Re: WGLC: draft-ietf-regext-epp-eai (was: WGLC: draft-ietf-regext-rdap-rir-search-09)

["Gould, James" <[e-mail]>]

Jim,

My proposal is to do nothing in draft-ietf-regext-epp-eai since it’s generally handled as an option for servers in RFC 9038.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: "Hollenbeck, Scott" <[e-mail]>
Date: Monday, December 2, 2024 at 9:47 AM
To: "[e-mail]" <[e-mail]>, James Gould <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-epp-eai (was: WGLC: draft-ietf-regext-rdap-rir-search-09)

Given the options, my preference is to do nothing.

Scott

From: James Galvin <[e-mail]>
Sent: Monday, December 2, 2024 9:46 AM
To: Gould, James <[e-mail]>
Cc: [e-mail]; Hollenbeck, Scott <[e-mail]>; [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [regext] 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:

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

[cid:[e-mail]7C0BC0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://secure-web.cisco.com/1GmRLVHvq8At83b4EbKH2z3kSAG32CmjAg9lMOagggHL894H67kFIQwrTBhYdDxHai-12_UQNXJ9x1xN4dYXaPN1J1_BpFaeOzal8BW9YdiRxdp_aT5VgpOeBk9eYStojHDAZgwWDI6S4aZ5IKJdvwmryfakreAI5N_HdPwW8wtNlWQuuvCVfPp5T4LQUb67PFFxxEseh8l0ohp6Hx9TSoTXF8Qc96bN9NasY266Iji-KZ3iXbWjuU9-D1gR8_ZbZGIN7cKdmNP5T8FyqOD5F1voZcrhch64vPCTKakWX0GM/http%3A%2F%2Fverisigninc.com%2F>

From: James Galvin <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 2, 2024 at 8:55 AM
To: Joseph Yee <[e-mail]<mailto:[e-mail]>>
Cc: "Hollenbeck, Scott" <shollenbeck=[e-mail]<mailto:shollenbeck=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]>> wrote:
> -----Original Message-----
> From: Arnt Gulbrandsen <[e-mail]<mailto:[e-mail]>>
> Sent: Monday, November 18, 2024 11:15 AM
> To: [e-mail]<mailto:[e-mail]>
> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
regext mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>