Il 17/09/2026 22:09, Scott Hollenbeck ha scritto:
*From:*Mario Loffredo <[email protected]>
*Sent:* Thursday, September 17, 2026 3:24 PM
*To:* Scott Hollenbeck <[email protected]>; 'Pawel Kowalik'
<[email protected]>; [email protected]
*Subject:* Re: [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Il 17/09/2026 18:12, Scott Hollenbeck ha scritto:
*From:*Mario Loffredo <[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, September 17, 2026 11:48 AM
*To:* Scott Hollenbeck <[email protected]>
<mailto:[email protected]>; 'Mario Loffredo'
<[email protected]>
<mailto:[email protected]>; 'Pawel
Kowalik' <[email protected]>
<mailto:[email protected]>; [email protected]
*Subject:* Re: [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Il 17/09/2026 16:31, Scott Hollenbeck ha scritto:
*From:*Mario Loffredo
<[email protected]>
<mailto:[email protected]>
*Sent:* Thursday, September 17, 2026 9:38 AM
*To:* Scott Hollenbeck <[email protected]>
<mailto:[email protected]>; 'Pawel
Kowalik' <[email protected]>
<mailto:[email protected]>; 'Mario Loffredo'
<[email protected]>
<mailto:[email protected]>;
[email protected]
*Subject:* [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Hi Scott,
please find my comment below.
Il 17/09/2026 14:09, Scott Hollenbeck ha scritto:
-----Original Message-----
From: Pawel Kowalik<[email protected]>
<mailto:[email protected]>
Sent: Thursday, September 17, 2026 3:06 AM
To: Mario Loffredo<[email protected]>
<mailto:[email protected]>; Pawel
Kowalik<[email protected]>
<mailto:[email protected]>;[email protected]
Subject: [regext] Re: I-D Action:
draft-ietf-regext-rdap-jscontact-26.txt
Hi Mario,
On 16.09.26 18:03, Mario Loffredo wrote:
[SAH] [snip]
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.
[SAH] After thinking about this some more, I have a more fundamental issue with the draft that
Pawel touches on above. We have to remember that jCard and "rdap_level_0" as defined in RFC 9083
are tightly coupled. A server can't signal support for "rdap_level_0" without supporting jCard.
That's immutable without updating or replacing 9083. I prefer an option where a server that supports
JSContact signals support for the "jscontact" extension in the usual way and returns both
representations. As Pawel describes above, the extension data can be included even if not explicitly
requested because we're assured that clients will ignore things that they don't understand. Clients that want
the JSContact representation will receive it, and clients that don't want it can ignore it.
Deprecation of jCard use in RDAP, or changing what "rdap_level_0"
means, requires either update or replacement of 9083. We can't get around that.
[ML] Section 5.1 of RFC9083 states the following:
The entity object class *can contain *the following members:
1. objectClassName -- the string "entity"
2. handle -- a string representing a registry-unique
identifier of the entity
3. vcardArray -- a jCard with the entity's contact information
....
My interpretation is that an RDAP response including an entity
object remains compliant with "rdap_level_0" even when the
vcardArray member is missing.
The text defines which members are allowed in an entity
object, not which ones are mandatory.
The other normative language mentioning jCard refers to the
case where contact information is included and provided via jCard.
The handle property may also be missing.
In fact, RFC9537 includes an example in which the handle
property - despite belonging to a domain object - is redacted
by the removal method.
There is nothing in the definition of handle and vcardArray
that makes handle optional and vcardArray mandatory.
Maybe I'm wrong but could you please indicate where it is
clearly stated that an entity object MUST include the
vcardArray member?
*/[SAH] That’s a good point. It isn’t clearly stated. The
current “can contain” text could be interpreted to mean that
*all* of the members of an entity object are OPTIONAL. Section
4.9 clarifies that the "objectClassName" member is REQUIRED
(5.1 should really note the requirement, too. That may merit
an errata report.), but there’s not a similar requirement for
a vcardArray or any other member. I can’t remember why we
chose to use “can contain”, except that it supports the
development of operational profiles (such as ICANN’s gTLD
response profile) to provide greater specificity. Ugh./*
*//*
*/ICANN’s gTLD response profile requires a vcardArray in some
cases. That’s a potential conflict. It may be worth noting
somewhere that jCard omission could cause a conflict with any
extensions or profiles that require inclusion of a vcardArray./*
*//*
*/Scott/*
I believe this is a matter to be addressed within the scope of
specific RDAP profiles. Similarly, the specification regarding
JSContact profiles allows profile designers to define additional
constraints beyond those in RFC 9553.
*/[SAH] I have to disagree with that, Mario. You’re writing a
draft that’s known to conflict with other operational extensions.
It’s up to you to describe how to mitigate the conflicts. Once
this draft becomes an RFC it’ll be up to designers of new profiles
and new extensions to accommodate it./*
*/Scott/*
Scott, I may agree with the general principle that this document
should describe how it interacts with existing specifications and
known deployed extensions. However, I don't believe that the ICANN
gTLD RDAP Response Profile creates a conflict with this draft. I'm not
aware of any other extension that conflicts with this one either.
RFC 9083 does not require every entity object to include a vcardArray
member. Section 5.1 states that an entity object "can contain" a
vcardArray, while Section 2.1 allows servers to omit optional
registration-data members according to server policy. As you pointed
out, the only member that RFC 9083 expressly requires in every RDAP
response object is objectClassName, as specified in Section 4.9.
The ICANN RDAP Response Profile explicitly anticipates alternative
contact representations. Section 1.6.1 requires a server to use jCard
only "absent an indication from the RDAP client preferring an
alternative format". Section 1.6.2 permits the use of alternative
formats approved as Proposed Standards. Section 1.6.3 then provides
the applicable rule when a client requests such a format: the server
MUST represent the contact information using (1) jCard, (2) the
requested alternative format, or (3) both.
Consequently, the Profile clearly allows a server to return only the
requested alternative representation. When JSContact is requested,
returning jscontact_card without vcardArray is one of the alternatives
already allowed by Section 1.6.3.
The other requirements in the Profile identify contact data that must
be returned in particular contexts; they do not establish a general
requirement that every entity object always include vcardArray (see
Sections 2.4.1, 2.4.5, 2.7.4, 2.7.6 and 3.1). When JSContact is
requested, the draft maps those required data elements to their
JSContact counterparts. Therefore, the Profile’s substantive data
requirements can still be satisfied without providing the same contact
information a second time via vcardArray.
The prohibition against returning both jscontact_card and vcardArray
in the same entity does narrow the three choices offered by Section
1.6.3 of the Profile. For a JSContact request, the server uses the
second choice (i.e, the requested alternative format) rather than the
third one (i.e. both formats). It doesn't eliminate a Profile requirement.
This restriction also applies only after the client has explicitly
requested JSContact through one of the mechanisms defined by this
draft. A client that doesn't request JSContact continues to receive
the default jCard representation. Therefore, existing clients and
deployments are not required to replace jCard merely because this
document is published.
If there is a known operational extension that normatively requires
vcardArray, or that addresses values within vcardArray using
representation-specific paths, I agree that this document should
identify that extension and define whether it is incompatible with
JSContact or provide an equivalent JSContact mapping. However, that is
a specific extension-interaction issue. It does not establish a
general need to return both contact representations.
*/[SAH] Correct, but given the current draft text that disallows
returning both representations there’s a conflict with the third
option (both) described in Section 1.6.3 of the profile./*
*//*
*/Scott/*
[ML] I do not see a conflict because, as you have just confirmed,
returning both formats is an option, not a requirement. Specifically,
the request mechanism described in this specification satisfies two of
the three options: jCard is returned by default, JSContact is returned
upon requested.
Furthermore, after extensive discussion, the working group ultimately
agreed that the request for an extension (particularly in this specific
case, where contact information is represented in two different formats)
falls within the scope of content negotiation.
Returning both jCard and JSContact in the same RDAP representation is
not prohibited by HTTP content negotiation, because the response still
uses the application/rdap+json media type and both exts_list and
versioning_list are defined as hints. However, always returning both
formats weakens the purpose of negotiation: the client’s preference no
longer selects the contact representation but merely causes an
additional representation to be included.
Best,
Mario
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [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
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
