Hi Mario, I read the latest rdap-jscontact draft and have the following comments.
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. Instead, the experiment should focus on collecting feedback to inform a potential future promotion to PS. 2. I think the bar for success in section 1.2 is being set too high. rdap-jscontact already has more implementation experience than most specifications going to PS. Instead, I think the experiment should be about measuring how many servers and clients implement rdap-jscontact, and how many queries include a signal for rdap-jscontact. In other words, I don't think you should set a target level. It might be that we find 5% of queries support it and this working group could, in the future, deem that good enough. IMHO, 1% adoption is good enough. 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. 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. 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. 6. The use of notices in section 4.3 is not quite correct. The "title" property is being used as an identifier, but it is suppose to be human readable text that could be in a separate language. I think what you want is the "type" property, which takes a registered value. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
