Jasdip,
What I’m thinking is formally defining all known forms of extensions,
each with its own section, where there are no questions related to
RDAP’s support for each extension form. Further define how new forms
of extensions can be defined. Should there be an IANA registry of
RDAP extension forms / types that can be referenced in defining an
extension? The reason I bring this up is that EPP has a fixed set of
extension types, and we ran into an issue during IETF last call is
defining a new form, called a Functional Extension, in
draft-ietf-regext-epp-eai-15 that had to be removed in
draft-ietf-regext-epp-eai-16. We could go with a static set of RDAP
extension forms, but I believe that would be short-sided, since we
can’t foresee all possible forms that are needed. Below is a modified
list from my prior message:
1. Path Segment
1. Path segment for defining a new object in the request, which
is covered by RFC 7480 and RFC 9082. Sub-path segment could
be covered here as well or be a form on its own. RFC 9536
with the “reverse_search” sub-path for defining a new verb is
interesting and could be covered with the sub-segment
extension form.
2. JSON Names
1. JSON names for defining new members in the response, which is
covered by RFC 7480 and RFC 9083.
3. Query Parameters
1. Query parameters for defining new request preferences and
features, which is NOT covered RFC 7480 and RFC 9082. Many
RDAP extensions have leveraged extensibility of query
parameters, including RFC 8982, RFC 8977, RFC 9560,
draft-ietf-regext-rdap-versioning,
4. HTTP Headers
1. HTTP headers for defining new request preferences and
features, which is NOT covered RFC 7480 and RFC 9082. The
draft-ietf-regext-rdap-x-media-type draft leverages
extensibility of HTTP headers.
5. “objectClassName” Member Value
1. Value of the “objectClassName” member for defining a new
object in the response, which is NOT covered RFC 7480 and RFC
9083. I haven’t seen this form of extensibility in a
published extension, but it certainly would be needed if the
path segment was extended to support a new object.
Are there other extension forms to cover. If
draft-ietf-regext-rdap-extensions becomes authoritative in defining
the RDAP extension forms than it may belong under STD 95, since I
don’t believe the base RFCs adequately covered the extensibility.
Instead of clarification and guidance,
draft-ietf-regext-rdap-extensions could help define the extensibility
in a single place. Obviously, it needs to be careful to stay in
compliance with the base RFC language, where the lack of definition in
the base RFCs shouldn’t restrict the extensibility of RDAP.
--
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, October 8, 2024 at 2:49 PM
*To: *James Gould <jgo...@verisign.com>, "regext@ietf.org"
<regext@ietf.org>
*Subject: *[EXTERNAL] Re: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
*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,
Right, that’s what the Extensions draft is intended for – reasonably
capture areas where the extension concept needs to evolve wrt the
current standard, as well as clarify the current extension concept.
Since this draft has already gone through couple of structural
re-organizations, please let us know where things are still lacking or
could be clarified further.
Thanks,
Jasdip
P.S. This work could also be worthwhile in that the intended RESTful
Provisioning Protocol (RPP) effort should be able to emulate it for
extensibility.
*From: *Gould, James <jgo...@verisign.com>
*Date: *Tuesday, October 8, 2024 at 11:41 AM
*To: *Jasdip Singh <jasd...@arin.net>, regext@ietf.org <regext@ietf.org>
*Subject: *Re: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
Jasdip,
The use of sub-paths was not an envisioned form of extension in the
base RFCs as is the case for the other forms of extension that I
included in my prior mailing list messages (e.g., query parameters,
HTTP headers, “objectClassName” values). The forms of extensions in
the base RFCs are spread across them and is not inclusive of all the
needed forms of extension supported by HTTP and REST in general. I
believe the goal is that we don’t want collision between the
extensions, and we don’t want to overly constrict the forms of
extensions based on over interpreting the intent in the base RFCs. Do
we want to disallow a new form of extension that was not originally
envisioned, or do we want to require updating the base RFCs every time
a new extension form comes up? I personally don’t believe so.
How about re-structuring draft-ietf-regext-rdap-extensions to formally
define the forms of RDAP extensions with appropriate guidance for each
form and with extensibility of the forms for the future? We can be
creative for the future of RDAP extensibility without getting into RFC
language debate of “foo”, “bar”, and “fuzz”.
--
JG
cid87442*image001.png@01D960C5.C631DA40
*James Gould
*Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
<http://secure-web.cisco.com/1Rq42Kzhu61rEqXxqpCU6D7aRd3en319x2ZrLqCNkl7xBrwDwowzPETXUKBvW_rvZq1xEejsqaJGZe95UaBPwuO_vUxsFaE4SkGvrNBzZAM05u5l9Rekn7AmL7LflsLXlwGfwJyjnSF_UeSr2YcAHlLeg2PFPmQg0ZvtOA2TFbE-HTohcBJSnZAwJ4ZoCOt_PF3mRRmffbY2llrv4brmyU-5G3vwXYm6V5LMi6Nw5zD1EZOjdEJjPK5xKzU2_rHh2u2qWFik-76olwyLBWXr9kkJTc6SXUNanSDGY0liNdr8/http%3A%2F%2Fverisigninc.com%2F>
*From: *Jasdip Singh <jasd...@arin.net>
*Date: *Tuesday, October 8, 2024 at 11:13 AM
*To: *"regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
*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 Scott,
I absolutely get the need to be conservative when updating an Internet
standard. Please allow me to explain why this would be a good evolution.
Section 5 of RFC 9082 says:
“Custom path segments can be created by prefixing the segment with a
unique identifier followed by an underscore character (0x5F). For
example, a custom entity path segment could be created by prefixing
"entity" with "custom_", producing "custom_entity".”
IMO, this is necessary but not sufficient.
If there is an existing path with a segment “fuzz” for an existing
extension “foo” and another extension “bar” comes along that has a
need to create paths that start at the same level as the existing
segment “fuzz”, then using the prepend-extension-id-and-underscore
approach to create segment “bar_fuzz” is helpful. That would leave us
with:
For an existing extension “foo”, paths “fuzz/…” and “fizz/fuzz/…”.
For a new extension “bar”, paths “bar_fuzz/…” and “fizz/bar_fuzz/…”.
Now, the Extensions draft says:
“While [RFC9082] describes the extension identifier as a prepended
string to a path segment, it does not describe the usage of the
extension identifier as a path segment which may have child path
segments. This document updates [RFC9082] to allow the usage of
extension identifiers as path segments which may have child path
segments.”
By this use-extension-id-as-segment-for-child-segments approach, we
could replace paths “bar_fuzz/…” and “fizz/bar_fuzz/…” with:
“bar/fuzz/…” and “fizz/bar/fuzz/…”
The only difference is replacing ‘_’ with ‘/’ after “bar”, and still
retaining de-confliction.
This is essentially what’s done in Reverse Search with path
“{searchable-resource-type}/reverse_search/{related-resource-type}?<search-condition>”.
For example:
“domains/reverse_search/entity?...”
where “reverse_search” is used as the path segment and “entity” as a
child segment. Respectfully, the prepend-extension-id-and-underscore
approach would be rather clumsy here.
My main point being that there are use cases where the
prepend-extension-id-and-underscore approach is not a natural fit when
defining path segments. In fact, we “discovered” the
use-extension-id-as-segment-for-child-segments approach in the act of
penning the Extensions draft. We have been extremely careful in
picking the changes and clarifications for that draft.
Thanks,
Jasdip
*From: *Hollenbeck, Scott <shollenb...@verisign.com>
*Date: *Tuesday, October 8, 2024 at 7:48 AM
*To: *Jasdip Singh <jasd...@arin.net>, a...@hxr.us <a...@hxr.us>,
regext@ietf.org <regext@ietf.org>
*Subject: *RE: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
From: Jasdip Singh <jasd...@arin.net>
Sent: Monday, October 7, 2024 4:52 PM
To: Hollenbeck, Scott <shollenb...@verisign.com>; a...@hxr.us;
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
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.
Scott,
From: Hollenbeck, Scott <shollenb...@verisign.com>
Date: Monday, October 7, 2024 at 4:15 PM
To: Jasdip Singh <jasd...@arin.net>, a...@hxr.us <a...@hxr.us>,
regext@ietf.org <regext@ietf.org>
Subject: RE: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
...
I've read draft-ietf-regext-rdap-extensions-04 completely and have
several comments to share. An overarching comment is that any update
to Standard 95 responses means that the modified responses will not be
consistent with "rdap_level_0". A new identifier will be needed. I'd
very much prefer to avoid updates to Standard 95 unless there's an
absolute necessity to do so.
This draft does not change the RDAP data model and all updates are
either backwards compatible and/or codify existing practices, many of
them made by this working group. As there are no changes to the RDAP
data model and this draft is dealing with extensions and not the core
of RDAP, can you provide specific examples of these inconsistencies?
[SAH] The data model might not be changing, but that's not the only
consideration. Recall this sentence from Section 4.1 of RFC 9083: "The
string literal "rdap_level_0" signifies conformance with this
specification". It doesn't say anything about the data model. I
interpret that sentence to mean that if RFC 9083 changes,
"rdap_level_0" continues to signify conformance with RFC 9083, NOT
with whatever updates it.
Also, I'd like to point out that this working group has not updated
"rdap_level_0" even when making changes to the core RDAP data model,
as the move from PS to IS did in fact change the core RDAP data model
but did not change the identifier.
With regard to interoperability between a client and a server, what is
changing that is incompatible? What core RDAP JSON or query is
changing? Can you provide specific examples?
This document updates the core RDAP specs for two reasons: 1) they
define the rules around extension registrations, many of which this
working group has repeatedly broken, and 2) there are areas of those
documents concerning extensions that are very ambiguous. But this
document changes nothing with regard to current interoperability
between a client and server.
Also, changing that identifier signals a new version of the protocol,
which this is not, and introduces an incompatibility with any current
software that relies on it. I don't know the extent of that
incompatibility, but I suspect at the very least many conformance
tools will break.
[SAH] A specific example: I have a server that implements the foobar
extension, RFC 7480, 9082, and 9083. It expects to receive query path
segments that include "foobar_". It receives a query that includes
"foobar/fizz". It doesn't recognize that path segment, so the query
fails. That's protocol breakage.
[JS] Servers work from an expected lookup or search path per the
definitions in a supported extension. Therefore, "foobar/fizz" should
be as much a valid expectation if so defined in an extension, as long
as namespace collisions are prevented.
That said, "foobar_a/b" would be needed for an extension if another
extension already defines "a/b" for the same base path. E.g.,
"domains/foobar_a/b" for extension "foobar" to de-conflict from
"domains/a/b" for extension "a". For an example of "domain/a/b" path
for extension "a", see
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09#name-path-segments-2
<https://secure-web.cisco.com/1-6b-zkVxTZ_-hdQAx7qmBl4nTXJebGeQSByZ7UtXGe0EgSPCnLm38_rTiTBpp_FhWJvpsB-I94im7sVQP3pVbsRVA-K7XnTy5CsRo4J-zThUcR2c6qYy3rZ1i2BAIQPxXYUyhNDjAb-j2RRkOd-367hJPNH5sOpwCbuozz46OPZbG-nGaczH80zqGTvA0WewvsXQ_WOYlNl-9xh2VfpJ0dxChKhr0gn5cZs4Nl9kAvnrCY_fbUa3uCCSBbIgb4jra-Hs7_iaKVST10AltIe_jv4PrLSNOdOG2zcFnM5mb-c/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-rdap-rir-search-09%23name-path-segments-2>.
[SAH] This is precisely why we have issues with extensions that aren't
following the guidance in the core specs. Those that define their own
extension identification mechanisms can cause problems. "foobar/fizz"
isn't valid per the existing core specs, and should not be defined as
such in an extension specification.
Would you like regext to revisit Reverse Search?
Some of the RIRs have or are in the process of implementing Reverse
Search and RIR Search. There was plenty of discussion on the current
extension identifiers for Reverse Search and RIR Search, and their
use. I cannot think of any good technical reason to disallow
"foobar/fizz", and IMO grandfathering such paths would be pragmatic.
We could further clarify usage scenarios for "foobar_fizz" versus
"foobar/fizz" in the Extensions draft.
[SAH] We should be prepared to revisit any extension that deviates
from the core specifications. I get that there are people who are
implementing these extensions. There are many more people that have
implemented Standard 95.
Jasdip
P.S. Let me also re-post one other comment I made earlier:
[SAH] Yes, that's what I'm advocating for. I'd rather change the
non-conforming Proposed Standard extensions than update an Internet
Standard to validate them. Updating the Proposed Standard will be far
more disruptive than updating the optional extensions.
[JS] To Andy's disruption point, it is a balance between the extent of
grandfathering existing extensions and clarifying for the future
extensions.
[SAH] If there's a way to do that without updating Standard 95, fine.
Stick to clarifications. Keep in mind, though, that once you've
allowed a second form of extension identification (identifiers without
prefixes), you're opening up the possibility of even more extension
identification schemes. Any clarifications should attempt to eliminate
that possibility.
Scott
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
