Hi Pawel,
again my comments below prefixed with [ML2]
Il 17/09/2026 09:06, Pawel Kowalik ha scritto:
Hi Mario,
On 16.09.26 18:03, Mario Loffredo wrote:
Hi Pawel,
please find my comments embedded below prefixed with [ML]
Il 16/09/2026 17:14, Pawel Kowalik ha scritto:
Hi Mario,
I was also confused with the logic of current 3.1.1.
I believe it should be saying, that in implementing this extension
jscontact_card is MUST (not MAY) at the places where vcardArray
appears today, and it is MAY for vcardArray accounting for
transition period.
[ML] Basically, supporting JSContact format is an extension.
Therefore, a server MAY return the jscontact_card, i.e. supporting
the JSContact format is not required.
PK> depends how you frame it. Implementing any extension is a MAY by
definition. But, if the extension is implemented, then you expect the
server to use it in the payload don't you? The normative text in an
extension draft already assumes, that the extension is implemented.
Otherwise you would never define anything obligatory in an extension.
[ML2] Not if the extension is not returned by the server by default -
such as the "redacted" extension - but it's negotiated upon request as
it is described in rdap-x-media-type.
If we agree that any extension supported by the server is always
returned in the response, then there's no need to negotiate it.
The negotiation determines not only whether the extension is to be
returned but also which version of the extension is to be used as
described in rdap-versioning.
Therefore, in my view, the usage of MAY is appropriate.
And I copy what Scott tells - MUST NOT of the two representations is
very misleading and not even an intention. As implementer I would
interpret that the two would never appear in one object and maybe
even reject the payload if they did -which is not the intention.
[ML] Your interpretation is correct. The JSContat format is returned
only upon request. If a client requests this extension, this means
that it's capable of handling the jscontact_card member; therefore,
returning the vcardArray member as well is superfluous, and its
absence in the response doesn't break the client.
The other scenario where the server returns the JSContact extension
regardless of whether it is requested is when the server transition
from jCard to JSContact is completed, implying that all involved
clients have finished the transition on their end. However, it can
happen that a server continues to support both formats for a long time.
PK> "JSContat format is returned only upon request" - is it a
reasonable assumption? RDAP is build around "ignore unknown
properties" therefore it shall remain an option for the server to add
the extension data even if not requested, even if it is in the
transition - which I would assume would be the typical approach to
double the content if there is no signal in place.
[ML2] I consider this entirely reasonable; otherwise, I would be at a
loss to explain how a client could request an extension that it is
subsequently unable to handle.
We have already established that extensions (as well as their respective
versions) can be subject to negotiation between client and server.
Servers may include extensions in their responses by default; this
occurs once the transition from jCard to JSContact is complete.
However, during the initial phase and for a period deemed appropriate by
the server, the extension is provided only following negotiation.
Best,
Mario
Kind Regards,
Pawel
--
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]
