From alan.b.johnston@gmail.com Wed Mar 2 10:10:11 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653AC3A6844 for ; Wed, 2 Mar 2011 10:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu3uDXQr9ya7 for ; Wed, 2 Mar 2011 10:10:09 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DBCFA3A683E for ; Wed, 2 Mar 2011 10:10:08 -0800 (PST) Received: by bwz13 with SMTP id 13so476925bwz.31 for ; Wed, 02 Mar 2011 10:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=S1RsFeyCAoaqm4bqYHKQ245k0XGarywmxXudnSvbGjk=; b=bEqAvNRH6HH1vHE+U/UYC4iYc5KqmKWWr9mIOHTOEaF5eb9bfkdhVC7FVcmrL5OMof AK6fvvemeR50jXyaoA1jA81ZvNVlXeaKtV33JhmKty+qIcVF2wujqnfslnCmypqiACn6 QffVRAg4rDQPL7HXaSvXuiUv3j7XkDaJNhZ+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=b1d3OrJcSJAV3AoTSg33Uhes0mLWtEsbzM6GH7oR9mqWjfPMj8CH8El0P50hXrESFv 5mPlpNSBfZut7xwN2fKOpM0sVnAFL+YntBdIiyvvWf3hdtCbCQYttYsBk9lEcMv/jbG4 bUrUq20M4uKdY40XGlXuTiVMxdfr5HRzvkJIQ= MIME-Version: 1.0 Received: by 10.204.38.88 with SMTP id a24mr303021bke.194.1299089474475; Wed, 02 Mar 2011 10:11:14 -0800 (PST) Received: by 10.204.65.74 with HTTP; Wed, 2 Mar 2011 10:11:14 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Mar 2011 12:11:14 -0600 Message-ID: From: Alan Johnston To: bliss@ietf.org, Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [BLISS] AD review: draft-ietf-bliss-shared-appearances-06 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 18:10:11 -0000 I am finally working on a revision to the document. See below for comments on the minor issues. There hasn't been any comments on the major issues (changing 409 with 400 and updating RFC 3261 and 4235). Comments most welcome. I should have the changes described here done in the next few days. - Alan - On Fri, Dec 17, 2010 at 10:17 AM, Alan Johnston wrote: > Robert, > > Thanks for your review of this document. =A0I plan to address all of > your comments in a revision early in January. =A0For now, I will reply > to your three major issues below and see if we can get working group > consensus on the resolutions. > > - Alan - > > On Mon, Dec 6, 2010 at 1:58 PM, Robert Sparks wrot= e: >> Summary: There are a few major issues that need to be addressed before p= rogressing this document. >> >> Major Issues: >> >> 1) 409 is not a defined response code. Probably easiest to choose anothe= r. >> > > I knew 409 was deprecated as a response to REGISTER, but I hadn't > realized we had deprecated the entire response code! > > I suggest we just use a 400 response. =A0We had discussed including a > Retry-After header field with a very short value, or even zero, but > now I'm thinking about just omitting the Retry-After. > > >> 2) Is this an update to 3261 (through adding a parameter to Alert-Info)? > > > I am OK with this. > >> >> 3) Is this an update to 4235 (through adding the shared parameter)? >> > > I am OK with this. =A0We also make recommendations about dialog package > notifications that is stronger than RFC 4235, so this makes sense. > > >> ---- >> >> Section 4.2 calls out "An analysis of other mechanisms has been performe= d". >> Has that analysis been captured? It is in earlier versions of the I-D but was deleted. I will remove this t= ext. >> >> The list of steps in 4.2 is intended to be illustrative (I think). Can >> text be added to reinforce that this is not defining behavior. It might >> also help to point to where the behavior is actually defined. Right, we'll emphasize this is non-normative, and point to 5.3 and 5.4 where this is defined normatively. >> >> In 4.2, step 7, it's not clear what "this" is in "publishes this" The UA publishes the 100 Trying state dialog information without an appearance number. I'll add this in. >> >> Suggest deleting "In some cases," from the start of 4.2 step 9. Right >> >> The second paragraph of 5.2.2 should be clearer - it's not obvious >> that what you're trying to recommend is that a UA not share dialog >> information so that it won't be possible for someone else to take the >> call from a remote peer. Right, we will clarify this. >> >> Section 5.3 : why are the SHOULDs in paragraphs 2 and 3 (not counting >> the note between them), SHOULD and not MUST? I can't think of any reasons or cases where a UA that conforms to this specification wouldn't, so I'll change them to MUSTs. >> >> Section 5.3, paragraph 3: Should this say "fails or loops back to itself= "? >> Or is looping back the only failure you were intending to describe? What >> period should UAs retry the subscription with? No, it should just say "fails". A very long retry interval would seem to be in order - perhaps 4 hours? >> >> Section 5.3, paragraph 4 "All User Agents supporting INVITE MUST support= ...". >> This hasn't captured the real requirement - it's not All User agents tha= t >> support INVITE in the world - did you intend to scope this to "implement >> call pickup, joining, and bridging as you did in the first sentence? No, the MUST is for any UA that supports this specification and supports receiving INVITEs. I will make this clearer. >> >> Section 5.3, top of page 15: "This publication state SHOULD be refreshed= " >> Why is this a SHOULD? When would the endpoint choose to let the publishe= d >> state expire? It might help to call out that you are talking about norma= l >> 3903/5264 soft-state refreshes here. Right - we are not trying to make any changes to normal refresh operation, so I will remove the normative language. >> >> Section 5.3, middle of page 15: what does "implicitly rendered" mean? Explicitly rendered means show the actual appearance integer in the UI. Implicitly means some other clever UI trick that preserves the ordering aspects and makes sense to users within the group. >> >> End of section 5.3 - informative note. typo: received->receive. It would >> probably help to call out that this NOTIFY will be on the dialog event >> package. OK >> >> Section 5.4 - The SHOULD at the end of the 2nd paragraph is either >> modifying or restating a requirement from 4235. The Appearance Agent >> is being a State Agent at this point and the event package defines >> when change is sufficient to trigger a NOTIFY. It looks like this is >> in fact modifying the rules in 4235, adding extra conditions on >> when NOTIFYs would be sent. It would be much clearer to state this in >> terms of the affect on the package. This is all RFC 4235 says "It is RECOMMENDED that NOTIFY requests only contain information on the dialogs whose state or participation information has changed." which is very vague. The four items in this draft are: 1. A call is received, placed, answered, or terminated. 2. A call is placed on or off hold. 3. A call is joined or replaced. 4. An appearance number is reserved or released. I think 1 is covered by 4235. 2 could be covered if hold/unhold is considered participation, but I think not. I don't think 3 and 4 are covered. I can write some text that says explains how this specification extends 4235 by adding 2, 3, and 4. >> >> Section 5.4 talks about proxies inserting an Alert-Info field. Section >> 11 talks about proxies inserting and removing them. Both of these sectio= ns >> use non-normative terms. Where is the normative behavior for proxies par= ticipating >> in this feature defined? Also, for section 11. "If an Alert-Info is alre= ady present, >> =A0the proxy either removes the Alert-Info if it is not trusted, or adds >> =A0the 'appearance' parameter to the Alert-Info header field." >> It's not clear that RFC3261 allows a proxy to modify (in particular dele= te) >> existing Alert-Info header fields. You are correct that RFC 3261 does not explicitly allow this, although every real system does so. I would prefer to update RFC 3261 to explicitly allow proxies to apply trust domain rules in modifying and deleting Alert-Info header fields and parameters. However, if this causes trouble, we can remove it. I'm working on some text for this. >> >> Section 5.4, next to last paragraph on page 17, last sentence, >> starting "An Appearance agent does not have to". What does this mean >> in terms of protocol - is it suppressing a publish, a notify? It means delaying or suppressing a NOTIFY. >> >> Section 5.4, 2nd paragraph page 18 : Is this trying to say use >> event-rate-control? Or is it modifying the definition of the event packa= ge? We tried to make this vague, as it is something that implementations will need to manage themselves. I don't think event-rate-control is right for this. Nor is modifying the event package, as the RFC 4235 rules are so vague. >> >> Where is there a description of how the joined and replaced dialog xml e= lements >> are compared - there's an opportunity for error in implementation if the= y get >> the perspective of local and remote tag incorrect - where is the text th= at describes >> what to compare these against? I'll look at Replaces and Join and add in similar text. >> >> Section 7.1.1 - is this "0" an example, or is it intended that Single ap= pearance UAs >> only use "0" and any other values are not allowed? Section 7.1.2 doesn't= seem to have >> the same level of requirements that this section has. We can make it explicit that one uses only 0, and the other uses 0 and 1 on= ly. >> >> Section 7.1.3 - when you say call should be ignored, do you mean request= s should be >> rejected? Yes, rejected. >> >> Should the list starting with "The problems faced by each style" be its = own section >> or is it intended to be part of section 7.1.4? I'll add a new section. >> >> Section 8.2 - You should call out that if enpdoints use end-to-end encry= ption >> for their session descriptions, the Appearance agent will not get this i= nformation. >> This and other factors may make the information the appearance agent has= imperfect. Right, I'll note this. >> >> Seciton 8.3 - what's the consequence of not rejecting the requests - tha= t exlusive >> calls get joined? I'll clarify that the resulting request will be rejected by either the proxy or UA. Exclusive calls should not get joined unless the UA is buggy. >> >> Section 9 first paragraph - call out the event package (and that you are= probing >> for support of the extension via the event header parameter). OK >> >> I'm not sure what the second paragraph of section 9 is trying to achieve= ? >> Although there is no such correlation in RFC 3261, many UAs couple the authentication credentials with the From URI. RFC 3261 assumes both registrar and UA are infinitely flexible, a bad assumption in many cases. We are calling out this flexibility as a warning to implementors to avoid issues. No changes to RFC 3261 are implied by this, nor are we limiting the uses. >> Section 10.1 : Do you want to also call out authorizing publishes? Sugge= st >> rephrasing to avoid using "the same". Will do. >> >> 10.1 - >> In general, the examples need to be double-checked for correctness. >> The request and response in F1, and F2 do not have the same branch-id. >> F2 should have its expiry on the Contact header field value >> F5's Subscription-State header does not have the required elements (expi= res, >> at least, is required). This occurs in other examples as well. >> There should be no Event header field in F6. Right. >> >> 10.2 F4 and F21 have the same CSeq and the same partial-notification >> version number. >> >> 10.3 F4 and F6 are from different subscriptions - it's _very unlikely_ >> that the partial notify bodies would have the same version. I need to >> check, but I think the id attribute to > >> 10.4 F1 : Are you sure about using a partial publish here? >> >> 10.9 : Note that Bob's UA is configured not to, not that Bob chooses not >> to have an appearance number. What normative texts suppresses the normal= dialog >> state change notifications at the end of the paragraph? There is none. Probably these NOTIFYs would get sent, although they are of no use to anyone. >> >> 10.13: This is really hard to follow - it might help to tag the subscrib= es with >> what's being subscribed to. OK >> >> 10.14 : F48 - How is Alice authoritative for telling the appearance agen= t that >> the dialog in that Publish has been terminated? Alice initiated the pickup with F42. When F42 fails with a 481 and Alice decides not to retry, Alice knows the pickup has failed, and sends F48. >> >> 11 - What text precludes a UA from putting in its own appearance number? >> Nothing, but this yet another case why a proxy must be able to delete/modify Alert-Infos that are not correct or come from an untrusted source. >> 11 - it would be prudent to reconcile this ABNF change with what SALUD >> plans to do. We should make it where new parameters can be added with /= =3D >> after this change. OK >> >> Section 12 - This MUST to authenticate with Digest or S/MIME is stronger >> than the Replaces spec requires for a generic INVITE/Replaces - were you >> intending to further restrict the admission policy for INVITES associate= d >> with this extension? No, I'll check the INVITE/Replaces security considerations and make it matc= h. >> >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www.ietf.org/mailman/listinfo/bliss >> > From Internet-Drafts@ietf.org Mon Mar 14 14:00:03 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BFF3A6F0D; Mon, 14 Mar 2011 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHKodTCvdWFU; Mon, 14 Mar 2011 14:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FCF63A6AA5; Mon, 14 Mar 2011 14:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314210002.8579.48929.idtracker@localhost> Date: Mon, 14 Mar 2011 14:00:02 -0700 Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-07.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) Author(s) : A. Johnston, et al. Filename : draft-ietf-bliss-shared-appearances-07.txt Pages : 67 Date : 2011-03-14 This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bliss-shared-appearances-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14134611.I-D@ietf.org> --NextPart-- From Fred_Stacey@Mitel.com Mon Mar 14 14:59:49 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9F73A6BBA for ; Mon, 14 Mar 2011 14:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44F6coWR9oY7 for ; Mon, 14 Mar 2011 14:59:48 -0700 (PDT) Received: from smtp.mitel.com (smtp.mitel.com [216.191.234.102]) by core3.amsl.com (Postfix) with ESMTP id 9126B3A6BCA for ; Mon, 14 Mar 2011 14:59:48 -0700 (PDT) Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id DD2382C012 for ; Mon, 14 Mar 2011 18:01:11 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bE-autvPtfl for ; Mon, 14 Mar 2011 18:01:11 -0400 (EDT) Received: from ottlnmta.mitel.com (ottlnmta.mitel.com [10.44.16.150]) by smtp.mitel.com (Postfix) with ESMTP id 993572C03A for ; Mon, 14 Mar 2011 18:01:11 -0400 (EDT) From: Fred_Stacey@Mitel.com To: bliss@ietf.org Message-ID: Date: Mon, 14 Mar 2011 18:01:10 -0400 X-MIMETrack: Serialize by Router on OTTLNMTA/Mitel(Release 6.5.6FP3|March 27, 2008) at 03/14/2011 06:01:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [BLISS] Fred Stacey is out of the office. X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:59:50 -0000 I will be out of the office starting 03/12/2011 and will not return until 03/20/2011. I will be out of the office From March 12 to March 20 inclusive. If you inquiry is regarding Mitel AnyWare, please direct to mitel_anyware_sales@mitel.com. If your inquiry is regarding MICD or the Mitel Service Provider Program, please direct to Andrew Moses (andrew_moses@mitel.com) From alan.b.johnston@gmail.com Tue Mar 15 07:16:37 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7093A6D85 for ; Tue, 15 Mar 2011 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pyFWF8eaIPL for ; Tue, 15 Mar 2011 07:16:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 0C3273A6D11 for ; Tue, 15 Mar 2011 07:16:35 -0700 (PDT) Received: by bwz13 with SMTP id 13so653006bwz.31 for ; Tue, 15 Mar 2011 07:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=U5XlbfJ2UwTE7Lvk4KRhMb6wokTtmdpPlASsIOltXZ0=; b=mft4v+hY9MjAYMD8/4sfLxkla4hG1EXNd/ZWMiJV0kK05znKhghSP5kS4bcXJEnA+T lvm9Vmqk12nKYfxOyk4tUN1guOZ91YP0vMAHsesmcv05+Uw1SdYNEvlrG1eCcWRbH04e bhpLdmFzP/yHVfCM0lAF5AWBy5CKpM4uexqEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hdWJ2OBFZ6pW/P8WaKDxPhch7gN8/MuMYehikEB+At/RYchONj6KgRkPLR7jDEJ1GB Jlwq8l2ZR8mExkNZKajnBMha69cZYEDybTv89Ydd/o43auehjsjGHX33OU2+Jj8JGbAG 9A701A63pKxG4N1NwY46jZy+E5s2FAop0jTvk= MIME-Version: 1.0 Received: by 10.204.136.217 with SMTP id s25mr3133678bkt.13.1300198680380; Tue, 15 Mar 2011 07:18:00 -0700 (PDT) Received: by 10.204.49.85 with HTTP; Tue, 15 Mar 2011 07:18:00 -0700 (PDT) In-Reply-To: <20110314210002.8579.48929.idtracker@localhost> References: <20110314210002.8579.48929.idtracker@localhost> Date: Tue, 15 Mar 2011 09:18:00 -0500 Message-ID: From: Alan Johnston To: bliss@ietf.org Content-Type: multipart/alternative; boundary=0015175cd8d27b43ab049e861842 Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-07.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 14:16:37 -0000 --0015175cd8d27b43ab049e861842 Content-Type: text/plain; charset=ISO-8859-1 All, I have updated the draft based on Robert's feedback and my responses sent to the list previously. There are lots of edits, so Diff2 gives the best view: http://tools.ietf.org/rfcdiff?url2=draft-ietf-bliss-shared-appearances-07.txt A few additional notes: - I added some text about dialog matching which we need to be sure is correct - see 5.2.1. - There was a question about the ABNF changes and the SALUD work. Since the SALUD work is just on the Alert-Info URN, there are no ABNF changes planned to RFC 3261. - I added text relating to appearance handling during call transfers. See 5.3.1, 5.3.2, and 5.3.3. Comments most welcome! - Alan - On Mon, Mar 14, 2011 at 4:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Basic Level of Interoperability for SIP > Services Working Group of the IETF. > > > Title : Shared Appearances of a Session Initiation > Protocol (SIP) Address of Record (AOR) > Author(s) : A. Johnston, et al. > Filename : draft-ietf-bliss-shared-appearances-07.txt > Pages : 67 > Date : 2011-03-14 > > This document describes the requirements and implementation of a > group telephony feature commonly known as Bridged Line Appearance > (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line > Appearance (SCA). When implemented using the Session Initiation > Protocol (SIP), it is referred to as shared appearances of an Address > of Record (AOR) since SIP does not have the concept of lines. This > feature is commonly offered in IP Centrex services and IP-PBX > offerings and is likely to be implemented on SIP IP telephones and > SIP feature servers used in a business environment. This feature > allows several user agents (UAs) to share a common AOR, learn about > calls placed and received by other UAs in the group, and pick up or > join calls within the group. This document discusses use cases, > lists requirements and defines extensions to implement this feature. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > --0015175cd8d27b43ab049e861842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

