Correction. This queue size should really be zero (as discussed in the Boca F2F) as a queue size of 1 is completely pointless. This means that for Embedded DataChange Republish will never return any queued notifications.

I'm not sure what is expect on this mantis issue

Republish has to do with messages sent to the server, not what is in the queue for items to be sent - the "Embedded Datachange Subscription Server Facet" sets the queue size to 1, 960 does nto affect this.

The conformance unit for "Subscription Publish Min 02" set the minimum number of publish requests that can be queue to the server (2). It also sets the number of unconfirmed notifications (i.e. sent messages not acknowledged by the client as being recieved) that are to be buffered to 2.

mantis 960 changed how minimum notifications to buffer is calculated, it was being calculated by the keepalive interval (no conformance units listed this - so existing conformance units were in error for all publish related conformance units) The new requirement is to keep a minimum of 2x time the number of publish requests that can be queued as buffered notifications. This will require changes to all of subscription related profiles (no mantis issue listed for it as of yet - could fix under this mantis issue). The specification also allows a profile to overwrite the limit.

So what action should be taken - I propose the following
1) no changed to the "Subscription Publish Min 02" conformance unit (still leave it at 2).

pick one of these:
2a) Updated the "Subscription Publish Min 05" and "Subscription Publish Min 10" to increase the notification buffer limit to 10 and 20 respectively - but these are release profiles - so actually can not make the change with out a lot of other changes at the profile level

alternate 2b) create a new conformance units (listed as optional in released profiles) that deals with notification buffer sizes (messages to buffer).

Alternate 2c) Create new conformance unit and new profile that is titled "Support Subscription Robust Recovery" or something like it and add conformnace unit that describes the buffering as required. Could also include other items related to robust communication recovery.

Alternate 2d) do nothing - since spec allows profile to overwrite this limit.

This issue arose because of memory constraints for the released "Embedded Datachange Subscription Server Facet".

Part 4 has been modified to say that notification message queue size (while nominally twice the publish request queue size) can be overriden by profiles.

In my opinion we should add a conformance unit to the Embedded Datachange Facet to specify that the minimum notification message queue size is zero for this case.

As Paul states there is no need to change "Subscription Publish Minimum 02".
Contrary to what Paul says above this CU makes no direction regarding the notification retransmission queue size and this CU has not at any time been in error.

Updated text as discussed in meeting

Reviewed and agreed to changes in telecon.