Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Mario Loffredo]

Hi Andy,

could it work for you and Scott if I changed the text in Section 12.2.1 
as in the following ?


OLD

   Creators of either new RDAP reverse searches or new mappings for
   registered reverse searches SHOULD NOT replicate functionality
   already available by way of other documents referenced in these
   registries.

NEW

   Creators of either new RDAP reverse searches or new mappings for
   registered reverse searches SHOULD NOT replicate functionality
   already available by way of other documents referenced in these
   registries. Likewise, they SHOULD NOT map a registered reverse search 
property
   to a response field with a meaning other than that of the response fields
   referenced by the mappings already registered for that property.
   In other words, all the mappings for a reverse search property MUST
   point to response fields with the same meaning.
  


Best,
Mario

Il 16/08/2023 17:17, Andrew Newton ha scritto:

Thanks Mario. I understand the intent and had assumed that multiple
mappings were allowed.

While Scott and I understand, do we feel that future DE's might need
better guidance? Is the term "collisions" clear enough for a future DE
that may not have the benefit of having read this email thread?

-andy

On Mon, Aug 14, 2023 at 3:34 AM Mario Loffredo
  wrote:

Hi Andy,

please find my comments inline.

Il 11/08/2023 14:16, Andrew Newton ha scritto:

I wish I had asked this during the WG discussion, but I do have a question.

Section 12.2.1 paragraph 3 states:

"The designated expert should prevent collisions and confirm that
suitable documentation, as described in Section 4.6 of [RFC8126], is
available to ensure interoperability. References are not limited only
to RFCs and simple definitions could be described in the registries
themselves."

Does this mean that no duplicates in the RDAP Reverse Search Mapping
(section 12.2.4) are allowed?

[ML] What do you mean with "duplicates" ?

Under the conditions of sections 12.2.3.1. and 12.2.4.1. about the
uniqueness of the registries entries , duplicated entries are clearly
not possible.

Instead it's allowed that a single reverse property maps to more than
one response fields.

In this case one entry in the "Reverse Search" registry will split into
more entries in the "Reverse Search Mapping" registry depending on the
varipus values of the "Property Path" field.

The classical example is the "fn" reverse search property that maps to
multiple response fields based on the given contact format. But each of
those response fields has the same meaning namely the contact full name.

The term "collisions" is used in that sentence to refer to the case
where the DEs receive two registration requests for the same reverse
search property that maps to two response fields having different meaning.

It's unliely to happen but we can't exclude it.


If this is the case, that means a reverse search of "fn" will only
apply to jCard and cannot be applied to JSContact or SimpleContact
since the registration for "fn" is jCard specific. Is this
intentional?

[ML] As pointed out above, the "fn" reverse search property will also
apply  to other contact representations as the value of the "Property
Path" field will be different according to the contact representation used.

The name of the reverse search property is just a conventional name that
doesn't need to exactly match that of the response field it maps to. For
example, "fn" can map to the jCard "fn" as well as to the property
representing the contact full name in any other contact representation.
The same goes for "email".

The name "fn" has been used for compatibility with the corresponding
query parameter defined in RFC 9082 to search for entities.


I see this in section 5:

"Documents that deprecate or restructure RDAP responses such that a
registered reverse search is no longer able to be used MUST either
note that the relevant reverse search is no longer available (in the
case of deprecation) or describe how to continue supporting the
relevant search by adding another mapping for the reverse search
property (in the case of restructuring)."

It implies that duplicates are allowed, at least to me.

[ML]  See my previous comments.


Mario


-andy

On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT
   wrote:

Dear Andy and Scott (cc: regext WG),

As the designated experts for the RDAP Extensions registry, can you review the 
proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us? 
Please see:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

The due date is August 24th.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

https://www.iana.org/assignments/rdap-extensions/

Unless you ask us to wait for the other reviewer, we’ll act on the first 
response we receive.

With thanks,

David Dong
IANA Services Sr. Specialist

___
regext mailing list
regext@ietf.org
https

Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Andrew Newton]