I have updated the draft based on Robert's feed= back and my responses sent to the list previously. =A0 There are lots of ed= its, so Diff2 gives the best view:

=A0=A0 =A0=A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bliss-shared= -appearances-07.txt

A few additional notes:

- I ad= ded some text about dialog matching which we need to be sure is correct - s= ee 5.2.1.

- There was a question about the ABNF ch= anges and the SALUD work. =A0Since the SALUD work is just on the Alert-Info= URN, there are no ABNF changes planned to RFC 3261.

- I added text relating to appearance handling during c= all transfers. =A0See 5.3.1, 5.3.2, and 5.3.3.

Com= ments most welcome!

- Alan -

On Mon, Mar 14, 2011 at 4:00 PM, <Internet-Drafts@ietf.org> wrote:
=
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Basic Level of Interoperability for SIP Se= rvices Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Shared Appearances of a Session= Initiation Protocol (SIP) Address of Record (AOR)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : A. Johnston, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-bliss-shared-appearanc= es-07.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 67
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-14

This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). =A0When implemented using the Session Initiation
Protocol (SIP), it is referred to as shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. =A0This
feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment. =A0This feature
allows several user agents (UAs) to share a common AOR, learn about
calls placed and received by other UAs in the group, and pick up or
join calls within the group. =A0This document discusses use cases,
lists requirements and defines extensions to implement this feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft= -ietf-bliss-shared-appearances-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--0015175cd8d27b43ab049e861842-- From Martin.Huelsemann@telekom.de Thu Mar 31 08:03:24 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E991A3A6A34 for ; Thu, 31 Mar 2011 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvbWytoxnkCo for ; Thu, 31 Mar 2011 08:03:23 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 3B73B3A67FC for ; Thu, 31 Mar 2011 08:03:22 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 31 Mar 2011 17:04:57 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.217]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Thu, 31 Mar 2011 17:04:57 +0200 From: To: Date: Thu, 31 Mar 2011 17:04:56 +0200 Thread-Topic: more comments on the CC draft Thread-Index: AcvvtP8u4HqlfMucRyGWDU/f1cRubA== Message-ID: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE020113D8897CC1HE111543eme_" MIME-Version: 1.0 Cc: j.dave.smith@siemens-enterprise.com, R.Jesske@telekom.de Subject: [BLISS] more comments on the CC draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:03:25 -0000 --_000_9762ACF04FA26B4388476841256BDE020113D8897CC1HE111543eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear colleagues, during the last WGLC I again received a lot of comments from Dave for edito= rials and spelling corrections, thanks again for checking, my apologies for= not having detected them myself. Besides the editorials, Dave commented that the procedures are based very m= uch on the assumption of a underlying network architecture where there is a= clear seperation between the UA on the user device and the CC agent/monito= r which is located in the network. Dave proposed to better consider the cas= e where the CC agent/monitor is colocated with the UA on the user device. An example is a simple UA uses CC via a AS in the network, and when this UA= is not available for CC recall, we said that the CC agent SHALL suspend th= e CC request. But the suspension policy of a more sophisticated agent of a = CC App on a device could be different, therefore it was changed to 'SHOULD = be suspended'. There are some other changes in this direction. There are no= syntax changes. Even though they were contributed post WGLC, in my opinion those changes ar= e very useful for a more comprehensive CC solution, and therefore should be= considered. I have provisionally provided a 09 version of the internet dra= ft. You can find the changes at http://bliss-ietf.org/drafts/diff_ccbs.htm= l Your opinions? Regards, Martin --_000_9762ACF04FA26B4388476841256BDE020113D8897CC1HE111543eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 colleagues,
 
