Mario, in-line
On Fri, Jul 18, 2025 at 3:06 PM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > > 1. The guidelines on experimental RFCs does not guarantee that an > Experimental will be promoted to Proposed Standard if the experiment > is successful. Even if the criteria set out in section 1.2 were met, > IETF consensus is still required to move rdap-jscontact to PS. In > other words, the text "A future update to this document may promote it > to the Standards Track" should be struck as it seems to indicate that > rdap-jscontact will go to PS if the criteria are met and documented in > an I-D. > > [ML] OK. Does the following rephrasing sound better ? > > A future update of this document may lead to its re-evaluation for the > Standards Track if ... What about this? "It is expected that the information gathered from this experiment will be used in a future revision of this specification intended for Proposed Standard. This experiment is to collect the following information after 3 years following the publication of this document: 1. The number of server implementations implementing this specification. 2. The number of RDAP services for INRs and DNRs able to provide JSContact information. 3. The number of RDAP queries in which a client has signaled that it accepts JSContact information. 4. The number of RDAP queries containing JSContact information. 5. The number of open-source clients capable of interpetting JSContact information." That is a bit rough... but that is what I was thinking. Take or leave any parts of it. Also, if RPP adopts JSContact then there is a very compelling reason for RDAP to adopt it as well regardless of the experiment. This may be something we should discuss. > I guess the threshold value for clients is fine with you, isn't it? I think 25% is too high. I'd be happy with two or more clients intended for non-experimental use. > > 3. Does item 1 in section 1.2 rule out gTLD RDAP? That's how I read > it, but I am not sure that is the intent. > > [ML] My main concern was ICANN's policy toward experimental RFCs. I mean, > could the gTLD RDAP profile allow servers to optionally support JSContact as > an experimental format? > > I didn't think so. To have a chance of being promoted to PS, the JSContact > format would need to be supported by as many servers as possible, but gTLD > servers must conform to the gTLD RDAP profile, which is unlikely to allow > support for the JSContact format until it is promoted to PS :-( > > This potential circular dependency prompted the authors to exclude gTLD > servers from those observed in this experiment. > > We would be very happy if, once published as Experimental RFC, the JSContact > format was mentioned in the gTLD RDAP profile as an optional extension. Ah... I think what you have works for your purposes then. > > 4. Is it worth adding the qualifier "actively maintained" to item 2 of > section 1.2? Otherwise, projects that are dead might hold back the > adoption count. > > [ML] Since we're dealing with open source clients, I'm not sure this change > makes sense. Under some public licenses, an RDAP client could be forked and > maintained in a local branch. > > Also, I wonder how a client can be formally defined as "actively maintained." I would define it as any client for which the authors or maintainers have not indicated it will no longer be maintained. > > 5. I think it would be interesting to add a "noJcard" extension > identifier to the experiment to see how many clients and queries > explicitly want only jscontact. > > [ML] The end of the transition process is signaled by a specific notice. Are > you suggesting replacing it with an extension identifier in the > rdapConformance array or providing both? No, I am suggesting that clients can say "I don't want Jcard". My understanding of the "jscontact" signal is that it does not mean the server should return only jscontact (in other words, the server could return both jcard and jscontact). -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org