Re: [regext] Feedback about breakage analysis

Il 01/06/2022 18:46, Jasdip Singh ha scritto:
> Thank you, Mario. Let me review your feedback, and adjust the analysis accordingly. Probably, early next week. :)
>
> Jasdip

No problem. Take your time. I appreciated your effort in summarizing the 
different approaches.

Really think it could be helpful to evaluate all of them carefully and 
choose one hopefully.

Mario

> On 6/1/22, 12:33 PM, "regext on behalf of Mario Loffredo" <regext-bounces@ietf.org on behalf of mario.loffredo@iit.cnr.it> wrote:
>
>      Hi Jasdip,
>
>      I would suggest to add Approach C and split some scenarios into smaller
>      changes.
>
>      I mean, some of the scenarios presented merge breaking and non-breaking
>      changes.
>
>      I would classify the scenarios reflecting the basic breaking and
>      non-breaking changes as in the following.
>
>      Possible breaking changes that can occur in the RDAP context include:
>
>           Removing a response field
>           Modifying a path URI
>           Modifying a field name or type
>           Modifying a required query parameter
>
>      While non-breaking changes include:
>
>           Adding a path
>           Adding a response field
>           Adding an optional query parameter
>
>      Any combination of breaking changes should be treated as one
>      non-breaking change while any combination including at least one
>      breaking change should be treated as one breaking change (e.g.,
>      "Replacing jCard with JSCard" is equal to "Removing jCard " + "Adding
>      JSCard").
>
>      That being said, anyone can realize that Approach A (at least as is for
>      now) transforms the non-breaking changes in breaking ones. For example,
>      defining a new version of a request extension by adding an optional
>      query parameter to a given path implies that the path URI gets modified
>      (@Jasdip, this scenario corresponds to the second one presented in your
>      breakage analysis but limited only to the assumption "Query parameter q1
>      added"). Likewise, adding a new member to a response extension would
>      result in modifying the name of the response extension as well (@Jsdip,
>      this seems to me not included in your breakage analysis).
>
>      For that reasons, I wouldn't opt for Apporach A.
>
>
>      Cheers,
>
>      Mario
>
>
>      --
>      Dr. Mario Loffredoto a
>      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
>      regext@ietf.org
>      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