during th= e last WGLC=20 I again received a lot of comments from Dave for editorials and spelli= ng=20 corrections, thanks again for checking, my apologies for not having detecte= d=20 them myself.
 
Besides t= he=20 editorials, Dave commented that the procedures are based very much on = the=20 assumption of a underlying network architecture where there is a clear=20 seperation between the UA on the user device and the CC agent/monitor which= is=20 located in the network. Dave proposed to better consider the case where the= CC=20 agent/monitor is colocated with the UA on the user=20 device. 
An exampl= e is=20 a simple UA uses CC via a AS in the network, and when this UA is not=20 available for CC recall, we said that the CC agent SHALL suspend the CC req= uest.=20 But the suspension policy of a more sophisticated agent of a CC App on a de= vice=20 could be different, therefore it was changed to 'SHOULD be suspended'. Ther= e are=20 some other changes in this direction. There are no syntax=20 changes.
 
Even thou= gh they=20 were contributed post WGLC, in my opinion those changes are very useful for= a=20 more comprehensive CC solution, and therefore should be considered. I have= =20 provisionally provided a 09 version of the internet draft. You can find the= =20 changes at  http://bliss-ietf.org/= drafts/diff_ccbs.html
 
Your=20 opinions?
 
 

Regards, Martin=

 

 

