We may have more extensions that would want to add media type parameters, so the problem space is the same. (Potential) conflicts occur on the specification level, not in runtime where for all cases (media type parameters, url path segments, JSON names, query parameters) the server will by nature not generate duplicates, but won't help if 2 extension specifications would render conflict.

Anyway, IANA registry of extension identifiers assure no conflict possibility in all cases for both bare and prefixed identifiers. If someone would deploy an extension ignoring the registration process we can't really help.

Kind Regards,

Pawel

On 16.06.25 21:40, Jasdip Singh wrote:

James,

Preventing naming collisions in RDAP requests (query paths and parameters) and responses (JSON) across multiple RDAP extensions does make sense.

But this is not a problem for a media type since its parameters, if any, are appended right after (delimited by a semi-colon) in an Accept or a Content-Type header, and that inherently makes them unique from parameters for another media type, as in:

  accept: application/json;q=0.9,

         application/rdap+json;extensions="rdap_level_0 rdapExtensions1 fred";q=1,

<another media type>;extensions="…”;<another parameter>=”…”;q=1

Furthermore, for example, the “charset” parameter exists for both the “text/html” and “text/csv” media types.

In other words, if media types are guaranteed to be unique, which the IANA Media Types registry [1] ensures, naming parameters for each of them is considered safe from collisions. Hence, no need for prefixing a media type’s parameters.

Jasdip

[1] https://www.iana.org/assignments/media-types/media-types.xhtml

*From: *Gould, James <[email protected]>
*Date: *Monday, June 16, 2025 at 2:39 PM
*To: *Jasdip Singh <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Hollenbeck, Scott <[email protected]>, [email protected] <[email protected]>
*Cc: *[email protected] <[email protected]>
*Subject: *Re: Re: [regext] Re: On bare identifiers in Extensions draft

Jasdip,

The same case can be made for query parameters and path segments.  An RDAP extension can come in many forms, whether it be media type parameters, query parameters, path segments, and JSON members.  I personally don’t believe there is any issue with bare identifiers for extension elements if there is no conflict and there is a clear specification.  If we’re going to require an extension identifier prefix with an underbar separator for all RDAP extension elements, that would apply to draft-ietf-regext-rdap-x-media-type and its media type parameter.

Thanks,

--

JG


cid87442*[email protected]

*James Gould
*Fellow Engineer
[email protected]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

*From: *Jasdip Singh <[email protected]>
*Date: *Monday, June 16, 2025 at 10:59 AM
*To: *"Andrew (andy) Newton" <[email protected]>, James Gould <[email protected]>, "[email protected]" <[email protected]>, "Hollenbeck, Scott" <[email protected]>, "[email protected]" <[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *[EXTERNAL] Re: [regext] Re: On bare identifiers in Extensions draft

*Caution:*This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi James,

The string literal “rdapExtensions1” is intended as this ‘profile’ extension’s identifier, per the Extension Identifier section [1].

Not sure if we need such prefixing to avoid parameter collision for media types, like “application/rdap+json”, that the IETF produces. AFAIK, this is not even done for the non-IETF media type trees like “vnd.”.

Jasdip

[1] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-x-media-type-03.html#name-extension-identifier <https://secure-web.cisco.com/1s3TRlXlUHD4LwvWvsWs2lnaUeJVvWW2GLuuVzdbtP3_oR1cr_Q07S61RomAnDMuMl414YyoM0QbzUvX4U1dp6bvoab5pRVRuhpTJMK_35HZ3R6MuNkFtOaDywZD6tBPG7d9tep-fMm86fO9aHfjdgxUspeyCOeXB0zY4n08LWB63VO8AF1R0YXBCOCJN5R7JH-U7y04Uq5hkTvf00P6wKgEYot4rh5ThUQPpKheXdsJB7BTg3D5u6Ui7jm1Lb0FJFligapXOywcHFX78qe1-hN1MVtVnxWt8g8AVxQlyF30/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-regext-rdap-x-media-type-03.html%23name-extension-identifier>

*From: *Andrew (andy) Newton <[email protected]>
*Date: *Monday, June 16, 2025 at 8:32 AM
*To: *Gould, James <[email protected]>, [email protected] <[email protected]>, Hollenbeck, Scott <[email protected]>, [email protected] <[email protected]>
*Cc: *[email protected] <[email protected]>
*Subject: *[regext] Re: On bare identifiers in Extensions draft



On 6/16/25 07:56, Gould, James wrote:
>
> Shouldn’t the x-media draft register the “extensions” RDAP extension identifier and use an extension identifier prefix in place of the bare identifier for the “extensions” media type parameter, such as “extensions_extensions”, “extensions_param”?  I believe the x-media draft should include an RDAP extension registration, but I don’t believe there is the need to change from the use of the bare identifier.

I think "extensions_list" is probably what we want. Good point. I've created an issue for the next rev.

-andy

_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to