Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 1010 Effect of non-correlation on the event model

["Worley, Dale R (Dale)" <[e-mail]>]

Paul K. has suggested that we treat call-completion subscriptions as
being subscriptions to "the status of the queue" (the queue for the
destination AOR), but that filtering is in effect such that each
subscriber sees only the status of the queue entry that coresponds to
his subscription.

This idea seems to me to be enough to align our use of subscriptions
with the formal model of RFC 3265, and thus allow us to have
call-completion subscriptions operate like everyone wants them to
without adding any further machinery.

It also provides a way to add future extensions that provide
special subscriptions that show the entire queue.

Within that model, we need to make the following wording changes:

(I've shortened CECE ("calls eligible for completion entity") to CCE
("call-completion entity").)

   Section 5

   The callee's monitor manages CC for a single URI.  This URI is
   likely to be a published AOR, or more likely "an AOR without its
   voicemail", but it may be as narrowly scoped as a single UA's
   contact URI.  The monitor manages a dynamic set of call-completion
   entities (called "CCEs") which represent CC requests, or
   equivalently, the existing incoming call-completion subscriptions.
   This set is also called a queue, because a queue data structure
   often aids in implementing the monitor's policies for selecting
   CCEs for CC recall.

   Each CCE has an availability state, which is either "available"
   (for recall) or "not available" (for recall).  It is not visible
   via subscriptions.

   Each CCE has a recall state which is visible via subscriptions.
   The recall state is either "queued" or "ready".

   Each CCE carries the From URI of the SUBSCRIBE request that caused
   its creation.

   CC subscriptions arrive at the the monitor by being addressed to
   the managed URI, or URIs the monitor returns in Call-Info headers.
   The request URI of the SUBSCRIBE request determines the queue to
   which the resulting CCE is added.  The resulting subscription
   reports the status of the queue.  The base event data is the status
   of all the CCEs in the queue, but the data returned by each
   subscription is filtered to report only the status of that
   subscription's CCE.  (Further standardization may define means for
   obtaining more comprehensive information about a queue.)

   When a CCE is created, it is given the availability state
   "available" and recall state "queued".

   The monitor may receive PIDF bodies [RFC3863], via PUBLISH requests
   directed at its URI.  These PUBLISH requests are expected to be
   sent by subscribers to suspend and resume their CC requests.  A CCE
   is identified by the request-URI (if it was taken from a
   call-completion event notification and identifies the CCE) or the
   From URI of the request (matching the From URI recorded in the
   CCE).  Receipt of a PUBLISH with 'status' of 'open' sets the
   availability state of the CCE to 'available'; 'status' of 'closed'
   sets the availability state of the CCE to 'not-available'.

   The monitor MUST select for recall only CC requests whose CCE's
   have availability state 'available', and for which the callee
   appears to be available considering the 'm' value of the CCE.
   Within that constraint, the monitor's selections are determined by
   its policy.  Often, a monitor will choose the acceptable CCE that
   has been in the queue the longest.  When the monitor has selected a
   CCE for recall, it changes the CCE's recall state from 'queued' to
   'ready', which triggers a notification on the CCE's subscription.

   If a selected subscriber then suspends its request by sending a
   PUBLISH with status 'closed', the CCE becomes not-available, and
   the monitor changes the CCE's recall state to 'queued'.  This may
   cause another CCE (e.g., that has been in the queue for less time)
   to be selected for recall.

Dale