Hi Scott,
I'm concerned about injecting the version information into
prefixes/identifiers as I see some drawbacks in dealing with
non-breaking changes, which hopefully should be the majority and usually
don't require to manage a deprecation process.
For example, introducing a new property into a response extension would
result in returning the same information twice (e.g. the response field
"ext1_..." and response field "ext2_..." resulting from adding the new
property to "ext1_..") .
To ensure interoperability, both the response fields should coexist for
a period time so that the RDAP server could manage the sunset and then
the deprecation of "ext1_..." as smoothly as possible.
Furthermore, according to a largely used best practice in versioning
REST APIs, breaking changes should always result in a change to the
major version number while non-breaking changes, such as adding new
endpoints or new response parameters, do not require a change to the
major version number.
Unfortunately, injecting the version information into the
prefixes/identifiers means that every change would break the RDAP server
and would result in a change of the major version number !?!?
Really, this doesn't make sense to me.
Think the RDAP mechanism to implement and signal extensions should take
vantage from an RDAP server being a REST service that returns a JSON
(schemeless) content and, as such, it is possible to make many changes
without breaking the REST contract with the client and forcing the
server to manage a deprecation process even when it is unnecessary.
Hope it could be helpful to evaluate the various approaches on the table
from a practical perspective.
Best,
Mario
Il 25/05/2022 16:41, Hollenbeck, Scott ha scritto:
*From:* Gould, James <[email protected]>
*Sent:* Wednesday, May 25, 2022 10:23 AM
*To:* Hollenbeck, Scott <[email protected]>;
[email protected]; [email protected]
*Cc:* [email protected]
*Subject:* Re: [regext] Extension Prefixes, JSON Values, and URI Path
Segments
Scott,
My comments are embedded below with a “JG – “ prefix.
--
JG
*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: *"Hollenbeck, Scott" <[email protected]>
*Date: *Wednesday, May 25, 2022 at 9:10 AM
*To: *James Gould <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *RE: [regext] Extension Prefixes, JSON Values, and URI Path
Segments
*From:* Gould, James <[email protected]>
*Sent:* Wednesday, May 25, 2022 8:49 AM
*To:* Hollenbeck, Scott <[email protected]>;
[email protected]; [email protected]
*Cc:* [email protected]
*Subject:* Re: [regext] Extension Prefixes, JSON Values, and URI Path
Segments
Scott,
If the authors of 9083 feel that “lunarNIC_level_0” should be the
prefix value “lunarNIC” instead of a versioned literal, then I’m
confused on the true purpose of the RDAP Conformance member. If the
RDAP Conformance member is meant to signal the use of a namespace
prefix and not a versioned literal, then why didn’t the base RFC RDAP
Conformance value (“rdap” instead of “rdap_level_0”) and RFC elements
(“rdap_domain” instead of “domain”) follow the same pattern?
*/[SAH] The values described in the RDAP specifications aren’t
extensions. As such, the extension mechanisms aren’t applicable./*
*//*
JG – The question is associated with the purpose of the RDAP
Conformance. If the intent of the RDAP Conformance is to signal the
set of prefixes used in the response in place of the list of extension
literals, then the base RFCs should have followed the intent. There
is no existing language in the RFCs that requires consistency between
the entries in the RDAP Conformance and the prefixes used by the
extension.
*/[SAH] “RDAP conformance” is intended to identify the
specification(s) associated with elements found an in RDAP response.
That’s why the registry of values includes identification of the
associated specification./*
*//*
Changing the purpose of the RDAP Conformance values would invalidate
the use of the literals registered for the RDAP profile.
*/[SAH] No, it wouldn’t. The RDAP profile doesn’t register extension
elements./*
*//*
JG – If the RDAP profile doesn’t register extension elements, do the
RDAP Profile literals belong in the RDAP Extension Registry? I
believe the RDAP Profile literals has value to the client and
therefore should be in the RDAP Extension Registry and represented as
an entry in the RDAP Conformance, but that would violate the intent of
the RDAP Conformance values as prefixes and not versioned literals.
*/[SAH] Yes, the values should be registered. Including them in the
rdapConformance section of an RDAP response describes how that
response was formed. There’s value in that even if the response
doesn’t contain any extension elements./*
If there is consensus to define the RDAP Conformance as containing
only prefixes to ensure the consistency of values, then the RFC 9083
normative sentence below needs to be revised to change “string literal
value” to “prefix”:
When custom JSON values are inserted into responses,
conformance to those custom specifications MUST be indicated by
including a *prefix* value registered in the IANA RDAP
Extensions registry specified in [RFC7480
<https://datatracker.ietf.org/doc/html/rfc7480>].
I believe it’s best for the RDAP Conformance to reflect a versioned
literal at the level of the extension specification to indicate to the
client what version of the extension is supported instead of
attempting to define the extension namespace prefixes. The RDAP
Extension Registry can ensure the uniqueness of the prefixes and
contain the list of versioned extension literals. This should be
handled by the definition of draft like the RFC 3735 “Guidelines for
Extending the Extensible Provisioning Protocol (EPP)” that is focused
on all the forms of RDAP extensibility (e.g., object extensibility,
request and response attribute extensibility, policy signaling). I
don’t believe the base RFCs thought through the extensibility deep
enough to tweak via errata.
*/[SAH] The registered prefix/identifier can in fact contain version
information. That’s exactly what I’m doing in the federated
authentication draft./*
*//*
JG - Injecting versioning into the extension elements adds brittleness
when backward compatible version changes are made. Including the
versioning in the RDAP Conformance provides the signaling, and the
registered prefixes ensures uniqueness. Artificially linking the two
adds brittleness with no perceived value.
draft-ietf-regext-rdap-openid would be cleaner by registering
“roidc_level_0” for the RDAP Conformance value and a single prefix
“roidc” value used for the set of extension elements (“roidc_id”,
“roidc_session”, “roidc_iss”, “roidc_session”,
“roidc_openidcConfiguration”). The individual extension elements
could be registered as well but based on the number and use of
something generic like “id”, it may be best to group them using a
single prefix.
*/[SAH] I can only say that I disagree. There’s more value in
consistency and simplicity. It makes life *much* easier for a client
if the value registered with IANA is the same value that’s used to
identify extension elements. If changes are made in the future, you
just need to register a new value./*
*//*
*/I agree that this all needs to be clarified. The first step is to
document the areas that require clarification as errata. Then we write
a draft that addresses the errata./*
--
JG
*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: *"Hollenbeck, Scott" <[email protected]>
*Date: *Wednesday, May 25, 2022 at 8:07 AM
*To: *James Gould <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
*Cc: *"[email protected]" <[email protected]>
*Subject: *RE: Re: [regext] Extension Prefixes, JSON Values, and URI
Path Segments
*From:* Gould, James <[email protected]>
*Sent:* Tuesday, May 24, 2022 4:37 PM
*To:* [email protected]; [email protected]
*Cc:* Hollenbeck, Scott <[email protected]>; [email protected]
*Subject:* Re: Re: [regext] Extension Prefixes, JSON Values, and URI
Path Segments
Approach A – “tight coupling” and Approach B “lack of tight coupling “
treats the RDAP Conformance value not as hint to the specifications
used in the construction of the response, as defined in section 4.1 of
RFC 9083, but instead as defining the prefix value of the extension
elements (URI path segments, JSON response members, and
objectClassName values). My read of the RDAP Conformance is that
version is material and there doesn’t need to be any direct link
between the literal values in the RDAP Conformance with the prefixes
used for the extension elements. If the versioning of the RDAP
Conformance needed to cascade down to the extension elements, why
didn’t the base RDAP RFCs cascade the version “rdap_level_0” down to
all the base RFC elements? What would happen if a new version of RDAP
was created, with the RDAP Conformance value of “rdap_level_1”, should
all of the RFC elements embed the version “_1” version as well, as in
“domain_1”, “domains_1”? I believe the answer is “no”. The example
provided for the fictional registry of the Moon is “lunarNIC_level_0”
and not simply the prefix “lunarNIC”. We already have examples of
pure RDAP Conformance literals that don’t relate to extension element
prefixes with the RDAP profile identifiers, which certainly have value
to the client.
*/[SAH] The authors of 9083 believe that the “lunarNIC_level_0”
example is an error. It should be “lunarNIC” so that the
IANA-registered value, the rdapConformance value, and the prefix used
in examples is consistent. We’re currently looking at everything that
needs to be documented as errata; this will be one of the items./*
My recommendation is to separate the RDAP Conformance values from the
registration of the prefixes used for the extension elements, which
can be registered separately for uniqueness. We get full version
signaling in the RDAP Conformance member and we get full support for a
mix of extension elements that are registered for uniqueness. I don’t
see a compliance issue with the language in the RDAP RFCs with
Approach C taken in draft-ietf-regext-rdap-redacted and I don’t see
any technical issues that will impact the client by having a versioned
RDAP Conformance registration (“redacted_level_0_3” with a future
value of “redacted_level_1”) and a registration of the “redacted”
member that is used in the JSON response. Does anyone see any
explicit compliance issues or technical issues with this?
*/[SAH] See above./*
*//*
*/Scott/*
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
