Il 17/09/2026 18:12, Scott Hollenbeck ha scritto:
*From:*Mario Loffredo <[email protected]>
*Sent:* Thursday, September 17, 2026 11:48 AM
*To:* Scott Hollenbeck <[email protected]>; 'Mario Loffredo'
<[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 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.
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]