--_000_9762ACF04FA26B4388476841256BDE020113D8897CC1HE111543eme_-- From keith.drage@alcatel-lucent.com Thu Mar 31 09:31:06 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB733A6844 for ; Thu, 31 Mar 2011 09:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.969 X-Spam-Level: X-Spam-Status: No, score=-105.969 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD1VIoAgI8Ec for ; Thu, 31 Mar 2011 09:31:05 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 89F4828C118 for ; Thu, 31 Mar 2011 09:31:03 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2VGWRNO014771 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Mar 2011 18:32:42 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 31 Mar 2011 18:32:36 +0200 From: "DRAGE, Keith (Keith)" To: "Martin.Huelsemann@telekom.de" , "bliss@ietf.org" Date: Thu, 31 Mar 2011 18:32:34 +0200 Thread-Topic: more comments on the CC draft Thread-Index: AcvvtP8u4HqlfMucRyGWDU/f1cRubAADAP1A Message-ID: References: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBD9FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [BLISS] more comments on the CC draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:31:06 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBD9FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you provide access to the -09 version somewhere (and please not as the = real -09 version as the changes are proposed for WG approval, and should no= t yet form part of the official WG draft). I find the diff link provided less than useful in this form, and there are = other things that need to be checked. Keith ________________________________ From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of M= artin.Huelsemann@telekom.de Sent: 31 March 2011 16:05 To: bliss@ietf.org Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de Subject: [BLISS] more comments on the CC draft Dear colleagues, during the last WGLC I again received a lot of comments from Dave for edito= rials and spelling corrections, thanks again for checking, my apologies for= not having detected them myself. Besides the editorials, Dave commented that the procedures are based very m= uch on the assumption of a underlying network architecture where there is a= clear seperation between the UA on the user device and the CC agent/monito= r which is located in the network. Dave proposed to better consider the cas= e where the CC agent/monitor is colocated with the UA on the user device. An example is a simple UA uses CC via a AS in the network, and when this UA= is not available for CC recall, we said that the CC agent SHALL suspend th= e CC request. But the suspension policy of a more sophisticated agent of a = CC App on a device could be different, therefore it was changed to 'SHOULD = be suspended'. There are some other changes in this direction. There are no= syntax changes. Even though they were contributed post WGLC, in my opinion those changes ar= e very useful for a more comprehensive CC solution, and therefore should be= considered. I have provisionally provided a 09 version of the internet dra= ft. You can find the changes at http://bliss-ietf.org/drafts/diff_ccbs.htm= l Your opinions? Regards, Martin --_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBD9FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can you provide access to the -09 vers= ion somewhere (and please not as the real -09 version as the changes are propos= ed for WG approval, and should not yet form part of the official WG draft).

 

