Add sdpi:ReportSequence extension to separate message sequencing and versioning

[PaulMartinsen]

📑 Description

This pull-request proposes replacing R1005, which relies on the MDIB version for lost notification message detection, with a new mechanism suitable for full and partial subscribers that separates lost message detection from MDIB versioning. A extension element, sdpi:ReportSequence is proposed for inclusion in the message header, with one attribute, @MessageNumber that can be used by both full (consumers that subscribe to all available reports) and partial (consumers that subscribe to a subset of reports) subscribers.

Summary:

• New §3:8.3.2.10.7 Report sequence: describes an extension for report sequence numbers to be included in the header of every notification report
• Updated §2:A.5.2 MDIB Report Retrofit
  ** removed requirement R1005
  ** added requirements R1030, R1031, R1032, R1033
• New §3:A.4 Report Sequence XML Schema: schema for new extension

☑ Mandatory Tasks

The following aspects have been respected by the pull request assignee and at least one reviewer:

• Changelog update (necessity checked and entry added or not added respectively)
  • Pull Request Assignee
  • Reviewer - I'm going to ask interested folks from plug-a-thon 19 to share their thoughts first .

[JavierEspina]

2025.06.13 SDPi call:
This MAY be a breaking change. Needs more review to confirm. Will consider it as an SDPi option.

[PaulMartinsen]

I'm not clear how this would work as an option. I think providers will have to include the report sequence in the header or risk incompatibility with consumers that choose to check it. Consumers are still free to rely on TCP transport guarantees and not check the sequence. But providers would have to support it, in the same way R1005 is really mandatory for providers that value interoperability now.

Without this change partial subscribers have no way to track missed messages (they can't use MDIB version because the version may change either because they missed a message or the version was assigned to a report they don't subscribe to,

It may also be harder to resolve apparent inconsistencies between R1005 in SDPi and R0065 in 20701.

[JavierEspina]

SDPi call July 18: to be discussed in Ocotber. So it has to be moved to SDPi 3.0 or later.

[BenjaminHohlmann]

Please see my comment on the related ticket:
#321 (comment)

[JavierEspina]

SDPi call Aug 22:
As a compromise solution, the meeting had consensus to accept the proposal under the condition that it is made optional. Then the free market can decide to adopt it in practice or not.

[PaulMartinsen]

Okay. I've change key requirements from shall to should to make it optional:

• R1030 (provider shall should include message number in notifications),
• R1032 (consumer shall should treat messages with duplicate numbers as identical),
• R1033 (consumer shall should acknowledge receipt or terminate the subscription like R1005 had).

[JavierEspina]

2025.08.29 SDPi Call: Looks good. Davod will do a final review towards approval.