Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response

From: Antoin Verschuren <[email-masked]>
Date: Fri, 10 Apr 2020 16:11:18 +0200

Hi all,

The chairs realised we did not formally close this Working Group Last Call yet, due to a discussion that was still going on on the mailing list.
Even though there was not an enormous diverse amount of support stated on the mailing list for this document during WGLC, we have also not received any objections.
The chairs would therefor like to formally close this WGLC now, and we will submit this document to the IESG for consideration.
We will guide the document shepherds for this document to start their work on the writeup.

Regards,

Jim and Antoin

> Op 28 feb. 2020, om 15:43 heeft Antoin Verschuren <[email-masked]> het volgende geschreven:
> 
> The following working group document is believed to be ready for submission to the IESG for publication as a standards track document:
> 
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-response/
> 
> This WG last call will end at close of business, Friday, 13 March 2020.
> 
> Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list.
> 
> The authors are still looking for a document shepherd for this document. Being a document shepherd is an awesome opportunity to get involved in the IETF process. No deep inside technical review is needed, but it is a process review that needs to be done by an individual not being one of the authors. So please volunteer by replying to this message if you want this document to move forward after WGLC. The author’s will thank you for it.
> 
> Regards,
> 
> Jim and Antoin
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 00:45:42 -0500

On Fri, Feb 28, 2020, at 09:43, Antoin Verschuren wrote:
> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
> 

I am too late, I know.

But anyway I fear that at least the "brief" case will create interoperability
problems, or at least complexity in clients because there is a risk of each
RDAP server thinking of it differently.
The "subsetting_metadata" is only a SHOULD not a MUST, so clients could
remain completely without real explanations on why "brief" for server A
is different from "brief" result for server B.

It would have been nice to provide a template for "brief", at least a SHOULD,
per objects described in the RDAP RFCs.

Specially since the document has this text:
"the
   name, as well as the list of fields for each field set, should be
   shared by most of RDAP providers."

Written like that, this is not a protocol specification, and does not even
give tools at the protocol level to enforce that.

Or, and this could be an easy solution, another draft defining rdapConformance
subsetting_brief_level_0
should define exactly what is brief and then servers are free to properly
signal if they adhere to this definition of fields or not.
There could be multiple drafts in fact for multiple definitions.

PS: the argument in A.1 about the complexity arising out of jCard can "soon"
become obsolete if draft-loffredo-regext-rdap-jcard-deprecation goes through,
so maybe some text should have addressed other non jCard cases (or explaining why
even if jCard is dropped then problems remain)

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 01:04:12 -0500

Also:
couldn't each fieldset have a list of jsonPath elements (similar to what is done in
draft-ietf-regext-rdap-sorting-and-paging)
to properly list the fields concerned?

TBH, I am not sure to understand:
- why there are multiple links elements (the example given shows only one, what would be other ones?)
- why value there is different from href (and hence why value is needed at all),
why is the current fieldSet the "context URI" of any other fieldset used for same query?

RFC8288 defines the context URI to be, for HTML serialization:
"The context of the
   link is the URI associated with the entire HTML document. "

There is no real explanation of the context for RDAP, but based on that maybe
it should be a link to the same query with fieldSet "full"?

On Mon, Apr 27, 2020, at 00:45, Patrick Mevzek wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

