Subject: [BLISS] Last call comments on draft-ietf-bliss-call-completion-18.

From: [email-masked] (Dale R. Worley)
Date: Fri, 7 Dec 2012 16:28:15 -0500 (EST)

Fundamentally, I think the draft is in great shape.  The only
significant change is that I think a summary of the "retain option"
procedures and considerations should be added so the reader can see
how it affects the procedures (and how gateways to the PSTN handle
"retain").

Only items 2 and 19 have technical content; the remainder are
editorial.

item 1) headers

Can you abbreviate my affiliation on the front page to "Ariadne"?  If
you are using XML2RFC, you can use the 'abrev' attribute of the
<organization> element:

    <organization abbrev='ISI'>
        USC/Information Sciences Institute
    </organization>

item 2) overall

The procedures regarding the retain option are scattered throughout
the document in a way that makes it difficult to see how it is
handled.  It seems to me that it would be helpful to add a summary of
retain option processing as a section, perhaps at the end of section
4.  This allows deleting the last paragraph of section 4.2, which is
vague when it stands alone.

   4.5 Summary of retain option procedures

   When the call completion call fails there are two possible options:
   the CC feature has to be activated again by caller's agent
   subscribing to callee's monitor, or CC remains activated and the
   original CC request remains in the queue.

   If the callee's monitor operates in the latter way, it is said to
   support the retain option.  Callee's monitors SHOULD support the
   retain option.  If a monitor supports the retain option, it SHOULD
   provide the cc-service-retention header in its call-completion
   events.  The caller's agent can use this header to know that this
   monitor supports the retain option.

   If a callee's monitor does not support the retain option (e.g., if
   it is a gateway to a network device whose CC functionality does not
   support the retain option), it SHOULD NOT provide the
   cc-service-retention header.  In addition, after a failed CC call
   that causes the CC request to be deleted from the queue, the
   monitor MUST terminate the corresponding agent's subscription to
   inform the agent that its CC request is no longer in the queue.

   After a failed CC call, the caller's agent MAY terminate its
   subscription, to inform the monitor that it is terminating its CC
   request.  After a failed CC call, the caller's agent MAY receive a
   termination of its subscription from the callee's monitor, if the
   monitor has terminated the agent's CC request.  In either case, the
   agent MAY create a new subscription (as described in section 6.2)
   to create a new CC request for the same original call.  The agent
   SHOULD avoid terminating one subscription and creating a new one if
   the caller's monitor has indicated support of the retain option.

I have used SHOULD to describe procedures which are desirable but are
not required for correct functioning.  In particular, the
cc-service-retention value does not have to be correct for a
properly-implemented agent and monitor to interact correctly.  This
gives us some freedom in situations where a gateway cannot discern
accurately whether the ultimate callee supports the retain option or
not.

Pure SIP agents and monitors can implement all the SHOULD behaviors
straightforwardly, so in the pure-SIP case, CC is done with the retain
option, which is what we want.

item 3) section 4.1

   The callee's monitor maintains information about the set of INVITEs
   received by the callee's UA(s) considered unsuccessful by the caller.

Strictly speaking, the monitor can't know if an INVITE is considered
unsuccessful by the caller.  This wording might fix that:

   The callee's monitor maintains information about the set of INVITEs
   received by the callee's UA(s) that the caller might consider
   unsuccessful.

item 4) section 4.2

   The callee's monitor
   keeps a list or queue of the caller's agent's subscriptions,
   representing the requests from the caller's agent to the callee's
---------------------------------------------------^
should be "agents"
   monitors for call-completion services.
----------^
should be "monitor"

item 5) section 4.2

   When the callee's monitor determines the callee and/or callee's UA
insert "are" here
   available for a CC call, it selects a caller to execute the CC call
   and sends a call-completion event update (''cc-state: ready'') via a
