On Fri, Mar 17, 2023 at 10:45 AM Mario Loffredo <[email protected]> wrote: > > > 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. > > [ML] No problem. I can remove the reference to the RFC5733 labels and > generally talk about the unique or the preferred value for each contact > property.
For clarity, I don't think a 5733 mapping is a bad thing. I just want to be sure we accommodate those servers where it has no relevance. > > I would be inclined to leave MUST to provide clients and servers with a > pre-defined set of map keys for the mostly used contact properties. If left as a MUST, the document should be clear about what interoperability problem will occur if that MUST is violated. At least to me it is not clear. > > In addition, I would define a general mapping scheme that SHOULD > (instead of MAY) be used for the additional entries of the mostly used > maps or others. > > The scheme could merely consist in appending a sequential number to the > map name in the singular (e.g. "phone-1", "phone-2" for the additional > entries of the "phones" map to those identified by "voice" and "fax" ). > > The other option is to always apply the general scheme to any map key. > > Which way do you and others consider the most suitable ? Conceptually this sounds good. I would need to see a few examples to wrap my brain around it though. :) > > > > > 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? > > [ML] The main reason supporting the proposed approach is to avoid to > duplicate contact data. Conceptually, it seems to me the best way to go > because jCard and JSContact are alternative formats for the same > information. > > The other reason is that servers can realize when the transition is > really concluded because no more clients use the jcard parameter so that > there is no risk to break the response. > > Otherwise, the servers couldn't know when it's time to remove jCard from > the responses and that decision would be made arbitrarily. I think the majority of servers will switch to JSContact via mandate rather than metrics. But that's just my opinion. That said, if the goal is to collect metrics I believe that can be accomplished with one query parameter instead of two. Also, I don't think we want to set a precedent of sending query parameters for every extension. After a while, we'll run into URI length limitations. Additionally, if we want to start signaling client capabilities instead of user queries, we should look into doing that in headers or some other HTTP mechanism. > > Furthermore, I see many drawbacks in returning both jCard and JSContact > in the same response such as the implications on the use of the fn > parameter in both standard and reverse searches (see point 3), and > duplicating some possible items of the redacted array. > > I would leave the document as is about this point unless there was a > large consensus on treating JSContact as additional to jCard. This is a fair point, but during a transition the work has to be done to support both JCard and JSContact by both client and servers anyway. So no work or complexity is being avoided. > > > > > 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. > [ML] Sounds reasonable to me to include such an RDAP conformance tag in > the help response. > > > > 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. > > [ML] On the assumption that either jCard or JSContact is returned, think > it's embedded in the mapping between the vCard fn and JSContact fullName > as described in the appendix. > > The query parameter remains fn but it is mapped to another RDAP property. Great. IMHO, this should be explicitly stated and strongly normative in the document. -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
