Hi Tim,
please find my response in my replies to Andy's and Rick's post.
Best,
Mario
Il 01/04/2023 03:13, Tim Wicinski ha scritto:
Since it appears that code changes will need to be done for JContact,
the simpler proposal will be number 3.
Bytes are less expensive than making additional requests. (for the
most part)
tim
On Fri, Mar 31, 2023 at 9:03 PM Rick Wilhelm <rwilh...@pir.org> wrote:
I think that I’m leaning towards Andy’s approach, but I haven’t
soak this thinking for very long.
Perhaps it’s useful to go back to one of the original motivations
for the draft.
As I recall, programmers, especially client-side, have been known
to have difficulty with JCard (for various reasons).
Therefore, a “more modern” approach using JSContact is being proposed.
So… A server presently has to support JCard and theoretically MAY
support JSContact.
If a client encounters such a server, and detects that the server
supports JSContact, then it would be able to reliably ignore the
JCard that is returned and instead use code that parses JSContact
and be on its merry way.
A key difference between Mario’s (2) and Andy(3) is basically a
negotiation step. While I understand the benefit of “smaller
response” proposed by (2), it seems that the negotiation step
(with its round trips) would overwhelm that. And perhaps lead to
odd situations (race conditions?) if the server is responding
inconsistently.
On balance, to me the cost of some extra bytes on the wire is
cheap compared to the additional client and server code
complexity, and the server load of the extra connection.
Interested in others thoughts.
Thanks
Rick
*From: *regext <regext-boun...@ietf.org> on behalf of Andrew
Newton <a...@hxr.us>
*Date: *Saturday, April 1, 2023 at 6:27 AM
*To: *Mario Loffredo <mario.loffr...@iit.cnr.it>
*Cc: *Marc Blanchet <marc.blanc...@viagenie.ca>, regext@ietf.org
<regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] jCard to JSContact transition
CAUTION: This email came from outside your organization. Don’t
trust emails, links, or attachments from senders that seem
suspicious or you are not expecting.
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.
-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
<https://protect-us.mimecast.com/s/iZbdC31PzwsROjLt2OE9B?domain=iit.cnr.it>
> >>
> >> _______________________________________________
> >> regext mailing list
> >> regext@ietf.org
> >> https://www.ietf.org/mailman/listinfo/regext
<https://protect-us.mimecast.com/s/6DeiC4xPALS7qZLhWUpEW?domain=ietf.org>
>
> --
> 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
<https://protect-us.mimecast.com/s/iZbdC31PzwsROjLt2OE9B?domain=iit.cnr.it>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
<https://protect-us.mimecast.com/s/6DeiC4xPALS7qZLhWUpEW?domain=ietf.org>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
<https://protect-us.mimecast.com/s/6DeiC4xPALS7qZLhWUpEW?domain=ietf.org>
_______________________________________________
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
