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.