I find the diff link provided less tha= n useful in this form, and there are other things that need to be checked.

 

Keith

 

From:= bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of Martin.Huelsemann@teleko= m.de
Sent: 31 March 2011 16:05 To: bliss@ietf.org
Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de
Subject: [BLISS] more commen= ts on the CC draft

 

Dear colleagues,

 

during the last WGLC I again received a lot of comments = from Dave for editorials and spelling corrections, thanks again for checkin= g, my apologies for not having detected them myself.<= /p>

 

Besides the editorials, Dave commented that the procedures are based very much on the assumption of a underlying network architecture where there is a clear seperation between the UA on the user device and the CC agent/monitor which is located in the network. Dave propo= sed to better consider the case where the CC agent/monitor is colocated with th= e UA on the user device. 

An example is a simple UA uses CC via a AS in the network, and when this UA is not available for CC recall, we said that the = CC agent SHALL suspend the CC request. But the suspension policy of a more sophisticated agent of a CC App on a device could be different, therefore i= t was changed to 'SHOULD be suspended'. There are some other changes in this direction. There are no syntax changes.

 

Even though they were contributed post WGLC, in my opini= on those changes are very useful for a more comprehensive CC solution, and therefore should be considered. I have provisionally provided a 09 version = of the internet draft. You can find the changes at  http://bliss-ietf.org/= drafts/diff_ccbs.html

 

