Hi Andy,
Il 31/03/2023 23:27, Andrew Newton ha scritto:
I really don't understand this decision tree. JCard is in the standard
today while JSContact is not. Any transition that aims to be as
non-disruptive as possible would need to start at serving JCard today,
serving both JCard and JSContact, and then phasing out JCard.
[ML] This is exactly the goal of the current proposal: providing jCard
or JSContact at any time in the transition period.
In addtion, it is less disruptive than the other proposals because an
RDAP server can decide to stop returning jCard based on the evidence
that no client is still requesting for jCard.
Think we can rearrange the current proposal to make it less effort
consuming for both clients and servers.
We can remove the stage 3 and, consequently, the jcard parameter. An
RDAP server would be sure that no client is still using jCard because
all the incoming requests include the jscard parameter but,
nevertheless, it can respect a deprecation time announced previously.
We can assume that a client requesting for JSContact is able to process
it hence there's no need for the server to return both the formats and
no risk for the server to provide a disruptive response.
From the other side, a client is able to know that a server can return
JSContact by searching for the "jscard" rdapConformance tag in the help
response. Another way is to include the jscard parameter in the request
and then check if the response includes the jscard member.
When a server stops returning jCard and returns JSContact by default, it
simply ignores the jscard parameter.
This usually occurs for every query parameter unknown to a REST API.
Therefore, both clients and server need to handle errors.
A client can anyway keeps including the jscard parameter for an
undefined period . In addition, it can realize that all the contacted
servers have completed the transition by checking that the jscard member
is missing in the response when it doesn't include the jscard parameter
in the request.
In that case, the client can definitively remove the jcard handling from
its implementation.
Does it work for you and everyone else ?
Best,
Mario
-andy
On Thu, Mar 30, 2023 at 8:37 PM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi Marc,
thanks for your quick reply.
Think it's always better to reduce the response payload when you can
through a low implementation effort. But it's just my opinion.
So now we have 3 proposals on the table :-))
Best,
Mario
Il 30/03/2023 13:09, Marc Blanchet ha scritto:
Le 30 mars 2023 à 19:47, Mario Loffredo <mario.loffr...@iit.cnr.it> a écrit :
Hi folks,
this is a post to resume the discussion about how to execute the transition
from jCard to JSContact.
Up to now, there are two approaches on the table:
1) Returning JSContact in place of jCard (current proposal)
Until transition is ended, a server returns one of the two formats by default
and returns the other on request.
Each server can decide that it's time to stop supporting jCard based on the
evidence that it's no more requested.
2) Returning JSContact in addition to jCard
Until transition is ended, a server returns jCard by default and adds JSContact
to the response on request.
Each server arbitrarily decides when it's time to stop supporting jCard.
Sorry Mario, I’ve been a bit off on this, so maybe my comment is off. But why
not:
3) Returning JSContact in addition to jCard
Until transition is ended, a server returns jCard by default and always adds
JSContact to the response
Each server arbitrarily decides when it's time to stop supporting jCard.
Regards, Marc.
Please see Section 4.2.1 of the rdap-jscontact document and my today's
presentation for more information about pros/cons of each approach and provide
feedback.
Best,
Mario
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
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
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
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
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
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
https://www.ietf.org/mailman/listinfo/regext