---------------------------------------------^^
this should probably use " rather than ''
   NOTIFY request to the selected caller's agent's subscription, telling
   it to begin the CC call to the callee's UA.

item 6) section 4.2

   When the call completion call fails there are two possible options:
   the CC feature has to be activated again by caller's agent
   subscribing to callee's monitor, or CC remains activated and the
   original CC request retains its position in the queue if retain
   option is supported.

This is kinda vague.  See item 2.

item 7) section 4.3

   There is no interaction between call completion and automatic redial,
-----------------------------------^
There is a risk of confusion.  I think this could be clarified as

   There is no interaction between automatic redial and call
   completion (as defined in this document), as they use different
   event packages and specify different behaviors regarding the
   events.

item 8) section 5

   Each CCE has an availability state, determined through caller's
   presence status at the callee's monitor.  A presence status of
   ''open'' represents CCE's availability state of 'available' and a
---^^
this should probably use " rather than ''
   presence status of "closed" represents CCE's availability state of
   'unavailable'.

item 9) section 5

   A CCE is identified by the
   request-URI (if it was taken from a call-completion event
--------------^^^^^^^
I think this would be clearer as

   request-URI of the PUBLISH request (if that URI was taken from a
   call-completion event

item 10) section 5

   notification which identifies the CCE) or the From URI of the request
   (matching the From URI recorded in the CCE).

   state of the CCE to 'not-available' (suspend).
------------------------^^^^
Other locations in the text use the value 'unavailable'.

item 11) section 7.1

   The callee's monitor SHOULD insert a URI in the Call-Info header

Since the first sentence of the previous paragraph specifies "MUST"
regarding inserting Call-Info, this "SHOULD" would be better specified
as "MUST".

item 12) section 7.1

   The 'm' parameter defines the "mode" of call completion.  The "m=NR"
   parameter indicates that it failed due to lack of response, the
----------------------------^^
this "it" should be "the original call"
   "m=BS" parameter indicates that it failed due to busy subscriber, and
-----------------------------------^^
the latter two "it"s are probably unambiguous
   the "m=NL" parameter indicates that it failed due to non registered
---------------------------------------^^
   subscriber (no devices are registered for the AoR contacted).  The

item 13) section 7.4

   The callee's UA(s) and the callee's monitor may give the CC call
   precedence over non-CC calls by evaluating the presence of the 'm'
   URI parameter and the From header of the INVITE request.
-----------------^^^

I don't think this "and" is correct.  One possibility is:

   The callee's UA(s) and the callee's monitor may give the CC call
   precedence over non-CC calls by evaluating the presence of the 'm'
   URI parameter in the From header of the INVITE request.

item 14) section 7.5

   the retain option and terminate the subscription along with the queue
   if it doesn't support the retain option.  Similarly, if the CC call
I think "queue" is supposed to be "CCE".

item 15) section 7.5

   completion" events, or any URI it returns as the "URI" line of the
---------------------------------------------^^
I think this is supposed to be "in".

item 16) section 7.5

   The receipt of the PUBLISH request initiates a presence event state
   for the caller's identity at the presence server functionality of the
   callee's monitor as specified in [RFC3903] , together with a logical
   presence server if this has not been done before for another call.

   Note: The presence server may initiate a presence event state for the
   caller's identity at the receipt of SUBSCRIBE request as well,
   dependent on the implementation.

These paragraphs do not match the following paragraph from 4.2:

       Upon receiving a SUBSCRIBE request from the caller's agent, the
       callee's monitor instantiates a presence state for the caller's UA
       which can be modified by the caller's UA to indicate its availability
       for CC call.  The status at the presence upon instantiation is
       "open".

Also, this section doesn't explicitly specify what is happening:  The
first sentences need to say that suspend requests are PUBLISH with
status 'closed'.  Somewhere in this section it needs to be mentioned
that the CCE is set to 'unavailable'.

item 17) section 7.6