Your opinions?

 

 

<= span style=3D'font-size:10.0pt;font-family:Arial'>Regards, Martin<= font size=3D2>

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBD9FRMRSSXCHMBSC3d_-- From shida@ntt-at.com Thu Mar 31 09:56:02 2011 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24CE3A6A48 for ; Thu, 31 Mar 2011 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-ztM35ECM-l for ; Thu, 31 Mar 2011 09:56:01 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.82.10]) by core3.amsl.com (Postfix) with SMTP id 2A0863A6A33 for ; Thu, 31 Mar 2011 09:56:01 -0700 (PDT) Received: (qmail 15235 invoked from network); 31 Mar 2011 16:57:56 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway15.websitewelcome.com with SMTP; 31 Mar 2011 16:57:56 -0000 Received: from dhcp-6799.meeting.ietf.org ([130.129.103.153]:50846) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q5LBi-0008CH-B7; Thu, 31 Mar 2011 11:57:39 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-9--986573725 From: Shida Schubert In-Reply-To: Date: Thu, 31 Mar 2011 18:57:36 +0200 Message-Id: References: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) 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-Source: X-Source-Args: X-Source-Dir: Cc: "bliss@ietf.org" , "Martin.Huelsemann@telekom.de" Subject: Re: [BLISS] more comments on the CC draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:56:02 -0000 --Apple-Mail-9--986573725 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Keith; Below is the 09 version of the draft that was used to=20 create the diff. http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-09.txt Regards Shida On Mar 31, 2011, at 6:32 PM, DRAGE, Keith (Keith) wrote: > Can you provide access to the -09 version somewhere (and please not as = the real -09 version as the changes are proposed for WG approval, and = should not yet form part of the official WG draft). > =20 > I find the diff link provided less than useful in this form, and there = are other things that need to be checked. > =20 > Keith > =20 > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf = Of Martin.Huelsemann@telekom.de > Sent: 31 March 2011 16:05 > To: bliss@ietf.org > Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de > Subject: [BLISS] more comments on the CC draft > =20 > Dear colleagues, > =20 > during the last WGLC I again received a lot of comments from Dave for = editorials and spelling corrections, thanks again for checking, my = apologies for not having detected them myself. > =20 > Besides the editorials, Dave commented that the procedures are based = very much on the assumption of a underlying network architecture where = there is a clear seperation between the UA on the user device and the CC = agent/monitor which is located in the network. Dave proposed to better = consider the case where the CC agent/monitor is colocated with the UA on = the user device.=20 > An example is a simple UA uses CC via a AS in the network, and when = this UA is not available for CC recall, we said that the CC agent SHALL = suspend the CC request. But the suspension policy of a more = sophisticated agent of a CC App on a device could be different, = therefore it was changed to 'SHOULD be suspended'. There are some other = changes in this direction. There are no syntax changes. > =20 > Even though they were contributed post WGLC, in my opinion those = changes are very useful for a more comprehensive CC solution, and = therefore should be considered. I have provisionally provided a 09 = version of the internet draft. You can find the changes at = http://bliss-ietf.org/drafts/diff_ccbs.html > =20 > Your opinions? > =20 > =20 > Regards, Martin > =20 > =20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss --Apple-Mail-9--986573725 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Keith;

 Below is the = 09 version of the draft that was used to 
