Re: [scim] Extension Schema Versioning in draft-ietf-scim-device-model

Hassan,

This is a great question. Actual versioning is something we (the SCIM community) have been able to avoid so far.

In my experience, the best reason to change versions is when breaking changes occur (like changing the format or name of an attribute).  If however, it is critical that participants need to understand the new attributes, then I would rev the verison (e.g. change 1.0 to 1.1).

I assume you are referring to draft-ietf-scim-device-model-00 <https://datatracker.ietf.org/doc/draft-ietf-scim-device-model/>, which means likely any updates would come from a new draft.  That would open the door to decide whether to change the version in the URN or not.  If it is not important that implementers support the new schemas, you could keep the old version number.  If it is important, is would up the dot version for backwards compatible and the major number for breaking change.

As background: In the SCIM core specs we had a major change from SCIMv1 so all the schemas have a 2.0 version because it was a breaking change from 1.0.  Note there was never a 1.0 urn because the whole idea of registerable schemas didn’t exist for SCIM v1.  :-)

Colloquially the SCIM v2 specs refer to the idea of SCIM Protocol V2 (this is actually mentioned in RFC7644 in order to support v1 and v2 endpoints), and V2 of the schemas. Technically these versions don’t need to be locked together.  If the WG decided to change the core schemas, it would be either 2.1 or 3.0 depending on breaking changes. 

The same is true for the API, v2 would be the same (for backwards compatible changes) except for a breaking change would make it likely v3.

That said, that’s just my impression of how it might be…. not necessarily what a future consensus decision would take.

Finally, some servers might be “dumb” with regards to schemas and just reject because the URNs don’t match up based on the configured ResourceType.
Example: a client wants to submit a 1.0 device to a server that supports 1.2

Some possible solutions:

1.  If the update is a “.” change, the client can just change the schema URN to 1.2 and submit it.

2.  The server could be smart and automatically upgrade a 1.0 schema to 1.2, or even a 1.x to a 2.x and so on.  

3. The server could be smart and be able to auto-switch between versions.  By default servers would always respond with the latest version, but you could use a fully qualified attribute name (includes the schema URI) to specifically request a 1.x attribute vs. a 2.x attribute assuming the server is able to transform between versions.

——>  We may want to document schema upgrade handling in a new spec.  This would be a way to describe how the ResourceType endpoint could be extended to list equivalent or upgraded schema URN values.

Phillip Hunt
phil.hunt@independentid.com

> On Sep 13, 2023, at 6:10 AM, Hassan <hassaniqbal931@gmail.com> wrote:
> 
> Hi Everyone,
> 
> The attributes in extension schemas represent the device's technology (BLE, WiFi, etc.). Given the evolution in technologies that influence extension schemas, would it be appropriate to have extension version numbers in the extension schema URIs to address potential future attribute modifications?
> 
> Thank you.
> 
> --
> Best
> Hassan Iqbal
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim