Hello Mario, A quick follow-up that could be a closure in fact, as your answer fills the missing points I had.
On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote: > 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. 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. I do however profoundly disagree with: > because the WG had clearly recommended to separate the technology, > described in the RFC, from its operational aspects, described in an RDAP > profile. 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. > > 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. 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? > 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. Yes, clearly my worries are about "brief". > > 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 :-( 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. > I would like the other WG members to manifest their opinions so that I > 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 p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