-- 
  Patrick Mevzek
  [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 27 Apr 2020 17:30:34 +0200

Hi Patrick,

your feedback is really welcomed. Better late than never.

My responses to your comments are included below.

> RDAP server thinking of it differently.

I published a draft version, namely 
draft-loffredo-regext-rdap-partial-response-03, including a definition 
of the "brief" field set which was based on those WHOIS response fields 
identified in RFC 7485 as mostly supported (i.e. by more than one third 
of contacted services). As you can see from the "Change Log", that 
definition was removed in draft-ietf-regext-rdap-partial-response-01 
because the WG had clearly recommended to separate the technology, 
described in the RFC, from its operational aspects, described in an RDAP 
profile.

The same feedback was recently provided by Karl Heinz Wolf and now I'm 
giving you the same answer as I gave him.

Anyway, if the WG members reconsider their position about this point, I 
will be happy to refine my old proposal or work on a new one.

> is different from "brief" result for server B.

It's not a MUST because the available field sets could be defined in a 
document published elsewhere, for example, in a specific RDAP profile.

Therefore, in my opinion, it would be recommended but not required.

> per objects described in the RDAP RFCs.
See my response above.
>     shared by most of RDAP providers."

Obviously, the field set approach is valuable if there is a wide 
consensus on both the name and the content of a possible field set. It's 
perfectly unuseful to multiply the field sets as well as

to let the same field sets have different contents.

Three possible field set names have been recommended in the document in 
order to ease interoperability. For the field sets representing the two 
extremes, namely "id" and "full", the corresponding content is evident.

For the remaining field set, the WG considered that the document wasn't 
the right place to define its content.

> There could be multiple drafts in fact for multiple definitions.

This is an interesting solution but I dont' see, at least in the case of 
"brief",  why the WG should approve to define in a separate draft what 
has been considered unsuitable in this draft :-(

> even if jCard is dropped then problems remain)

Yes, it might become but presently it isn't obsolete. Anyway, the 
reasons why the "field set" approach should be preferred  even when 
jCard will be no more supported are reported before section A.1.

So I don't think section A.1 needs to be changed.

I would like the other WG members to manifest their opinions so that I 
could change the document where appropriate.

Best,

Mario

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
#pleasestayathome

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 10:45:17 -0500

Hello Mario,

A quick follow-up that could be a closure in fact, as your answer fills
the missing points I had.

> Therefore, in my opinion, it would be recommended but not required.

I agree with all the above, in theory.
My main fear is once the draft being put into active use, I am not sure people
will bother creating other proper IETF documentation on what "brief" is,
and hence the pretty much result I see coming is multiple servers using "brief"
in completely different senses, without always to use the metadata, and hence clients
will need again to hardcode on their side assumptions per server, which is very
bad for interoperability.

> described in the RFC, from its operational aspects, described in an RDAP 

As this argument is used when wanted but not always. At the same time, we (the WG)
see no problem (but I do) to define a BCP on "secure transfers", which is certainly
just operational stuff and not protocol stuff, so sometimes we do hardcode operational
stuff in WG documents. So we should either do it always, or never, but using that
argument only in some case and not others is not something I find good process.
That is just my generic view, nothing specific to the one draft discussed in this thread.

> consensus on both the name and the content of a possible field set.

I agree, but I am not sure there is such consensus. Or even if there is here
on the mailing-list how can be sure there will be among all RDAP servers working?

> extremes, namely "id" and "full", the corresponding content is evident.

Yes, clearly my worries are about "brief". 

> has been considered unsuitable in this draft :-(

Understood. I am probably once again possibly at odd's with the WG but it is not
something unheard of already :-)
So anyway, I believe we will see problems in the future, but we will have to wait
and see them I guess.

> could change the document where appropriate.

As you said, the issue I raised was already discussed and settled so probably
no need to rehash it, I was the one being late here, I should have taken
more attention to the previous discussion, but I was not able to reserve
the time I wanted to participate in this WG lately, sorry about that.
So no need to spend energy on my late points.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 27 Apr 2020 18:46:14 +0200

Hi Patrick,

> to properly list the fields concerned?
I dropped this solution because it seemed to me conceptually valid but 
very inefficient.
> - why there are multiple links elements (the example given shows only one, what would be other ones?)
The figure is uncorrect. I missed to fix this issue in the last version. 
There are multiple field sets but each field set includes a single link 
because each field set is an alternative view of the results provided 
according to the current field set.
>     link is the URI associated with the entire HTML document. "

The use of both the "value" and the "href" JSON values is compliant to 
what is shown in RFC7483. The context is the URI of the current view of 
a resource (i.e. the collection of objects returned according to the 
current fiel set) while the target is the URI of an alternative view of 
the same resource (i.e. the collection of objects provided according 
another field set).

> it should be a link to the same query with fieldSet "full"?

I think that we need to agree about the meaning of "context" in RDAP. It 
seems to me that in RDAP the context is the JSON content provided as the 
result to the current query.

I wait for additional comments by the WG.

Best,

Mario

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 12:13:27 -0500

> I dropped this solution because it seemed to me conceptually valid but 

Ok, I see.

> according to the current field set.

Great, that was my understanding too.

> the same resource (i.e. the collection of objects provided according 

Ok. Maybe put that in the draft (value = current document, href = other document with other fieldset applied)>
 
> I think that we need to agree about the meaning of "context" in RDAP. It 

Yes, I need this point should be explained better in rfc7483bis,
hoping that it could be considered as a clarification/correction point.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 28 Apr 2020 12:10:46 +0200

Hi Patrick,

thank you for your quick reply.

My comments are included below.

> That is just my generic view, nothing specific to the one draft discussed in this thread.

My humble opinion is that the definition of the "brief" field set would 
have made the document self-contained. I think we could start from the 
outcomes of RFC7485 to converge to a minimal set of recommended fields.

Anyway, I respected the WG decisions. Ubi major minor cessat!

> on the mailing-list how can be sure there will be among all RDAP servers working?

Sometimes it happens that a software artifact becomes a de-facto 
standard because it is largely shared by most of implementers. For 
example, a possible brief field set defined in the gTLD RDAP profile 
would affect 80% of RDAP providers.

This could be a similar situation.

> So no need to spend energy on my late points.

Hope you can contribute more actively to other RDAP drafts still in 
progress.

Thanks again.

Best,

Mario

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 28 Apr 2020 12:22:06 +0200

Hi Patrick,

I just published a new version fixing the issues you pointed out in your 
feedback.

In detail:

- corrected the JSON content of Figure 2

- clarified the meaning of both context and target URIs in a result 
subset link. Hope this change meets your remark.

Best,

Mario