On Thu, Aug 17, 2023 at 4:43 AM Mario Loffredo
 wrote:
>
> Hi Andy,
>
> could it work for you and Scott if I changed the text in Section 12.2.1 as in 
> the following ?
>
> OLD
>
>Creators of either new RDAP reverse searches or new mappings for
>registered reverse searches SHOULD NOT replicate functionality
>already available by way of other documents referenced in these
>registries.
>
> NEW
>
>Creators of either new RDAP reverse searches or new mappings for
>registered reverse searches SHOULD NOT replicate functionality
>already available by way of other documents referenced in these
>registries. Likewise, they SHOULD NOT map a registered reverse search 
> property
>to a response field with a meaning other than that of the response fields
>referenced by the mappings already registered for that property.
>In other words, all the mappings for a reverse search property MUST
>point to response fields with the same meaning.

Could I offer a slight modification?

NEW

Creators of either new RDAP reverse searches or new mappings for
registered reverse searches SHOULD NOT replicate functionality
already available by way of other documents referenced in these
registries. Creators MAY register additional reverse search mappings for
existing properties, but they SHOULD NOT map a registered reverse
search property
to a response field with a meaning other than that of the response fields
referenced by the mappings already registered for that property.
In other words, all the mappings for a reverse search property MUST
point to response fields with the same meaning.

-andy

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Mario Loffredo]

Il 17/08/2023 13:19, Andrew Newton ha scritto:

On Thu, Aug 17, 2023 at 4:43 AM Mario Loffredo
 wrote:

Hi Andy,

could it work for you and Scott if I changed the text in Section 12.2.1 as in 
the following ?

OLD

Creators of either new RDAP reverse searches or new mappings for
registered reverse searches SHOULD NOT replicate functionality
already available by way of other documents referenced in these
registries.

NEW

Creators of either new RDAP reverse searches or new mappings for
registered reverse searches SHOULD NOT replicate functionality
already available by way of other documents referenced in these
registries. Likewise, they SHOULD NOT map a registered reverse search 
property
to a response field with a meaning other than that of the response fields
referenced by the mappings already registered for that property.
In other words, all the mappings for a reverse search property MUST
point to response fields with the same meaning.

Could I offer a slight modification?


Of course, no problem.

I'll added it to the new version.


Thanks,

Mario



NEW

 Creators of either new RDAP reverse searches or new mappings for
 registered reverse searches SHOULD NOT replicate functionality
 already available by way of other documents referenced in these
 registries. Creators MAY register additional reverse search mappings for
 existing properties, but they SHOULD NOT map a registered reverse
search property
 to a response field with a meaning other than that of the response fields
 referenced by the mappings already registered for that property.
 In other words, all the mappings for a reverse search property MUST
 point to response fields with the same meaning.

-andy


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Mario Loffredo]

Il 17/08/2023 13:19, Andrew Newton ha scritto:

On Thu, Aug 17, 2023 at 4:43 AM Mario Loffredo
 wrote:

Hi Andy,

could it work for you and Scott if I changed the text in Section 12.2.1 as in 
the following ?

OLD

 Creators of either new RDAP reverse searches or new mappings for
 registered reverse searches SHOULD NOT replicate functionality
 already available by way of other documents referenced in these
 registries.

NEW

 Creators of either new RDAP reverse searches or new mappings for
 registered reverse searches SHOULD NOT replicate functionality
 already available by way of other documents referenced in these
 registries. Likewise, they SHOULD NOT map a registered reverse search 
property
 to a response field with a meaning other than that of the response fields
 referenced by the mappings already registered for that property.
 In other words, all the mappings for a reverse search property MUST
 point to response fields with the same meaning.

Could I offer a slight modification?


Of course, no problem.

I'll added it to the new version.


Thanks,

Mario


NEW

  Creators of either new RDAP reverse searches or new mappings for
  registered reverse searches SHOULD NOT replicate functionality
  already available by way of other documents referenced in these
  registries. Creators MAY register additional reverse search mappings for
  existing properties, but they SHOULD NOT map a registered reverse
