Sorry, missed the original proposer of option 3 – Marc. Obviously, agree with him! :)
Jasdip From: regext <regext-boun...@ietf.org> on behalf of Jasdip Singh <jasd...@arin.net> Date: Wednesday, May 31, 2023 at 7:57 PM To: Mario Loffredo <mario.loffr...@iit.cnr.it>, Rick Wilhelm <rwilh...@pir.org>, Andy Newton <a...@hxr.us> Cc: Marc Blanchet <marc.blanc...@viagenie.ca>, "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition Hello Mario, No worry. :) Firstly, thank you for sharing this analysis. The JSContact versus jCard size comparison is particularly interesting, and kinda expected given the map versus the jagged arrays respectively for them. Though one could appreciate the rationale for using query parameters for reduced response sizes, as well as a graceful API sunset mechanism for retiring jCard, IMO the simplicity of implementing option 3 (both jCard and JSContact in a response for some time) is still a good tradeoff for increased response size. Given both jCard and JSContact are optional to start with, an RDAP client could cleanly ignore the data type it does not understand at any point. (Re-read what Andy and Rick said below, and still concur with their inputs.) Thanks, Jasdip From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Wednesday, May 31, 2023 at 8:34 AM To: Jasdip Singh <jasd...@arin.net>, Rick Wilhelm <rwilh...@pir.org>, Andy Newton <a...@hxr.us> Cc: Marc Blanchet <marc.blanc...@viagenie.ca>, "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition Hi Jasdip and others, I strongly apologize for replying to this post with big delay but I have been very busy with JSContact and reverse search docs and other business from .it. After having concluded the discussion on how to redact the uid property, would like to resume and finalize the discussion on this topic. As I promised, have made some tests to estimate the size increase of the RDAP response when JSContact is returned along with jCard. Think it could be helpful to have a comprehensive overview. For the sake of obtaining an accurate measure, I purged the responses of notices, remarks and extensions and compacted the JSON content to exclude unnecessary characters (i.e. spaces, nelines) from the bytes count. First I found out that jscard is twice as big as jcard on average. In .it RDAP responses, the size of a jscard is a about 800 bytes whilst jcard is about 400 bytes long. This shouldn't sound weird. In fact, as opposed to JSContact, jCard doesn't include the property names because basically it's a JSON transliteration of a positional notation. I could not test other RDAP servers implementing JSContact but I don't think the results would be much different since in general RDAP makes use of the same subset of JSContact data. Then I took a domain with five contacts (i.e. one registrant, one admin and three techs) which corresponds to a common .it case. The response including only jCard was long about 3,5 Kb. This means that providing both the formats together makes the RDAP response larger more than twice. Maybe the size increment can't be a concern but I'm still convinced that it would sound pretty unusual to the client to get more than twice the response as before without negotiation. What do you think ? Best, Mario Il 04/04/2023 00:18, Jasdip Singh ha scritto: Hi. If the response size increase is not a concern when both jCard and JSContact objects are returned for some time, it seems Andy’s proposal (option 3) is the way to go. IMO, it keeps things simple without having to worry about which query parameter to set on the client side. Additionally, a server could simply send back a notice as to when jCard would be sunset from its side. As was mentioned previously, agree that a server couldn’t definitively measure when the client demand for jCard goes to zero by looking at the proposed query parameters. Instead, the server would decide unilaterally with sufficient forewarning to clients. Jasdip From: regext <regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> on behalf of Mario Loffredo <mario.loffr...@iit.cnr.it><mailto:mario.loffr...@iit.cnr.it> Date: Monday, April 3, 2023 at 5:32 AM To: Rick Wilhelm <rwilh...@pir.org><mailto:rwilh...@pir.org>, Andy Newton <a...@hxr.us><mailto:a...@hxr.us> Cc: Marc Blanchet <marc.blanc...@viagenie.ca><mailto:marc.blanc...@viagenie.ca>, "regext@ietf.org"<mailto:regext@ietf.org> <regext@ietf.org><mailto:regext@ietf.org> Subject: Re: [regext] [EXTERNAL] Re: jCard to JSContact transition Hi Rick, please find my comments below. Il 01/04/2023 03:03, Rick Wilhelm ha scritto: 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. [ML] Up to now, we have always followed the philosophy that an addtional feature must be provided by the server on demand. I would keep it also in this case so I would make the submission of jscard parameter the condition to receive JSContact. In my opinion, it's useless to provide the same information twice in two different formats simultaneously because the client will always use only one. Furthermore, providing the contact information in two formats increases the risk of inconsistencies between them. Please take a look at the change on the current approach I proposed to Andy and say if it works for you too. Best, Mario Thanks Rick From: regext <regext-boun...@ietf.org><mailto:regext-boun...@ietf.org> on behalf of Andrew Newton <a...@hxr.us><mailto:a...@hxr.us> Date: Saturday, April 1, 2023 at 6:27 AM To: Mario Loffredo <mario.loffr...@iit.cnr.it><mailto:mario.loffr...@iit.cnr.it> Cc: Marc Blanchet <marc.blanc...@viagenie.ca><mailto:marc.blanc...@viagenie.ca>, regext@ietf.org<mailto:regext@ietf.org> <regext@ietf.org><mailto: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><mailto: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><mailto: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<mailto: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<mailto: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<mailto: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<mailto: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 -- 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
