Hi all, I'm doing some RDAP programming and looking at the JSContact draft and have a couple of comments.
1) Section 3 has some strong MUST language regarding JSContact and EPP. As I'm reading it, I am trying to deduce what interoperability problem is being mitigated but, at least to me, it is not apparent. If there is some cardinality issue, I think the rules should be generalized because RDAP is used by more than just the EPP registries, most notably the RIRs but also Marc's space debris proposal. If an EPP mapping is truly necessary, I think putting it in a separate EPP mapping section would be better. Also, unless things will truly break, the normatives should be SHOULD and not MUST. 2) I think Section 4 will actually hinder transition rather than help it. If a server doesn't support JSContact, there are no amount of query parameters that a client can send to make it do so. Therefore, we should treat this like any other extension... server's just send it if they have it. If there is a desire to save hamster wheel time (i.e. bandwidth), shouldn't we try to make use of the "subsetting" extension? And if there is a desire to indicate a server has deprecated JCard (YES!!!), perhaps a "jcard_deprecated" RDAP conformance value can be used for that. 3) There is no support for section 3.2.3 of RFC 9082, specifically the name search. The current pattern is "entities?fn=XXX". The use of "fn" parameter is a bit unfortunate, but this draft should indicate how a server supporting only JSContact maps this query. Thanks. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
