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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
