Hi Jasdip,
please find my comments embedded.
Il 31/05/2022 22:20, Jasdip Singh ha scritto:
Hi Mario,
Few comments, and one suggestion.
Thanks,
Jasdip
On 5/30/22, 4:50 AM, "Mario Loffredo" <[email protected]> wrote:
Hi Jasdip,
the current approach appears unpractical to me as it results in managing
all the changes in the same manner regardless their scope.
[JS] Consistency is the key point. Per the Breakage Analysis section in the
RDAP Extensions Analysis doc I had shared earlier [1], the current approach --
tight coupling between extension identifier and rdapConformance value -- seems
to afford us zero collisions and near-zero breakage for various change
scenarios, and that should be a good thing, no?. To your point, yes, there are
few scenarios (especially during transition for an extension vis-à-vis an
existing path without that extension identifier in it) where sending data for
both the old and new extension identifier in a response sounds inefficient but
that's the trade-off with a consistent, collision- and breakage-free extension
model.
[1]
https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing
[ML] Approach A will raise breakage issues as, at least according to a
strict interpretation of what is stated in the existing RFCs, every
change will result in replacing old features with new ones through a
deprecation process.
I agree with you that it will be consistent and collision-free but In my
opinion it will introduce more complexity for both clients and servers
whereas things could be managed straightforwardly.
Tom has replied to this objection of mine presenting some workarounds
that could be used to figure out some use cases without necessarily
starting a deprecation procedure.
Nevertheless, it seems to me those workarounds require the handling of
additional features beyond those involved by the change itself (e.g. in
the case of a non breaking change to response extension, the usage of a
specific field containing the conformance value).
REST API implemeters are well aware that breaking changes should be
avoided as far as possible. Most of changes to REST services consist in
adding new features rather than deleting, replacing or changing old ones.
That being agreed , can't really understand why we should go in the
opposite direction and basically reset the gains from using REST and,
above all, JSON.
Most of version changes could be signaled on server side by simply
adding a value in the rdapConformance array instead of dealing with a
deprecation process and providing clients with information about sunset
and complete replacement of old features.
A unified apporach is always advisable except in those cases where it
results in adding complexity where it is unneeded. And I suspect that
this would be one of those cases.
Indeed, handling every change (at least reading strictly the RFCs)
through a transition process would be a mess for server operators.
[JS] It doesn't look like we need any extraneous transition process beside
listing the from and to extension identifiers in the rdapConformance array.
Please see below one plausible way for jcard-to-jscontact transition using
solely the current approach.
[ML] Think that deprecations are tricky and transition processes should
be used carefully and only when the change to the REST API is relevant
such as the replacement of jCard with JSCard.
Let's imagine, for example, how a possible non-breaking change in
JSContact representation impacting on the RDAP response could be managed
while the possible transition from VCARD to JSContact was still in place.
Server operators may have to deal with a transition within another
transition ?!?!
[JS] One plausible way for jcard-to-jscontact transition using solely the
current approach (tight coupling):
Phase 1: Only jcard
---------------------------
p = entity/<handle>
{
“rdapConformance” : [
“rdap_level_0”
],
{
…,
"vcardArray" : [
…
]
}
}
Phase 2: jscard_0 extension (available along with jcard)
---------------------------------------------------------------------------
p = entity/<handle>
{
“rdapConformance” : [
“rdap_level_0”,
“jscard_0”
],
{
…,
"vcardArray" : [
…
],
“jscard_0” : {
…
}
}
}
Phase 3: no_jcard extension (jcard data no more in response)
-----------------------------------------------------------------------------------
p = entity/<handle>
{
“rdapConformance” : [
“rdap_level_0”,
“jscard_0”,
“no_jcard”
],
{
…,
“jscard_0” : {
…
}
}
}
Phase 4: jscard_1 extension (has a new field beside the jscard_0 data)
---------------------------------------------------------------------------------------------
p = entity/<handle>
{
“rdapConformance” : [
“rdap_level_0”,
“jscard_0”,
“no_jcard”,
“jscard_1”
],
{
…,
“jscard_0” : {
…
},
“jscard_1” : {
…,
“new_field” : …
}
}
}
Phase 5: Transition from jscard_0 to jscard_1 after a sufficient grace period
for clients
-------------------------------------------------------------------------------------------------------------------
p = entity/<handle>
{
“rdapConformance” : [
“rdap_level_0”,
“no_jcard”,
“jscard_1”
],
{
…,
“jscard_1” : {
…
}
}
}
Non-breaking changes can be more easily managed and signaled by server
operators by adding a minor version in rdapConformance array and an
optional link to the related documentation in the response. That's it.
[ML] The rdap-jscontact draft defines two query parameters to make an
RDAP server return only one between JSCard and jCard. I consider it a
valuable choice as it restricts the response payload (significantly for
search response) and permits clients to receive JSCard only when they
are ready to process it.
That apart, your example represents the scenario where the transition
from jscard_0 to jscard_1 comes later the transition from vcardArray to
jscard_0, not simultaneously.
Anyway, if returning three times almost the same considerable
information wouldn't be likely, returning it twice would occur each time
JSCard (or even jCard) was changed.
[JS] One suggestion. To help settle and/or move forward the discussion
vis-a-vis if we should stick with the current approach (tight coupling), or
evolve using the proposed approach (lack of tight coupling), it would be great
if we could review and discuss the Breakage Analysis section in
https://docs.google.com/document/d/1iadJc1D2-z_9pSy0PNcl4mhEQglh7dIHhbmRgrCW6mc/edit?usp=sharing
and decide whether the breakage points matter for various change scenarios or
not.
[ML] By a strict interpretation of Approach A, every change would result
in a replacement of something. Since replacing a feature with another
one, a.k.a. deprecation, is considered a breaking change in the REST
contract, Approach A would appear to me penalized in that sense, unless
we agree on more sustainable solutions reflecting a different
interpretation of Approach A like for example those outlined by Tom (see
above).
However, I remain more inclined to follow Approach B or C (the latter
seems more likely ).
Best,
Mario
Cheers,
Mario
Il 27/05/2022 16:31, Jasdip Singh ha scritto:
> 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"
<[email protected] on behalf of [email protected]> 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
> [email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 5/27/22, 10:10 AM, "Mario Loffredo" <[email protected]>
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
> [email protected]
> https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> 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
--
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