search property
  to a response field with a meaning other than that of the response fields
  referenced by the mappings already registered for that property.
  In other words, all the mappings for a reverse search property MUST
  point to response fields with the same meaning.

-andy


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] I-D Action: draft-ietf-regext-rdap-reverse-search-24.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Registration Protocols
Extensions (REGEXT) WG of the IETF.

   Title   : Registration Data Access Protocol (RDAP) Reverse Search
   Authors : Mario Loffredo
 Maurizio Martinelli
   Filename: draft-ietf-regext-rdap-reverse-search-24.txt
   Pages   : 23
   Date: 2023-08-17

Abstract:
   The Registration Data Access Protocol (RDAP) does not include query
   capabilities for finding the list of domains related to a set of
   entities matching a given search pattern.  Considering that an RDAP
   entity can be associated with any defined object class and other
   relationships between RDAP object classes exist, a reverse search can
   be applied to other use cases besides the classic domain-entity
   scenario.  This document describes an RDAP extension that allows
   servers to provide a reverse search feature based on the relationship
   defined in RDAP between an object class for search and any related
   object class.  The reverse search based on the domain-entity
   relationship is treated as a particular case.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-24

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-24

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-24.txt

[Mario Loffredo]

Just published version -24 that addresses the feedback from Andy and 
Scott as DEs.


Best,

Mario



 Messaggio Inoltrato 
Oggetto: 	New Version Notification for 
draft-ietf-regext-rdap-reverse-search-24.txt

Data:   Thu, 17 Aug 2023 06:46:06 -0700
Mittente:   internet-dra...@ietf.org
A: 	Mario Loffredo , Maurizio Martinelli 






A new version of I-D, draft-ietf-regext-rdap-reverse-search-24.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-ietf-regext-rdap-reverse-search
Revision: 24
Title: Registration Data Access Protocol (RDAP) Reverse Search
Document date: 2023-08-17
Group: regext
Pages: 23
URL: 
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-24.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-reverse-search-24


Abstract:
The Registration Data Access Protocol (RDAP) does not include query
capabilities for finding the list of domains related to a set of
entities matching a given search pattern. Considering that an RDAP
entity can be associated with any defined object class and other
relationships between RDAP object classes exist, a reverse search can
be applied to other use cases besides the classic domain-entity
scenario. This document describes an RDAP extension that allows
servers to provide a reverse search feature based on the relationship
defined in RDAP between an object class for search and any related
object class. The reverse search based on the domain-entity
relationship is treated as a particular case.



The IETF Secretariat

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [IANA #1278515] expert review for draft-ietf-regext-rdap-reverse-search (rdap-extensions)

[Andrew Newton]

David,

The IANA registrations as listed in
draft-ietf-regext-rdap-reverse-search-24 look good to me.

-andy

On Thu, Aug 10, 2023 at 6:41 PM David Dong via RT
 wrote:
>
> Dear Andy and Scott (cc: regext WG),
>
> As the designated experts for the RDAP Extensions registry, can you review 
> the proposed registration in draft-ietf-regext-rdap-reverse-search-23 for us? 
> Please see:
>
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/
>
> The due date is August 24th.
>
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
>
> https://www.iana.org/assignments/rdap-extensions/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the first 
> response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Murray S. Kucherawy]

On Wed, Aug 16, 2023 at 6:48 AM Hollenbeck, Scott 
wrote:

