History: add LastReport attribute to simplify processing

[PaulMartinsen]

Currently, consumers use a subscription-end notification to determine when a provider has finished delivering the available history notifications. Suggested adding a LastReport attribute to the ChangeSequenceReportType as well.

From discussion at plug-a-thon 18:

• no strong dissenting views, though it was noted this may not be strictly necessary as consumers can figure out when the history service has finished by listening for optional EndTo notifications, or processing wse:UnableToRenew faults.
• it may be necessary to make subscription end notifications [WS-Eventing-2004:§3.5] mandatory for the history service because they are optional (best effort) in the draft eventing specification used by SDC.
• it may be necessary to impose additional restrictions on the end-point for subscription end notifications to avoid race conditions. For example, consumers should use the same end-point (IP address and port) to avoid race conditions (such as the subscription end notification arriving before the last change sequence report).
• including the attribute in the report may be considered as mixing data and transport information.

[PaulMartinsen]

In my view, adding a LastReport (for example) attribute to the history service schema and related constraints is a straight forward resolution of the issues raised. Specifically:

• it wouldn't be necessary to make an exception to make subscription end notifications mandatory for the history service,
• it is more robust than relying on consumers unable to renew,
• in my view the ChangeSequenceReport is a wrapper required by the soap transport format so an attribute attached could be considered as not part of the data stream,
• race conditions can be avoided, without further specialization, by consumers that use the LastReport attribute instead of relying on (currently optional, best-effort) notifications.

<xsd:complexType name="ChangeSequenceReportType">
  <xsd:annotation>
    <xsd:documentation>Type definition of a report to communicate MDIBs along with sequences of changes./xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:element ref="hm:ChangeSequence" minOccurs="0" maxOccurs="unbounded">
      <xsd:annotation>
        <xsd:documentation>Zero or more ChangeSequence elements to describe changes of different MDIB sequences and/or instance numbers.</xsd:documentation>
      </xsd:annotation>
    </xsd:element>
  </xsd:sequence>
  <xsd:attribute name="LastReport" default="false" type="xsd:boolean" use="optional" />
</xsd:complexType>

The following constraints apply:

• A provider shall set LastReport to true for the ChangeSequenceReport to complete the requested history subscription and false for all other reports sent during the subscription,
• A provider may send an empty ChangeSequenceReport as the last report (e.g., it wasn't aware the previous report was going to be the last for some reason),
• A provider may complete a sequence history subscription, setting LastReport to true, because it has sent all the requested information or it no longer has the information requested,
• A provider should send a subscription end notification, if an EndTo address was provided by the consumer.

[ToddCooper]

SDPi Frida 2024.12.06 -
Reviewed finding from PAT #18