Hi Maarten,
thanks a lot for your feedback.
Please find my comments inline.
Il 10/11/2025 10:58, Maarten Wullink ha scritto:
Hi Mario,
2) Deprecating one feature and replacing it with another always implies a
transition period during which both features are provided by the server and can
be requested by the client. Therefore, I didn't understand the argument that
the draft couldn't be made ST because jCard is already there. Even if the draft
remained experimental, JSContact and jCard would coexist for a more or less
long time. The only difference in making jscontact-rdap ST is that the WG would
agree that JSContact is a more efficient representation of jCard and could be a
technically viable alternative to jCard.
i see no valid reason why jscontact cannot become a ST, a client/server can
support both in multiple ways, we just have to figure out which format is the
future preferred format.
I prefer jscontact over jcard any day.
This may be a good time to start thinking about a generic process for
deprecating RDAP fields/headers/params/objects? because this might happen again
in the future for example when DELEG becomes a reality we might want to replace
the Nameserver object.
3) As suggested by Jasdip on the mailing list, I also think that using
JSContact in RDAP should be viewed first and foremost as an extension like any
other. While the draft also includes guidance for a transition process between
jCard and JSContact, it doesn't explicitly state that jCard is deprecated
neither it defines the duration of the transition process. Like any other
extension, it always depend on how many servers will implement and how many
clients will require this extension.
I’m not sure if making jscontact an extension is the best way forward, it
signals that the core format for an entity is always jCard and it will make
deprecating jCard not any easier
[ML] I think it's best to proceed step by step. First, release
rdap-jscontact as a ST extension so that RDAP clients and servers have a
more efficient contact format than jCard. If JSContact is implemented
adequately on both the server and client sides, initiating the jCard
sunset and then deprecation as described in the document will be a
natural consequence.
maybe it would be better to add jscontact to the rdap “core" as an alternative
for jcard, keeping jcard as the default format (for now, to not break existing
clients), the client can then use a mimetype to signal what type of response is
preferred?
[ML] This corresponds exactly to phase 2 of the transition process
described in the paper, i.e., jCard is the default contact format, but
clients can get JSContact on demand. I implemented the request for
jscontact using the methods described in the rdap-x-media-type and
rdap-versioning drafts.
That said, and considering that most of WG members (3 out of 4 including Jim)
who spoke on the mic at last meeting supported reconsidering the draft's
status, I expect that the Chairs will post a call to verify the WG consensus on
turning the draft back to ST.
+1
Best,
Mario
-
Maarten
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
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 -- [email protected]
To unsubscribe send an email to [email protected]
