Page tree
Skip to end of metadata
Go to start of metadata
Minor changes

A minor change will impact the structure with new fields that are 'optional' or removal of fields that were 'optional'.

This way, the structure remains compatible for applications processing the structure.

In this situation, a new version of the same identifier will be specified.

Consumers of the structure SHOULD be able to process all versions of Identifier
(Identifier, Identifier-v2 ... Identifier-vX). (Identifier OID.*)

Policy for new optional fields is that they are implicitly tagged, and that all optional fields are added at the end of the (sub)-structure.

<Identifier-vX> OBJECT IDENTIFIER ::= { Identifier X}

where X is the version number

Example:

Current version:

id-BSNk-encrypted-identity-v2 OBJECT IDENTIFIER ::= { id-BSNk-encrypted-identity 2 }

OID: 2.16.528.1.1003.10.1.2.1.2

Next version:

id-BSNk-encrypted-identity-v3 OBJECT IDENTIFIER ::= { id-BSNk-encrypted-identity 3 }

OID: 2.16.528.1.1003.10.1.2.1.3

Applications that can process OID: 2.16.528.1.1003.10.1.2.1.2, SHOULD be able to process OID: 2.16.528.1.1003.10.1.2.1.3 as well

(OID: 2.16.528.1.1003.10.1.2.1.are all compatible)

Major changes

A major change is a change that impacts the structure in a way that it can't be kept backward compatible. In this case a new identifier will be introduced.

The previous identifier (and it's dependent structures) will be marked 'deprecated'

<NewIdentifier> OBJECT IDENTIFIER ::= { NewIdentifier 1}

where NewIdentifier is the functional description of the new identifier.

Example:

Current version:

OID: 2.16.528.1.1003.10.1.2.3.1

id-BSNk-encrypted-identity-signed OBJECT IDENTIFIER ::= { id-BSNk-encrypted-identity-signed 1 }

New Version

id-BSNk-encrypted-identity-ecsdsa-signed OBJECT IDENTIFIER ::= { id-BSNk-encrypted-identity-ecsdsa-signed 1 }

OID: 2.16.528.1.1003.10.1.2.7.1

(this is the successor of the id-BSNk-encrypted-identity-signed - which breaks compatiblity with the previous version)


  • No labels