Hi Patrick,

your feedback is really welcomed. Better late than never.

My responses to your comments are included below.

Il 27/04/2020 07:45, Patrick Mevzek ha scritto:

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:

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.
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.

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.

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'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.

It would have been nice to provide a template for "brief", at least a SHOULD,
per objects described in the RDAP RFCs.
See my response above.
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."

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.

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.

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 :-(

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)

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

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

Reply via email to