Hi.
I'd contend that unlike the proposed approach(es), current approach:
- guarantees no collisions under every change scenario (not just optional new
field)
- guarantees sufficient transition time for clients when moving to the next
version of an extension (without requiring any additional signaling beyond RDAP
conformance) and thereby, guarantees near-zero breakage (breakage only possible
if a client ignores the transition time)
- has a simple registration model for each opaque extension identifier
Jasdip
On 5/27/22, 10:25 AM, "regext on behalf of Gould, James"
<regext-boun...@ietf.org on behalf of jgould=40verisign....@dmarc.ietf.org>
wrote:
Mario,
[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.
I'm not aware of the plan for new versions of the existing extensions, so I
don't view it as a scalability issue. While an extension is an Internet Draft,
the pointed versions will not be registered until the draft becomes an RFC.
This is similar to what happens with the EPP extensions, where pre-RFC
implementers can use the pointed version contained in the draft for signaling
that will eventually become a full registered version (e.g., "0_N" becoming "1"
or "1_N" becoming "2") in the registry. When there are multiple versions of an
extension, I believe it is important to capture those versions in the RDAP
Extension Registry with a link to the associated specification. Mixing
versioning with the prefixes I believe is unnecessary and brittle, so I don't
support Approach A. Approach B provides the flexibility to define the full
RDAP Conformance version in the specification, so it supports versioning
without the brittle side effects, but I view Approach C as being better since
the versioning is more explicit in the registry. If there is the risk of an
overload of versions in the registry, then I would agree with the concern of
Approach C, but I don't believe that risk exists.
--
JG
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/>
On 5/27/22, 10:10 AM, "Mario Loffredo" <mario.loffr...@iit.cnr.it> wrote:
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://secure-web.cisco.com/16t5sBrz_iAuxdO4FzKpp7t63WvEdOI56N9ldgS_C5bon4NCc-fivU9_kFZf8_evpDmkcPCcQiuBoJ7ofMrxCHVesyRtQIvx85qEcFV0qX_2PuNNpIb30pT3SRzrneNKg75w7-OAskVaeHoaFH9yk1uOXj-IB65xr1AE0B_z08bGMucXu9VhZ-ghBF2wZjUuw9-C2po2YN2kn9i4nBpQQqX0Kc1A-h2sVt4NJuokO7CbStWfhVUom1hVeNIZuUWn3/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