> *From:* Murray S. Kucherawy 
> *Sent:* Monday, August 14, 2023 6:23 PM
> *To:* Hollenbeck, Scott 
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication has been requested for
> draft-ietf-regext-rdap-openid-23
>
>
>
> *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.
>
> Hey Scott,
>
>
>
>
>
> On Mon, Aug 14, 2023 at 5:54 AM Hollenbeck, Scott <
> shollenb...@verisign.com> wrote:
>
> Thanks for the review, Murray. Notes below.
>
>
>
> Scott
>
>
>
> *From:* regext  *On Behalf Of *Murray S.
> Kucherawy
> *Sent:* Saturday, August 12, 2023 7:58 PM
> *To:* regext@ietf.org
> *Cc:* AlBanna, Zaid ; regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication has been requested for
> draft-ietf-regext-rdap-openid-23
>
>
>
> *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.
>
> AD review:
>
>
>
> I note that the shepherd writeup's last question points out the creation
> of a registry using Specification Required rules, and thus doesn't need a
> designated expert, referencing RFC 8126 Section 4.6.  However, that section
> of that RFC says:
>
>
>
>This policy is the same as Expert Review, with the additional
>
>requirement of a formal public specification.  In addition to the
>
>normal review of such a request, the designated expert will review
>
>the public specification and evaluate whether it is sufficiently
>
>stable and permanent, and sufficiently clear and technically sound to
>
>allow interoperable implementations.
>
>
>
> So yes, we do need to appoint designated expert(s) and this document needs
> to include any advice that they should have when reviewing specifications.
> Such advice is missing here.  Do you want to add any?
>
> *[SAH] Yes, that’s my mistake, confusing “specification required” with
> “RFC required”. I need to add text that instructs the expert to review
> specifications to ensure that any request to register a value meets the
> requirements described in Section 3.1.5.1.*
>
>
>
> "Revised I-D Needed".  :-)
>
>
>
>
>
> I also note from the writeup that you attempted to get OAUTH WG input but
> were not successful.  I will raise this to the SEC ADs and ask them for
> advice as soon as I've sent this.  For that matter, you might want to
> trigger an early SECDIR review, although there's going to be one as part of
> Last Call anyway.
>
>
>
> In Section 3.1.2, what is a "given period of interaction"?
>
> *[SAH] The intention here is to use encourage clients to use one form of
> interaction or the other consistently in the course of sending RDAP queries
> and receiving RDAP responses over a given period of time. For example,
> don’t mix in token-oriented actions while in the middle of a
> session-oriented interaction.*
>
>
>
> OK, I thought you might have actually been trying to say "session".  But
> the same text could legitimately mean, say, "month", or "before an
> unspecified timeout expires"; in the latter case, I'd be wondering what
> timeout you mean.
>
> *[SAH] Yes, I was trying to say “session” without using that word because
> token-oriented clients don’t establish sessions in the way the term is used
> in the document. On the other hand, would it be clearer to say something
> like “within an exchange of requests and responses over a period of time”?*
>

What's the advice to an implementer of token-oriented clients?  It feels
like we're trying to describe a time boundary beyond which you can
establish a new pattern.  What might that be for non-session situations?
It's fine if there's no good answer, but I wanted to tease out any
opportunity to be more crisp here.


>
>
>
> In Section 3.1.3, bullet 1, "OpenID OpenID Providers".
>
> *[SAH] Will fix.*
>
>
>
> In Section 3.1.3, bullet 1, why is that only a SHOULD?  Why might I not do
> this?
>
> *[SAH] A client might have received that information from some other
> source, such as published documentation provided by a server operator, and
> it may hard-code certain preferences. The SHOULD exists to encourage
> dynamic processing of the returned information, but it’s not an absolute
> requirement.*
>
>
>
> So this isn't an interoperability requirement?
>
>
>
> I suggest making it clear why I might implement something deviating from
> this advice, and why that's okay.
>
> *[SAH] How about this: “If one or more remote OpenID Providers are
> supported, the RDAP client SHOULD evaluate the additional information
> described in Section 4.1 in order to discover the capabilities of the RDAP
> server and optionally obtain the set of supported OPs unless that
> information is available from a trusted out-of-band source and has already
> been processed.”*
>

Perfect.

Re: [regext] Proposed update to draft-ietf-regext-epp-eai

[James Galvin]

Responding only to this one issue:

Now acting in your role as chair, how do we establish consensus now 
that you as an individual don’t support the working group consensus?


Thank you for the question.

As co-Chair, I completely support the working group consensus.  I have 
demonstrated this by agreeing with our co-Chair on the prior consensus 
call and acting on that consensus by submitting the document to the IESG 
for publication.


