Hi Andy,
inline ....
Il 16/12/2025 15:17, Andy Newton ha scritto:
Hi Mario,
Thanks for your response. My reply is inline.
On 12/15/25 9:54 AM, Mario Loffredo wrote:
Object classes can also be embedded in other object classes (entities are the classic case),
clients can dereference them via a referral, and they can appear in search results. Substituting
"blockchain_domain" where the client expects "domain" may cause problems.
[ML3] If they are embedded in other classes, they are essentially new elements
of those classes. Therefore, they should be parsed and then ignored per section
2.1 of RFC9083.
I think we can clarify in the draft that introducing a new object class where
the client would expect another will cause problems, and then list the
scenarios discussed in this thread. Hopefully that makes the issue clearer.
[ML4] Replacing a new object class with another is a breaking change,
and as such, this case is already covered in Section 5.4.3. Regarding
Section 5.4.4, I would simply recommend that any extension updates be
reported to clients. See my reformulation of Section 5.4.4 at
https://mailarchive.ietf.org/arch/msg/regext/OC8gaYiPb2rW9F0D16EgEMN0foc/
[ML3] All response extensions standardized so far leveraged JSON objects.
In contrast to this best practice, Section 5.4.2 seems to encourage extension
designers to scatter information across a set of simple properties, related
only by their common prefix.
I disagree with this approach, which apperas also inconsistent with Section
2.5.2 and, in general, with object-oriented data modeling.
Assuming we are still talking about 5.4.4, how does using one JSON object and
then evolving the extension by adding new members into that object make things
any different? It is the same problem of new JSON members in the response with
no signaling of what is going on.
[ML4] My objection was to the solution proposed in Section 5.4.2 to
achieve the goal of reducing the response size.
Overlapping extensions/versions is naturally supported by maturity
versioning when a non-breaking change occurs. By leveraging JSON's
ability to ignore unknown elements, the same response object can be
parsed and deserialized by clients regardless of whether they have
switched to the new version. In practice, servers don't need to worry
about the transition from the old to the new version because, as long as
new non-breaking changes are added, backward compatibility is
guaranteed. They simply need to notify clients that a new version is
available to prevent them from loosing information.
In contrast, this is naturally not supported by opaque versioning. What
you propose in section 5.4.4 is an alternative solution applicable only
when the response extension consists of a set of simple, sparse
elements. This strategy for representing extension information has not
been used by any of the standardized response extensions to date. Based
on Based on the best practices of data modeling, we have always grouped
properties into object best practices, we have always grouped properties
into objects.
Of course, servers may opt for this strategy, but I wouldn't recommend
it in case of opaque versioning.
In addition to overlapping extensions/versions (valid only for maturity
versioning), other strategies for managing the evolution of response
extensions are:
- Signaling extensions/versions
This method can be used via the exts_list and versioning parameters.
Opaque versioning can leverage this method to handle both breaking and
non-breaking changes, while maturity versioning requires this method to
handle breaking changes. Based on query logs, servers are fairly
confident in the timing of switching to the new version as default and
then permanently removing the old one.
- Duplicating extensions/versions
This can be used to manage any changes when using opaque versioning. At
some point, servers should remove the old version. In this case,
backwards compatibility may not be guaranteed when the old version is
removed, since servers have no proof that clients are still using the
old version; they can only assume that, after an appropriate period of
time, all clients have switched to the new version.
I hope I've clearly summarized my opinion on the evolution of extensions.
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
