> -----Original Message----- > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Sent: Tuesday, January 24, 2023 9:57 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; jbern...@cofomo.com; > regext@ietf.org > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid- > 20.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 Scott, > > Il 18/01/2023 17:17, Hollenbeck, Scott ha scritto: > >> -----Original Message----- > >> From: Julien Bernard<jbern...@cofomo.com> > >> Sent: Wednesday, January 18, 2023 11:05 AM > >> To: Hollenbeck, Scott<shollenb...@verisign.com>;regext@ietf.org > >> Subject: [EXTERNAL] Re: [regext] I-D Action: > >> draft-ietf-regext-rdap-openid- 20.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. > >> > >> Thanks Scott. My answers inline. > >> > >> On 18/01/2023 09:24, Hollenbeck, Scott wrote: > >>> Thanks for the feedback and questions, Julien. More below. > >>> > >>>> -----Original Message----- > >>>> From: Julien Bernard<jbern...@cofomo.com> > >>>> Sent: Monday, January 16, 2023 2:33 PM > >>>> To: Hollenbeck, Scott<shollenb...@verisign.com>;regext@ietf.org > >>>> Subject: [EXTERNAL] Re: [regext] I-D Action: > >>>> draft-ietf-regext-rdap-openid- 20.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 Scott, > >>>> > >>>> I read the full draft recently and I have a couple of comments > >>>> related to -20 and older versions as well. Sorry if those have > >>>> already been discussed previously on the mailing list. > >>>> > >>>> - section 3.1.2: "Servers MUST support both types of client." > >>>> Is there a reason for this to be a MUST? I think it could prevent > >>>> people from implementing the spec (or a part of it) as this is a > >>>> pretty huge requirement. > >>> [SAH] That requirement is based on the robustness principle, aka > >>> Postel's > >> Law: > >>> https://secure- > >> web.cisco.com/1yZtJRmWuxFVBrupACQRNwf8lBoBQmKUYJblANZa5 > >>> l4nfFT5tunPDMNc_16e- > >> HlegBKEm8trlSL4AKVwCxCO4SZrVe72jG3K7LQdJNqUYz26IeO > >> > mrvO9R7GRjXYPt3dt1YcHaOOh1Zr2KLsQR8Ipvbd4wJk5bUnoVMfPiSdsLgFyYR_n > >> X27RT > >>> H1dD8Rdum_8IdUgRq9qth2BaNaC- > >> 5Z88xNaMiC5ubpC_IqCMNDmmet4ZaDX_D_uwwFRBcR > >>> NfQlwDNXaYTNLeGBrK4KlcTO4aDHObX23xxSGHXaWNBvLGB0- > eioedCMH6- > >> oQHO1dXVyJX > >>> /https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRobustness_principle > >>> > >>> Yes, it's more work for servers, but it makes things easier for clients. > >> [JB] I agree that the server development should follow Postel's law > >> but why not adding this as a capability in the > >> farv1_openidcConfiguration structure, so what is implemented would be > clear and won't break the principle. > >> This concern is based on feedback I got from developers, including > >> people maintaining RDAP servers. I think we may end up with partial > >> implementations without a way to be aware that only one client type is > supported. > > [SAH] I'd really like to hear what others have to say about this. A server > > that > only supports one type of client won't be accessible to some number of end > users. That doesn't sound like a good thing. > > [ML] I support Julien's proposal. > > The token-based approach will be implemented with little to no effort while > the > session-based approach will take much more time. > > IMO, separating the implementation of the two approaches would enable > implementers to easily comply with the spec. > > In addition, the token-based approach might be the only one practicable due > to > the server policy of accepting the authenticated requests from trusted > clients > only.
[SAH] Thanks for the feedback, Mario. I still don't think this is a good idea, but if mine is a minority opinion I'll update the text to remove the MUST and include config info so a server can describe the type(s) of clients it supports. Please folks, share an opinion now if you have one. Should a server be able to support one type of client only? > As an aside note, it doesn't look clear to me which RDAP features defined > for > the session-based approach are still valid in the token-based approach. I > mean, > the farv1_* endpoints seem meaningless to me while farv1_dnt and farv1_qp > parameters are still relevant. [SAH] The text was restructured in -20 in an attempt to make that clear. The query parameters are described in the "Common Protocol Features" section, so yes, they're common to both. The different endpoints are described in sections titled "Protocol Features for Session-Oriented Clients" and "Protocol Features for Token-Oriented Clients". Did I miss something such that the distinction remains unclear? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
