I’m currently implementing the Responder side of MIDI-CI Property Exchange Subscription, and I have a question about the recommended synchronization behavior after Subscription Start.

As I understand it, there is a possible race condition around the initial baseline state.

For example:

1. The Initiator performs Get and obtains the current full state of a resource.
2. The Responder’s resource changes after that Get response.
3. The Initiator sends Subscription Start.
4. The Responder accepts the subscription and then starts sending Subscription Partial updates for subsequent changes.

In this sequence, the change that happened between the initial Get and the Subscription Start may not be observed by the Initiator, unless the Initiator performs another Get after Subscription Start to establish a reliable baseline.

From an interoperability point of view, it seems safest if Initiators are recommended to perform Get after Subscription Start has been accepted, and then apply subsequent Subscription Partial updates on top of that state.

Is there any plan to clarify this in the specification or implementation guidelines?

If this behavior is not recommended or required for Initiators, then as a conservative Responder implementation, I may need to send Subscription Notify immediately after accepting Subscription Start, in order to prompt the Initiator to retrieve the current full state.

However, if both sides behave conservatively, this can result in redundant Gets:

• The Initiator sends Get after Subscription Start to establish the baseline.
• The Responder also sends Subscription Notify after Subscription Start to prompt a Get.
• The Initiator may then perform an additional Get because of the Notify.

This is not necessarily incorrect, but it seems inefficient and could lead to inconsistent implementation patterns between devices.

So my questions are:

1. Is the intended/recommended behavior that an Initiator should perform Get after Subscription Start has been accepted, in order to establish a reliable initial baseline?
2. If so, would it be appropriate to clarify this as a recommended practice in the specification or implementation guidelines?
3. If not, what is the recommended Responder behavior to avoid missed changes around Subscription Start?
4. Should a Responder send Subscription Notify immediately after accepting Subscription Start, or should it avoid doing so to prevent redundant Gets?

My main concern is ensuring that the Initiator and Responder can share a complete and correct resource image without relying on implementation-specific assumptions.