What I didn’t and don’t support is the technical choice made by the 
working group; I was clearly in the minority in the working group then, 
and probably now.  What I’m doing at this time is being more explicit 
about my opinion given the response from our Area Director regarding the 
content of this document.


As I understand the position of our Area Director, he is questioning the 
technical choice of the working group.  What he is asking for is either 
an explicit explanation for why this working group is making the choice 
it’s making, if we are not open to making an alternate choice.


So, I’m taking this opportunity to speak out more “loudly” 
regarding an alternate position.


Antoin and I will be considering working group consensus together, and I 
will certainly be deferential to his point of view on consensus since 
I’m participating in this discussion.


Of course, if you have a concern please do let me know.  Your co-Chair 
and Area Director are also available to discuss any concerns you may 
have if you (or anyone) are not comfortable discussing them with me 
directly.


Thanks,

Jim



On 27 Jul 2023, at 23:31, Gould, James wrote:


Jim,

It’s too bad that you didn’t weigh in when I requested for 
opinions with the mailing list thread 
https://mailarchive.ietf.org/arch/msg/regext/V5znHXurkApuTJaL_GOyQUYMddw/ 
in March.  For SMTPUTF8 to be used, there must be a policy decision 
made by all three R’s (Registry, Registrar, and Registrant), so 
there is no concept of being “out of luck”.  When it’s 
implemented, there are multiple alternate forms of communication 
(postal address, voice, and fax) that can be used for insurance.  Your 
proposal will require having a permanent ASCII alternate email, since 
draft -17 received negative feedback related to having a transition 
period.  If an ASCII email is always required, SMTPUTF8 email 
addresses will never be used as first-class citizens in EPP.  Do you 
see the need for an ASCII email as a permanent requirement?


You stated, “If we’re going to stand firm on the current working 
group consensus, then I believe the question to be answered is why EPP 
is special and shouldn’t be required to align with accepted 
practice?”  What accepted practice are you referring to?
Now acting in your role as chair, how do we establish consensus now 
that you as an individual don’t support the working group consensus?


Thanks,

--

JG

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

James Gould
Fellow Engineer
jgo...@verisign.com

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

Verisign.com

From: James Galvin 
Date: Thursday, July 27, 2023 at 7:05 PM
To: James Gould 
Cc: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Proposed update to 
draft-ietf-regext-epp-eai



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 an individual, I don’t believe this responds to the 
issue at hand.


I understand this to be suggesting that EPP is telling the world that 
a registrant is welcome to use an SMTPUTF8 email address and the rest 
of the world is out of luck if you can’t handle that email address. 
Well, in fairness, what the text says is if you can’t use email, for 
whatever reason, then try some other method of contact.


If I’m wrong about that then the rest of this message won’t make 
sense and you can stop reading here.



Assuming that’s correct, my problem with that is it doesn’t align 
with the principles of the email standards and practices according to 
the IETF.


If we’re going to stand firm on the current working group consensus, 
then I believe the question to be answered is why EPP is special and 
shouldn’t be required to align with accepted practice?


Suggesting that if email doesn’t work an Internet user trying to 
contact a registrant should just use something else just doesn’t 
pass the “sniff test” for me. EPP is dictating to registrants 
their options and, in particular, telling anybody who wants to use EPP 
for their registration system they should *not* use an SMTPUTF8 email 
address if you actually want to be contacted until the entire Internet 
has converted to making SMTPUTF8 the default.



Coming at this from a different direction, speaking as a registry 
operator, I want my registrants to be able to have service regardless 
of the circumstances. I won’t always require an alternate email 
address, but for those registrants that want it I want to make su

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Hollenbeck, Scott]

From: Murray S. Kucherawy 
Sent: Thursday, August 17, 2023 11:56 AM
To: Hollenbeck, Scott 
Cc: regext@ietf.org; AlBanna, Zaid ; 
regext-cha...@ietf.org
Subject: [EXTERNAL] Re: [regext] Publication has been requested for 
draft-ietf-regext-rdap-openid-23



[SAH] [snip]

 In Section 3.1.2, what is a "given period of interaction"?