create the = diff.


  Shida

On Mar 31, 2011, at 6:32 PM, DRAGE, Keith = (Keith) wrote:

Can you provide access to the -09 = version somewhere (and please not as the real -09 version as the changes = are proposed for WG approval, and should not yet form part of the = official WG draft).
I find the diff link provided less = than useful in this form, and there are other things that need to be = checked.
From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.or= g] On Behalf Of Sent: 31 March 2011 = 16:05
To: bliss@ietf.org
  R.Jesske@telekom.de
Subject: [BLISS] more comments on = the CC draft
during the last WGLC I again received a lot = of comments from Dave for editorials and spelling corrections, = thanks again for checking, my apologies for not having detected them = myself.
Besides the editorials, Dave = commented that the procedures are based very much on the assumption = of a underlying network architecture where there is a clear seperation = between the UA on the user device and the CC agent/monitor which is = located in the network. Dave proposed to better consider the case where = the CC agent/monitor is colocated with the UA on the user = device. 
An example is a simple UA uses CC via a = AS in the network, and when this UA is not available for CC recall, we = said that the CC agent SHALL suspend the CC request. But the suspension = policy of a more sophisticated agent of a CC App on a device could be = different, therefore it was changed to 'SHOULD be suspended'. There are = some other changes in this direction. There are no syntax = changes.
Even though they were contributed post WGLC, = in my opinion those changes are very useful for a more comprehensive CC = solution, and therefore should be considered. I have provisionally = provided a 09 version of the internet draft. You can find the changes = at  Your = opinions?
BLISS@ietf.org
To: "Martin.Huelsemann@telekom.de" , "bliss@ietf.org" Date: Thu, 31 Mar 2011 19:28:25 +0200 Thread-Topic: more comments on the CC draft Thread-Index: AcvvtP8u4HqlfMucRyGWDU/f1cRubAAE6CMw Message-ID: References: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "j.dave.smith@siemens-enterprise.com" , "R.Jesske@telekom.de" Subject: Re: [BLISS] more comments on the CC draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:26:56 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was kicked off to look at this further. My brief skim identifies two issues: 1) Generally throughout the document, "header" should be "header fi= eld" and "header parameter" should be "header field parameter". 2) All instances of the words "SHOULD" and "RECOMMENDED" should be = qualified by informative material indicating when the requirement applies /= does not apply. The note below that some SHALLs have changed to SHOULD tri= ggered me on this. I'll try and have a closer look when not in a meeting. Regards Keith ________________________________ From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of M= artin.Huelsemann@telekom.de Sent: 31 March 2011 16:05 To: bliss@ietf.org Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de Subject: [BLISS] more comments on the CC draft Dear colleagues, during the last WGLC I again received a lot of comments from Dave for edito= rials and spelling corrections, thanks again for checking, my apologies for= not having detected them myself. Besides the editorials, Dave commented that the procedures are based very m= uch on the assumption of a underlying network architecture where there is a= clear seperation between the UA on the user device and the CC agent/monito= r which is located in the network. Dave proposed to better consider the cas= e where the CC agent/monitor is colocated with the UA on the user device. An example is a simple UA uses CC via a AS in the network, and when this UA= is not available for CC recall, we said that the CC agent SHALL suspend th= e CC request. But the suspension policy of a more sophisticated agent of a = CC App on a device could be different, therefore it was changed to 'SHOULD = be suspended'. There are some other changes in this direction. There are no= syntax changes. Even though they were contributed post WGLC, in my opinion those changes ar= e very useful for a more comprehensive CC solution, and therefore should be= considered. I have provisionally provided a 09 version of the internet dra= ft. You can find the changes at http://bliss-ietf.org/drafts/diff_ccbs.htm= l Your opinions? Regards, Martin --_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was kicked off to look at this furth= er.

 

