Hi james,
my comment inline.
Il 27/05/2022 14:43, Gould, James ha scritto:
Mario,
Thank you for providing an example of the complexity of versioning that is
associated with tightly coupling the RDAP compliance value with the set of
prefixes. Unfortunately, RDAP doesn't include the same sort of version
negotiation that exists in EPP with the use of XML namespace URIs in the
greeting and login services. I view the RDAP Conformance being closer to the
EPP greeting services. I'll continue down the EPP line of discussion, where
EPP leverages the XML namespace URIs for versioning that is tied to XML schemas
and leverages XML namespace prefixes for grouping of the XML elements. EPP
explicitly requires the use of a namespace-aware XML parser, which enables the
use of any XML namespace prefix. There is no direct tie in the RFCs to the
specific XML namespace prefix to use that is linked with the versioned XML
namespace URIs.
[ML] Agreed. I only meant to make WG see things from a different angle
beyond the considerations based on what RFCs currently permit presenting
what could be the operational consequences of opting for Approach A.
REST and JSON is schema-less, so are we attempting to bring in XML concepts
into REST and JSON with the tight coupling of extension RDAP conformance values
and the extension elements?
[ML] Clearly stated that we shouldn't. But what is most important,
Approach C that is currently implemented in draft-ietf-regext-rdap-redacted includes the registration of a full versioned
identifier for the RDAP Conformance, with "redacted_level_0_3" and the registration of the prefix "redacted"
to ensure uniqueness with other extensions. The "redacted" prefix looks a lot like "redacted_level_0_3", but
that is not required. The tie between the tie is based on the use of the same "Published specification" value in the
RDAP Extension Registry. I haven't heard of a concrete case to help the client out by having the RDAP Conformance value match
the prefix with the optional support for versioning in both. An extension should be additive, and the client would first key off
the set of versioned RDAP conformance values, to determine what is supported based on what is defined in the specification. We
have no equivalent of an XML schema, and I don't believe we should attempt to model that in RDAP.
[ML] Me too.
I view attempting to model XML schemas with predefined XML prefixes as brittle
and unneeded.
[ML] Fully agreed. I'd also say "unpractical" as it would reduce the
benefits from using REST and JSON.
Enable true versioning in the RDAP conformance and enable prefixes to be
independently registered in the RDAP Extension Registry without any predefined
linkage.
[ML] My only objection to Approach C is that every new version would
result in registering a new extension identifier. I would opt for a less
verbose solution, if any.
Summarizing, I'm OK with either approach B or C.
Best,
Mario
Thanks,
--
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
