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

[James Galvin <[e-mail]>]

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
> [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: James Galvin <[e-mail]>
> Date: Monday, December 2, 2024 at 8:55 AM
> To: Joseph Yee <[e-mail]>
> Cc: "Hollenbeck, Scott" <shollenbeck=[e-mail]>, 
> "[e-mail]" <[e-mail]>, 
> "[e-mail]" <[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]
> To unsubscribe send an email to [e-mail]