Similarly to 7.5, the first sentences need to say that suspend
requests are PUBLISH with status 'closed'.  Somewhere in this section
it needs to be mentioned that the CCE is set to 'unavailable'.

The final sentence seems to be incorrect in some cases:

   If the callee
   is not busy and there is no entry in the CC queue which is currently
   being processed, the callee's monitor MUST process the queue as
   described in section 7.3 above.

because the callee's policy may not allow any CCE to be recalled at
this time.  (For example, if a recall for that CCE has recently
failed.)

Assembling these changes, I think something like this would be better:

   A CC request is resumed by a PUBLISH request from caller's agent as
   described in section 6.6, that is, containing a 'state' of 'open'.
   The presence event state for the caller's identity at the presence
   server functionality of the CC monitor MUST be updated as described
   in [RFC3903], and the corresponding CCE's availablity state must be
   set to 'available'.  This may cause the CCE to be selected for
   recall under the monitor's policy.

item 18) section 8

In the second example, I see two uses of "Content-Type: 'app/pidf'".
I think this should be spelled out as "Content-Type: application/pidf".

For the bodies, I think it would be safer to spell out the PIDF a bit
more:

         | Body: ...<status><basic>open</basic></status>...

item 19) section 10.3

   The cc-URI line provides a URI (possibly in the form of a name-addr)

but it also says

   cc-URI = "cc-URI" HCOLON addr-spec

There are three choices for the syntax of the value of cc-URI:

addr-spec
	this eliminates the possibility of generic-params ("header parameters")
name-addr
	this allows generic-params but requires that we rephrase the
	first sentences of the section, as a name-addr isn't a URI, strictly
	speaking.
addr-spec / name-addr
	this alternative is used a lot in headers, but we would have
	to mention that the rule in RFC 3261 section 20.10 applies:

	   Even if the "display-name" is empty, the "name-addr" form MUST be
	   used if the "addr-spec" contains a comma, semicolon, or question
	   mark.  There may or may not be LWS between the display-name and the
	   "<".

Looking at the old drafts, we changed the value from "(name-addr /
addr-spec)" to "addr-spec" in -15.  So the ABNF is probably correct.
So we should reduce the text of this section to just the first three
sentences:

   The cc-URI line provides a URI (possibly in the form of a name-addr)
   which the agent SHOULD use as the request-URI of the CC recall INVITE
   and the suspend/resume PUBLISH.  It SHOULD be provided in all
   NOTIFYs.  The URI SHOULD be globally routable and SHOULD uniquely
   identify the CCE in question. 

item 20) section 12.2

   Intended usage: LIMITED USE

We could expand this to:

   Intended usage:  Within the procedures of RFC XXXX.

item 21) section 12.4

   Reference: [RFC3261].[RFC5367][[RFC XXXX]]
-----------------------^

I think this is intended to be a comma.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Sun, 9 Dec 2012 00:46:10 +0900

Hi Dale;

 The draft is going through IETF last call not WGLC 
so any comments you have should be sent to 
[email-masked]. 

 Detail review is always welcome but you being a 
co-author of the draft, these comments I think should 
have been provided sooner to your co-author or 
included in the ongoing revision that the draft has 
undergone. 

 Regards
  Shida

On Dec 8, 2012, at 6:28 AM, Dale R. Worley wrote:

> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 11 Dec 2012 11:49:06 -0500 (EST)

> From: Shida Schubert <[email-masked]>
> 

Yes, my apologies, I've not been keeping up and got quite rushed and
sloppy.  And though I'm an author, I haven't been involved in the
editing cycles for at least a year (after the my list of technical
issues were resolved).

What is the best way for me to proceed?  Most of my items are really
editorial.  One other item has technical content, but I think the real
issue is that an edit has not been fully applied.  The most
significant item is that I think the document would be clearer if a
summary of behaviors related to the "retain option" was added.  Of
course, all of these should be decided by the current authors, but
what is the proper process at this point?

Dale