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] To unsubscribe send an email to [email protected]_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