[SAH] The intention here is to use encourage clients to use one form of 
interaction or the other consistently in the course of sending RDAP queries 
and receiving RDAP responses over a given period of time. For example, don’t 
mix in token-oriented actions while in the middle of a session-oriented 
interaction.



OK, I thought you might have actually been trying to say "session".  But the 
same text could legitimately mean, say, "month", or "before an unspecified 
timeout expires"; in the latter case, I'd be wondering what timeout you mean.

[SAH] Yes, I was trying to say “session” without using that word because 
token-oriented clients don’t establish sessions in the way the term is used in 
the document. On the other hand, would it be clearer to say something like 
“within an exchange of requests and responses over a period of time”?



What's the advice to an implementer of token-oriented clients?  It feels like 
we're trying to describe a time boundary beyond which you can establish a new 
pattern.  What might that be for non-session situations?  It's fine if there's 
no good answer, but I wanted to tease out any opportunity to be more crisp 
here.

[SAH] What I’m trying to say here is that a client shouldn’t mix 
token-oriented requests in between session-oriented login and logout requests. 
Maybe that’s the best way to say it: “Clients MAY operate as either 
session-oriented or token-oriented clients, but they MUST do so consistently 
by not mixing token-oriented and session-oriented requests while interacting 
with an OP.” Does that work?





[SAH] [snip]







In Section 3.1.4.1, same question.

[SAH] This SHOULD exists because other methods exist to discover the provider. 
The server might not support the query parameter because it can determine the 
issuer from the given credential (Gmail maps to Google, for example), or it 
may only support a single identity provider.



But if I use one of those other methods, is there any degradation to 
interoperability or security?

[SAH] Not that we’re aware of. At least one implementer has confirmed that it’s 
more common not explicitly receive anything that identifies the provider. The 
alternatives are described in 3.1.4.



OK so this seems like a good candidate for another SHOULD-unless construction 
as you did above.  Thanks for clarifying.

[SAH] OK, how about this: “Alternatively, if mapping of an End-User's 
identifier is not possible, or not supported by the RDAP server, the RDAP 
server SHOULD support explicit specification of a remote OP by the RDAP client 
in the form of a query parameter as described in Section 5.2.2 unless the 
remote OP has been identified using an out-of-band mechanism.”?







In Section 5.1.1, the entire object is OPTIONAL.  This doesn't seem right. 
Would there be any practical use to such a thing?

[SAH] A token-oriented client won’t ever establish a session.



