Jasdip, The media type parameter could support the bare identifier since there is only one defined for the extension.
[JS] The same rule -- one-versus-multiple -- could apply here since there could be multiple parameters defined for a media type, as part of an RDAP extension. No? Yes, the same one (bare identifier supported)-versus-multiple (bare identifier not supported) would apply for a media type parameter as for other extension types. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Jasdip Singh <jasd...@arin.net> Date: Tuesday, June 24, 2025 at 2:01 PM To: James Gould <jgo...@verisign.com>, "kowa...@denic.de" <kowa...@denic.de>, "a...@hxr.us" <a...@hxr.us>, "Hollenbeck, Scott" <shollenb...@verisign.com>, "maarten.wull...@sidn.nl" <maarten.wull...@sidn.nl> Cc: "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: 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. From: Gould, James <jgo...@verisign.com> Date: Tuesday, June 24, 2025 at 1:09 PM To: Jasdip Singh <jasd...@arin.net>, kowa...@denic.de <kowa...@denic.de>, a...@hxr.us <a...@hxr.us>, Hollenbeck, Scott <shollenb...@verisign.com>, maarten.wull...@sidn.nl <maarten.wull...@sidn.nl> Cc: regext@ietf.org <regext@ietf.org> Subject: Re: Re: [regext] Re: On bare identifiers in Extensions draft Jasdip, I believe the guidance should be to allow the use of a bare identifier when there is a single extension element of type query path, query parameter, JSON name, object class, and/or another extension point (HTTP header, etc.). If there is more than one, the use of the extension identifier prefix with the underbar separator SHOULD or MUST be used. For draft-ietf-regext-rdap-versioning-03, we followed that for the JSON name elements, which now consists of the “versioning_help” and “versioning_data” JSON members, and the use of the bare identifier for the “versioning” query parameter since there is only one element of that type. I suggest this convention be used for all known forms of RDAP extension elements and future forms of RDAP extension elements. The extension identifier or extension identifiers defined in the specification will guarantee uniqueness in the RDAP extension registry and the use of the underbar when there is more than one extension element of a specific type will clearly define the grouping. [JS] That seems reasonable. The media type parameter could support the bare identifier since there is only one defined for the extension. [JS] The same rule -- one-versus-multiple -- could apply here since there could be multiple parameters defined for a media type, as part of an RDAP extension. No? Jasdip From: Jasdip Singh <jasd...@arin.net> Date: Tuesday, June 24, 2025 at 12:09 PM To: Pawel Kowalik <kowa...@denic.de>, James Gould <jgo...@verisign.com>, "a...@hxr.us" <a...@hxr.us>, "Hollenbeck, Scott" <shollenb...@verisign.com>, "maarten.wull...@sidn.nl" <maarten.wull...@sidn.nl> Cc: "regext@ietf.org" <regext@ietf.org> 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 Pawel, I think we as WG have been discussing 2 separate points lately: 1. To what extent should a bare identifier be allowed? Never, always, under certain well-defined conditions (say, when only one query path, query parameter, JSON name, object class, and/or another extension point (HTTP header, etc) needs naming), or when a technical solution cannot be defined otherwise. The next version of the RDAP Extensions draft would present these options so that we can settle this matter. 2. Should a media type parameter, as part of an RDAP extension, also be prefixed? For prefixing consistency, the answer seems to be yes, per earlier discussion with James. So far, from naming conflict prevention angle, we have identified query paths, query parameters, JSON member names, object class names, HTTP headers, and media type parameters as prefixing candidates. Andy and I were discussing one more. :) Should a new relation type defined for a web link used in an RDAP extension also be prefixed? Looks like we should since the Media Types reviewers recommend greater specificity for relation types. Though we haven’t yet tried registering “foobar123-xyz” as a new relation type. ;) The closest prefixing example for regext purposes has been “rdap-up”, etc for the RIR search, whereas “geofeed” was allowed for the RDAP Geofeed from specificity angle. Thanks, Jasdip From: Pawel Kowalik <kowa...@denic.de> Date: Tuesday, June 24, 2025 at 1:42 AM To: Jasdip Singh <jasd...@arin.net>, Gould, James <jgo...@verisign.com>, a...@hxr.us <a...@hxr.us>, Hollenbeck, Scott <shollenb...@verisign.com>, maarten.wull...@sidn.nl <maarten.wull...@sidn.nl> Cc: regext@ietf.org <regext@ietf.org> Subject: Re: [regext] Re: On bare identifiers in Extensions draft Hi Jasdip, On 18.06.25 19:43, Jasdip Singh wrote: Hi Pawel, Totally agree with being consistent prefixing-wise for query requests and responses in RDAP extensions! But afraid, we might be overlaying this prefixing concept on to the media type space unnecessarily. If another RDAP extension ends up adding another parameter to “application/rdap+json” or another media type, the IANA registration process shall identify any conflict with existing parameters when updating that media type’s specification. Correct. Being consistent is also my point but not necessarily in a twist that everything shall be always prefixed. I argument, that "IANA registration process shall identify any conflict" also applies to all other RDAP cases, thus rendering bare identifiers no issue for the interoperability or conflict potential between extensions. Thanks, Jasdip [...]
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