My brief skim identifies two issues:

 

1)      =    Generally throughout the document, “header” should be “header field” and = 220;header parameter” should be “header field parameter”.=

 

2)      =    All instances of the words “SHOULD” and “RECOMMENDED” should be qualified by informative material indicating when the requirement applies / does not apply. The note below th= at some SHALLs have changed to SHOULD triggered me on this.<= /font>

 

I’ll try and have a closer look = when not in a meeting.

 

Regards

 

Keith

 

From:= bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of Martin.Huelsemann@teleko= m.de
Sent: 31 March 2011 16:05 To: bliss@ietf.org
Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de
Subject: [BLISS] more commen= ts on the CC draft

 

Dear colleagues,

 

during the last WGLC I again received a lot of comments = from Dave for editorials and spelling corrections, thanks again for checkin= g, my apologies for not having detected them myself.<= /p>

 

Besides the editorials, Dave commented that the procedures are based very much on the assumption of a underlying network architecture where there is a clear seperation between the UA on the user device and the CC agent/monitor which is located in the network. Dave propo= sed to better consider the case where the CC agent/monitor is colocated with th= e UA on the user device. 

An example is a simple UA uses CC via a AS in the network, and when this UA is not available for CC recall, we said that the = CC agent SHALL suspend the CC request. But the suspension policy of a more sophisticated agent of a CC App on a device could be different, therefore i= t was changed to 'SHOULD be suspended'. There are some other changes in this direction. There are no syntax changes.

 

 

Your opinions?

 

 

<= span style=3D'font-size:10.0pt;font-family:Arial'>Regards, Martin<= font size=3D2>

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21EB8EBF3FRMRSSXCHMBSC3d_--