I support PS status for the JSContact for RDAP and this must not not be dependent on RPP using it or not.
- Maarten Op 26 sep 2025, om 15:43 heeft Mario Loffredo <[email protected]> het volgende geschreven: Hi Andy, Pawel and Jasdip, thanks a lot for your feedback. My post was divided into two parts. The first included the information that, in the author's opinion, should support this WG's decision to reconsider JSContact for PS, regardless of whether JSContact is adopted by RPP. Essentially, the two main WG concerns about using JSContact in RDAP have been eliminated following the publication of two CalExt drafts. Quoting Andy, "they make it easier to implement JSContact for the purposes of RDAP". The second part was additional information useful to the WG, but, IMO, the rdap-jscontact category should not necessarily depend on RPP's decisions. I've asked for time at the next meeting to allow all working group members to discuss this topic. In the meantime, I'd like to hear other opinions. Best, Mario P.S. Hopefully we don't end up in a weird deadlock where RegExt waits for RPP to mandate JSContact while RPP waits for RegExt to turn rdap-jscontact back into ST as information needed to mandate JSContact :-( Il 25/09/2025 17:18, Jasdip Singh ha scritto: Hi, Until now RDAP and EPP (RPP’s ancestor) have traditionally used different data structures with slightly differing semantics because of read versus read-write scenarios. Since that disparity won’t be changing any time soon and the fact that RDAP JSContact has already benefitted from the SimpleContact input, it should be ok for RDAP to continue with JSContact if RPP were to decide on another way. And, since that does not seem to presently bolster the case for JSContact use in both RDAP and RPP, it should be ok for RDAP JSContact to stay on the Experimental track unless we believe that the JSContact use in RDAP should solely suffice to put it on the Proposed Standard (PS) track. Emulating how other RDAP extensions being worked on are mostly on the PS track, it seems fair to also label the RDAP JSContact draft as a PS, no? Jasdip From: Pawel Kowalik <[email protected]><mailto:[email protected]> Date: Thursday, September 25, 2025 at 8:52 AM To: Andrew (andy) Newton <[email protected]><mailto:[email protected]>, [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject: [rpp] Re: [regext] Re: Turning back rdap-jscontact into ST ? Hi, I think this would be a hard dependency on RPP that would not find an answer before design phase concludes. The requirements say "RPP SHOULD consider using JSContact [@!RFC9553] format for contact representation." which means in the design phase JSContact would be seriously taken into account but not more than that. JSContact still has some built in complexity which is not yet convincing if this is the way to go for RPP. Refer to my slides from IETF123 - Slide 8&9 of [1]. Read-Write use-cases have some other operational requirements than read-only use cases which may move the needle. I will repeat what I said during IETF 123. JSContact was put as Experimental due to competing approach of SimpleContact and the WG obviously didn't want to proceed with 2 approaches as Standards Track same time so the conclusion was to put both as Experimental and see which one prevails. The real goal from the WG was however to push for migrating away from jCard, wasn't it? Here Standard Track document is in need eventually. Now that SimpleContact is not being worked on anymore, we don't have to run experiment to know which solution to take, do we? I'd say this would be enough as justification for me. The question can be reversed, however. If RPP would decide to go other way than using JSContact, would it mean RDAP would have an alternative candidate for replacement of jCard? Does such possibility matter on what we decide of JSContact now? [1] https://datatracker.ietf.org/meeting/123/materials/slides-123-rpp-rpp-hackathon-ietf-123-01 Kind Regards, Pawel cc RPP WG. On 25.09.25 13:05, Andrew (andy) Newton wrote: > Hi Mario, > > First, I very much appreciate the changes to JSContact to make it > easier to implement for the purposes of RDAP. > > And I agree that if RPP adopts JSContact, that is a compelling reason > to use it in RDAP. > > If this wg were to reconsider JSContact for PS, would that mean we > hold on to the draft until RPP is close to putting JSContact in their > RFCs? In other words, is there a timing issue we need to consider? > > -andy, as an individual > > On 9/24/25 08:40, Mario Loffredo wrote: >> Hi, >> >> this continues the brief discussion we had at the last meeting about >> turning the rdap-jscontact draft back into ST. >> >> Since that draft has been made experimental, the following revision >> documents have been published for the JSContact properties that were >> the WG's primary concern regarding the use of JSContact in RDAP: >> >> - draft-ietf-calext-jscontact-uid, now in IETF Last Call, makes the >> JSContact "uid" property optional. This specification prevents RDAP >> providers prevent response correlation and thus manage the redaction >> of that property. >> >> - draft-ietf-calext-jscontact-profiles, which is also expected to go >> through the IETF Last Call shortly, simplifies the handling of the >> JSContact "localizations" property to allow RDAP providers to avoid >> handling JSON pointers. This simplification was also demonstrated >> through the POC published at >> https://github.com/mario-loffredo/TestJSContactProfile. >> >> Furthermore, the RPP requirements, as described in >> draft-ietf-rpp-requirements, include a recommendation to use the >> JSContact format for representing contacts.Therefore, although RPP >> has recommended to adopt JSContact and not the corresponding RDAP >> extension, RPP implementers would benefit from a direct conversion of >> RPP data to RDAP data through the standardization of this extension. >> >> Consequently, Gavin and I believe this new information is sufficient >> to prompt the WG to reconsider the draft's category. >> >> It would be appropriate to conclude this matter so that the document >> can proceed to the next standardization phases, depending on its >> category. >> >> >> Thoughts ? >> >> >> Best, >> >> Mario >> >> >> -- >> 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]<mailto:[email protected]> >> To unsubscribe send an email to >> [email protected]<mailto:[email protected]> > > _______________________________________________ > regext mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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 _______________________________________________ rpp mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
