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
* 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
* JSON names for defining new members in the response, which is covered
by RFC 7480 and RFC 9083.
1. Query Parameters
* 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,
1. HTTP Headers
* 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.
1. “objectClassName” Member Value
* 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*[email protected]]
James Gould
Fellow Engineer
[email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: Jasdip Singh <[email protected]>
Date: Tuesday, October 8, 2024 at 2:49 PM
To: James Gould <[email protected]>, "[email protected]" <[email protected]>
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 <[email protected]>
Date: Tuesday, October 8, 2024 at 11:41 AM
To: Jasdip Singh <[email protected]>, [email protected] <[email protected]>
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*[email protected]]
James Gould
Fellow Engineer
[email protected]
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 <[email protected]>
Date: Tuesday, October 8, 2024 at 11:13 AM
To: "[email protected]" <[email protected]>
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 <[email protected]>
Date: Tuesday, October 8, 2024 at 7:48 AM
To: Jasdip Singh <[email protected]>, [email protected] <[email protected]>, [email protected]
<[email protected]>
Subject: RE: [regext] Re: Comments Regarding
draft-ietf-regext-rdap-extensions-04
From: Jasdip Singh <[email protected]>
Sent: Monday, October 7, 2024 4:52 PM
To: Hollenbeck, Scott <[email protected]>; [email protected]; [email protected]
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 <[email protected]>
Date: Monday, October 7, 2024 at 4:15 PM
To: Jasdip Singh <[email protected]>, [email protected] <[email protected]>, [email protected]
<[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
