Il 19/07/2025 13:02, Andrew Newton (andy) ha scritto:
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.
[ML2] A couple of questions:
1) Do you refer in point 1 to the open-source implementations ?
2) How could we independently calculate the measurements for points 3-4?
I mean, it's easy for a software agent querying bootstrap services to
verify that a server supports this specification from the /help response.
To obtain these numbers, you need access to server log data.
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.
[ML2] Agreed.
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.
[ML2] OK.
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.
[ML2] The authors intended to make a fair proposal. We didn't
intentionally limit the number of observed servers to increase the
probability of success, but, at the same time, we didn't want to
penalize the experiment by including servers that wouldn't be free to
choose to support the specification.
Talking about absolute numbers instead of percentages ameliorates the
problem, but doesn't solve it.
I think ICANN should add language to the gTLD profile to optionally
support JSContact.
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.
[ML2] OK.
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).
[ML2] OK.
Best,
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