Does that mean at least one of the object's attributes will always be set?  If 
so, a MUST at the bottom indicating such would tighten this up (e.g., "X is 
OPTIONAL, Y is OPTIONAL, Z is OPTIONAL, but you MUST set at least one of 
them").

[SAH] Mario helpfully reminded me that Section 5.2.3 describes the objects to 
be returned in a response based on success or failure. How about adding this 
to 5.1.1 right before the example: “Note that all of the members of the 
"farv1_session" data structure are OPTIONAL. See Section 5.2.3 for 
instructions describing when to return the minimum set of members.”



Thanks, I hadn't connected the two.  So the normative prose around this does 
indeed say an empty object is syntactically legal, but 5.2.3 provides guidance 
that it should really never happen.  Do we need to protect consumers against 
the possibility of a syntactically valid but semantically nonsense empty reply 
by giving them guidance about how to handle such a thing?  I'm fine if the 
answer is "no", but I wanted to ask the question.

[SAH] I think we’re safe with not saying any more that’s already in RDAP 
itself: if a client sees something it doesn’t expect, it can safely be 
ignored.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Publication has been requested for draft-ietf-regext-rdap-openid-23

[Murray S. Kucherawy]

On Thu, Aug 17, 2023 at 12:56 PM Hollenbeck, Scott 
wrote:

> *From:* Murray S. Kucherawy 
> *Sent:* Thursday, August 17, 2023 11:56 AM
> *To:* Hollenbeck, Scott 
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication has been requested for
> draft-ietf-regext-rdap-openid-23
>
>
>
> *[SAH] [snip]*
>
>  In Section 3.1.2, what is a "given period of interaction"?
>
> *[SAH] The intention here is to use encourage clients to use one form of
> interaction or the other consistently in the course of sending RDAP queries
> and receiving RDAP responses over a given period of time. For example,
> don’t mix in token-oriented actions while in the middle of a
> session-oriented interaction.*
>
>
>
> OK, I thought you might have actually been trying to say "session".  But
> the same text could legitimately mean, say, "month", or "before an
> unspecified timeout expires"; in the latter case, I'd be wondering what
> timeout you mean.
>
> *[SAH] Yes, I was trying to say “session” without using that word because
> token-oriented clients don’t establish sessions in the way the term is used
> in the document. On the other hand, would it be clearer to say something
> like “within an exchange of requests and responses over a period of time”?*
>
>
>
> What's the advice to an implementer of token-oriented clients?  It feels
> like we're trying to describe a time boundary beyond which you can
> establish a new pattern.  What might that be for non-session situations?
> It's fine if there's no good answer, but I wanted to tease out any
> opportunity to be more crisp here.
>
> *[SAH] What I’m trying to say here is that a client shouldn’t mix
> token-oriented requests in between session-oriented login and logout
> requests. Maybe that’s the best way to say it: “Clients MAY operate as
> either session-oriented or token-oriented clients, but they MUST do so
> consistently by not mixing token-oriented and session-oriented requests
> while interacting with an OP.” Does that work?*
>

That seems way better to me.


>
>
>
>
> *[SAH] [snip]*
>
>
>
>
>
>
>
> In Section 3.1.4.1, same question.
>
> *[SAH] This SHOULD exists because other methods exist to discover the
> provider. The server might not support the query parameter because it can
> determine the issuer from the given credential (Gmail maps to Google, for
> example), or it may only support a single identity provider.*
>
>
>
> But if I use one of those other methods, is there any degradation to
> interoperability or security?
>
> *[SAH] Not that we’re aware of. At least one implementer has confirmed
> that it’s more common not explicitly receive anything that identifies the
> provider. The alternatives are described in 3.1.4.*
>
>
>
> OK so this seems like a good candidate for another SHOULD-unless
> construction as you did above.  Thanks for clarifying.
>
> *[SAH] OK, how about this: “Alternatively, if mapping of an End-User's
> identifier is not possible, or not supported by the RDAP server, the RDAP
> server SHOULD support explicit specification of a remote OP by the RDAP
> client in the form of a query parameter as described in Section 5.2.2
> unless the remote OP has been identified using an out-of-band mechanism.”?*
>

Works for me.


>
>
>
>
>
>
> In Section 5.1.1, the entire object is OPTIONAL.  This doesn't seem
> right.  Would there be any practical use to such a thing?
>
> *[SAH] A token-oriented client won’t ever establish a session.*
>
>
>
> Does that mean at least one of the object's attributes will always be
> set?  If so, a MUST at the bottom indicating such would tighten this up
> (e.g., "X is OPTIONAL, Y is OPTIONAL, Z is OPTIONAL, but you MUST set at
> least one of them").
>
> *[SAH] Mario helpfully reminded me that Section 5.2.3 describes the
> objects to be returned in a response based on success or failure. How about
> adding this to 5.1.1 right before the example: “Note that all of the
> members of the "farv1_session" data structure are OPTIONAL. See Section
> 5.2.3 for instructions describing when to return the minimum set of
> members.”*
>
>
>
> Thanks, I hadn't connected the two.  So the normative prose around this
> does indeed say an empty object is syntactically legal, but 5.2.3 provides
> guidance that it should really never happen.  Do we need to protect
> consumers against the possibility of a syntactically valid but semantically
> nonsense empty reply by giving them guidance about how to handle such a
> thing?  I'm fine if the answer is "no", but I wanted to ask the question.
>
> *[SAH] I think we’re safe with not saying any more that’s already in RDAP
> itself: if a client sees something it doesn’t expect, it can safely be
> ignored.*
>

Sounds good.  Thanks for working through all this with me.  I'll send this
to Last Call when the new version goes up.

-MSK
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext