Hi Andy,
thanks for your feedback.
Please find my comments embedded below prefixed with [ML].
Il 06/10/2026 14:01, Andy Newton ha scritto:
Hi Mario,
On 10/5/26 12:41 PM, Mario Loffredo wrote:
The authors wish to draw particular attention to the following considerations
supporting the requirement that an RDAP entity object must not include both
vcardArray and jscontact_card:
I am still not in favor of this. It should be the server operator's choice. By
mandating this, it will either be ignored or give operators a reason not to
adopt this. Maximum interoperability with the current client base means
supporting both, and that decision is one of policy IMHO.
[ML] Support for JSContact remains a server-side choice, while it is up
to the client to decide whether to request jCard or JSContact. Maximum
interoperability is achieved in stage 2, as the client receives exactly
what it requested based on content negotiation and the "rdapConformance"
values present in the "/help" response. Moving to stage 3 is, once
again, a server-side choice.
A solution consistent with content negotiation involves defining a new
extension identifier that the client can use to negotiate the return of
both formats in the same response—for example, "jcardAndJscontact". A
server may accept this extension, either alongside "jscontact" or as the
only alternative to returning jCard by default during stage 2.
However, I don't advocate for this idea, for the reasons I have already
explained.
- The two members are alternative representations of the same contact
information. jscontact_card is intended to provide the same information as
vcardArray; it is not an additional, independent set of contact data.
- Returning both representations would duplicate information and unnecessarily
increase response size and processing costs, especially for responses
containing multiple entities.
This is great informative text that should go into the operational
considerations to inform operators about their choice.
[ML] In my view, it makes little sense to allow servers to provide both
formats in the response while simultaneously warning them of the
implications of that choice.
- Two representations in the same response could become inconsistent. Although
jCard and JSContact convey substantially the same information, differences
could arise through implementation errors or updates applied to only one
representation. Clients would then have no rule for deciding which value to use.
This document could set a rule that if two are present, jscontact takes
precedence. That is exactly how I have implemented it.
[ML] Consistent with the ability of servers to return both formats,
which format takes precedence for clients depends on the server's policy.
Also, my reading of this doc makes the transition section normative as there are
references to it that say "servers are expected to"... I like the strategy in
Section 4, but I don't think it should be a requirement.
[ML] The transition is not a requirement. It is up to the server to
decide when to start supporting JSContact, when to initiate the jCard
deprecation process, and what the duration should be. Section 4 simply
provides a very basic guidance to clients and servers to ensure
interoperability.
Finally, and it maybe stated I just didn't see it, if the JSContact profile for
rdap is updated, does that mean this extension must be updated? If the doc does
not say that, it should.
[ML] The policy for adding a new entry to the "JSContact Profiles"
registry is "Specification Required." This specification defines an
initial RDAP profile for JSContact named "rdap." Defining a new version
of this profile entails publishing an IETF document that updates the
specification in question. This does not preclude the possibility of
defining other specific JSContact profiles for RDAP through different
documents, outside the RFC publication process.
Best,
Mario
-andy, no hats
--
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]
