The discussion was always that if not enough publishes are available to support the defined subscription - the lowest priority should starve and eventually time out - so a keep-a-live should not be sent (using one of the publishes). i.e. if I create 5 subscription but the first two have so many notifications that the channel is just busy - then the lowest priority subscription should timeout. This was the intent and the discussion when priority was discussed - the Highest priority should always be service - it should not miss - dequeue a publish for keep-a-live could cause a miss. Typically this is a client side issue - i.e. if the client has the bandwidth then it queue enough publishes to handle all subscriptions. If the client does not want a timeout then it does not specify a priority or specifies the same priority for all subscriptions. In general the wording related to priority needs to be cleaned up - the only exception for priority processing that is implied in the specification is if a response did not fit in a publish then that response can be continued (without checking if a higher priority queue needs to be processed). I'm not sure if that is desired behaviour, but that is what is in the specification as I read it.

Need to be discussed at F2F

Agreed in F2F that even KeepAlive will get higher priority

Table 88 – CreateSubscription Service Parameters

In
Priority: " When more than one Subscription needs to send Notifications, the Server should de-queue a Publish request to the Subscription with the highest priority number."

Replaced
'Notifications' with ''a Publish response"

This should make sure that the Subscription with the higest priority always is first in sending Publish responese, even for keep-alive

Agreed to changes in Web meeting.