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

Shida Schubert <shida@ntt-at.com> Sat, 08 December 2012 15:46 UTC

Return-Path: <shida@ntt-at.com>
X-Original-To: bliss@ietfa.amsl.com
Delivered-To: bliss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABD21F88C7 for <bliss@ietfa.amsl.com>; Sat, 8 Dec 2012 07:46:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.543
X-Spam-Level:
X-Spam-Status: No, score=-100.543 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3p1tQLFzT1I for <bliss@ietfa.amsl.com>; Sat, 8 Dec 2012 07:46:14 -0800 (PST)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 160A021F8785 for <bliss@ietf.org>; Sat, 8 Dec 2012 07:46:13 -0800 (PST)
Received: from [125.193.49.76] (port=51133 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from <shida@ntt-at.com>) id 1ThMbU-0008MF-3w; Sat, 08 Dec 2012 09:46:12 -0600
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <201212072128.qB7LSF282576958@shell01.TheWorld.com>
Date: Sun, 9 Dec 2012 00:46:10 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <772B03DC-6911-43BB-BE78-7DD995A07D87@ntt-at.com>
References: <201212072128.qB7LSF282576958@shell01.TheWorld.com>
To: Dale R. Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: yes
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([192.168.11.3]) [125.193.49.76]:51133
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 2
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: bliss@ietf.org
Subject: Re: [BLISS] Last call comments on draft-ietf-bliss-call-completion-18.
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Dec 2012 15:46:15 -0000

Hi Dale;

 The draft is going through IETF last call not WGLC 
so any comments you have should be sent to 
ietf@ietf.org. 

 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:

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