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, 09 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
- [BLISS] Last call comments on draft-ietf-bliss-ca… Dale R. Worley
- Re: [BLISS] Last call comments on draft-ietf-blis… Shida Schubert
- Re: [BLISS] Last call comments on draft-ietf-blis… Dale R. Worley