Re: [BLISS] WGLC for draft-ietf-bliss-call-completion-07 -- 3001 Nits and wording improvements

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

In some places, "section" is capitalized and in others it is not.  I
think the usual convention is to not capitalize it.  In that case, the
places that need changing are section 4.3, para 1 ("described in
[RFC5359], Section 2.17.") and section 9.7, para 4 ("discussed in
Section 11.").

In Abstract, "... the usage of the the dialog event package (defined
in RFC 4235) as described as ..." is probably clearer as "the usage of
the the dialog event package (defined in RFC 4235) that is described
as ...".

In section 3, item "CC request" needs to be updated due to the lack of
call correlation:

   CC request: the entry in the callee's monitor queue representing the
   the caller's request for CC processing, that is, the caller's
   call-completion subscription.

In section 3, item "Retain option", the final full-stop is missing.

In section 4.1, para 3, at the end:  "... the two agents are ..."
should probably be "... the two functions are ...", in order to be
paralle to the first sentence of the paragraph.

In section 4.1, last para:  "... establishes that the dialog is no
longer eligible for CC requests." should be "... establishes that the
dialog is no longer eligible for CC activation."

In section 4.2, para 2 could be clarified by changing "insufficient to
satisfy his needs" to "insufficient to satisfy his needs (e.g., the
callee's voicemail)".

In section 4.2, para 4, sentence 2:  I think this sentence needs to be
in the past tense to be clear:  "Note that from the SIP point of view,
the INVITE may have been successful, but from the user's point of
view, the call may have been unsuccessful."

In section 4.2, para 6 is:

   The caller's agent sends a SUBSCRIBE request for the call-completion
   event package to all known monitor URIs and to the original
   destination URI of the call, which are provided by a Call-Info header
   in provisional and final responses to the INVITE.

This could be improved by:

   The caller's agent sends a SUBSCRIBE request for the
   call-completion event package to the original destination URI of
   the call and to all known monitor URIs (which are provided by
   Call-Info headers in provisional and final responses to the
   INVITE).

In section 4.2, para 6, changes are needed because we no longer do
call correlation:

   ...  The callee's monitor uses the existence of the subscription to
   know that the caller is interested in using the CC feature in
   regard to the specified callee.  The monitor keeps a list or queue
   of the caller's agent's subscriptions, which indicate the callers
   that are waiting to use the CC features.

In section 4.2, para 9, adding a hyphen makes this phrase clearer:
"... the next not-suspended CC agent ...".

In section 4.2, para 2, now that we aren't doing call correlation, the
last sentence should be changed to "To support this, the caller's
agent must record successful calls as well as unsuccessful calls.".

[My apologies for the multiple revisions of section 5 in my various
commentaries.  The complete revision given for issue 1010 is the
last one I wrote, and I think it incorporates everything I've suggested
for that section.]

In section 5, para 1, "A CECE is removed ... exceeds a particular time
limit."  should be made less rigid, as the local policies may vary.
Perhaps "A CECE is removed from the set based on local policy, which
is likely to include a limit on the lifetime timer."

In section 5, paras 2, 3, and 4:  I think the paragraph breaks are not
where intended.  The current text is:

   A subset of the CECEs are organized into a queue.  Each CECE has an
   availability state, which is either "available for recall" or "not
   available for recall".  This availability state is only significant
   for CECEs in the queue.  It is not visible via subscriptions.  Each
   CECE has a recall state which is visible via subscriptions.

   The recall state is either "queued" or "ready".  This recall state is
   only significant for CECEs in the queue.  CC subscriptions arrive at
   the the monitor by being addressed to the managed URI.  The CECEs
   being subscribed to are identified by the Request URI.

   When a CECE is destroyed, any subscriptions to its state are
   terminated.

whereas it reads better as:

   A subset of the CECEs are organized into a queue.  Each CECE has an
   availability state, which is either "available for recall" or "not
   available for recall".  This availability state is only significant
   for CECEs in the queue.  It is not visible via subscriptions.

   Each CECE has a recall state which is visible via subscriptions.
   The recall state is either "queued" or "ready".  This recall state
   is only significant for CECEs in the queue.

   CC subscriptions arrive at the the monitor by being addressed to
   the managed URI.  The CECEs being subscribed to are identified by
   the Request URI.  When a CECE is destroyed, any subscriptions to
   its state are terminated.

In section 5, para 7, the reference to RFC 3863 is not well formatted:
"PIDF bodies (RFC 3863[RFC3863]), via PUBLISH".  I think this can be
cleaned up by saying "PIDF bodies [RFC3863], via PUBLISH".

In section 7.2, para 2:  "... and should respond 482 ..." should be
"... and SHOULD respond 482 ...".

In section 7.2, para 2:  "... restrictions as which ..." should be
"... restrictions as to which ...".

In section 7.2, page 16, para 4: The paragraph has a stray "_" before
and after it.

In section 7.2, para 4:  Because we are no longer doing call
correlation, this needs to be rephrased:

   ...  If the callee's monitor becomes aware that, according to its
   policy, a subscription will never be selected for call-completion,
   it SHOULD terminate the subscription.

In section 7.3, para 1, "... the vital datum is that it contains an
indication ..." should be "... the vital datum that it contains is an
indication ...".

In section 7.3, para 1, "requestst" should be "requests".

In section 7.3, para 3:  Because we aren't doing call correlation,
this needs to be reworded (as marked by *...*):

   The callee's monitor has a policy regarding when and how it selects
   CC requests to be activated.  This policy may take into account the
   type of the requests (e. g.  CCNR vs. CCBS), the state of the
   callee's UA(s), the order in which *the CC requests* arrived, *the
   length of time the CC requests have been active,* and any previous
   CC attempts for the same original call.  Usually the callee's
   monitor will choose only one CC request for activation at a time,
   but if the callee's UA(s) can support multiple calls, it may choose
   more than one.  *Usually the callee's monitor will choose the
   oldest active request.*

In section 7.3, para 4:  Update the terminology:  "When the callee's
monitor changes the state datum for the chosen subscription from
"queued" to "ready", ..."

In section 7.4, para 1:  Update the terminology:  "... by changing the
value of its state datum to "queued"."

In section 10.1, "a user's entry" should probably be "the subscriber's
entry".

In section 11, page 26: Stray ">" in para 1.

In section 11, page 26, item 4:  The first sentence is the correct item
4; the second sentence should be a separate paragraph after the
itemized list.

In section 12.3, 12.4, and 12.5, the tables are badly formatted.
(Depending on the tools you are using, the best course of action may
be to leave fixing this to the RFC editor.)

Dale