From dworley@nortel.com Wed Feb 11 15:12:35 2009 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 05D293A6953 for ; Wed, 11 Feb 2009 15:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jHlm3E4nOhn6 for ; Wed, 11 Feb 2009 15:12:34 -0800 (PST) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id D9C983A67CF for ; Wed, 11 Feb 2009 15:12:33 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1BNCZ505825 for ; Wed, 11 Feb 2009 23:12:35 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 18:12:34 -0500 From: "Dale Worley" To: BLISS Content-Type: text/plain Organization: Nortel Networks Date: Wed, 11 Feb 2009 18:12:34 -0500 Message-Id: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2009 23:12:35.0056 (UTC) FILETIME=[3948BF00:01C98C9E] Subject: [BLISS] Bliss design group mailing lists 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, 11 Feb 2009 23:12:35 -0000 As far as I can tell, there are no publicly-visible pointers to the Bliss design group mailing lists, or to the design groups themselves. Relative to the concept that IETF participation is open to all, I think that this is a serious deficiency, and we should add appropriate pointers from the IETF Bliss WG page (http://www.ietf.org/html.charters/bliss-charter.html) to the secret Bliss WG page (http://bliss-ietf.org/) and from that page to the design group pages (http://bliss-ietf.org/mailman/listinfo/ccbs_bliss-ietf.org, etc.). Dale From shida@ntt-at.com Wed Feb 11 20:16:54 2009 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 107603A6927 for ; Wed, 11 Feb 2009 20:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 sfBOgrwmIZAr for ; Wed, 11 Feb 2009 20:16:53 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.154.35]) by core3.amsl.com (Postfix) with SMTP id 0915C3A67A2 for ; Wed, 11 Feb 2009 20:16:52 -0800 (PST) Received: (qmail 8875 invoked from network); 12 Feb 2009 04:43:34 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 12 Feb 2009 04:43:34 -0000 Received: from fl1-122-133-113-38.tky.mesh.ad.jp ([122.133.113.38]:7645 helo=[10.0.1.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LXT0Q-0007bV-BC; Wed, 11 Feb 2009 22:16:55 -0600 Message-Id: <0120C8CC-C695-4987-8B7B-86F015A1EC90@ntt-at.com> From: Shida Schubert To: Dale Worley In-Reply-To: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 13:16:53 +0900 References: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) 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 Cc: BLISS Subject: Re: [BLISS] Bliss design group mailing lists 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, 12 Feb 2009 04:16:54 -0000 Hi Dale; I will attend to this before the next IETF.. Many thanks for bringing this up and there was never an intention to keep any of this secret Regards Shida On 12-Feb-09, at 8:12 AM, Dale Worley wrote: > As far as I can tell, there are no publicly-visible pointers to the > Bliss design group mailing lists, or to the design groups themselves. > Relative to the concept that IETF participation is open to all, I > think > that this is a serious deficiency, and we should add appropriate > pointers from the IETF Bliss WG page > (http://www.ietf.org/html.charters/bliss-charter.html) to the secret > Bliss WG page (http://bliss-ietf.org/) and from that page to the > design > group pages (http://bliss-ietf.org/mailman/listinfo/ccbs_bliss-ietf.org > , > etc.). > > Dale > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From shida@ntt-at.com Wed Feb 11 20:17:22 2009 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 7B9CD3A69A6 for ; Wed, 11 Feb 2009 20:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 aWjA5XqhAiMY for ; Wed, 11 Feb 2009 20:17:21 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.212.28]) by core3.amsl.com (Postfix) with SMTP id 51A133A67A2 for ; Wed, 11 Feb 2009 20:17:21 -0800 (PST) Received: (qmail 28303 invoked from network); 12 Feb 2009 04:36:01 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 12 Feb 2009 04:36:01 -0000 Received: from fl1-122-133-113-38.tky.mesh.ad.jp ([122.133.113.38]:7645 helo=[10.0.1.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LXT04-0007bV-TA; Wed, 11 Feb 2009 22:16:33 -0600 Message-Id: From: Shida Schubert To: Dale Worley In-Reply-To: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Feb 2009 12:38:36 +0900 References: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) 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 Cc: BLISS Subject: Re: [BLISS] Bliss design group mailing lists 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, 12 Feb 2009 04:17:22 -0000 Hi Dale; I will attend to this before the next IETF.. Many thanks for bringing this up. Regards Shida On 12-Feb-09, at 8:12 AM, Dale Worley wrote: > As far as I can tell, there are no publicly-visible pointers to the > Bliss design group mailing lists, or to the design groups themselves. > Relative to the concept that IETF participation is open to all, I > think > that this is a serious deficiency, and we should add appropriate > pointers from the IETF Bliss WG page > (http://www.ietf.org/html.charters/bliss-charter.html) to the secret > Bliss WG page (http://bliss-ietf.org/) and from that page to the > design > group pages (http://bliss-ietf.org/mailman/listinfo/ccbs_bliss-ietf.org > , > etc.). > > Dale > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From mary.barnes@nortel.com Thu Feb 12 07:05:05 2009 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 B41CE3A68A1 for ; Thu, 12 Feb 2009 07:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 9LpFBFtkhI-8 for ; Thu, 12 Feb 2009 07:05:04 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 659FF3A69BA for ; Thu, 12 Feb 2009 07:05:04 -0800 (PST) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1CF0rJ11676; Thu, 12 Feb 2009 15:00:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 09:07:23 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF1C3899F6@zrc2hxm0.corp.nortel.com> In-Reply-To: <0120C8CC-C695-4987-8B7B-86F015A1EC90@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Bliss design group mailing lists Thread-Index: AcmMyMhcqX23TW24T7+zGavCl+H3PgAWepVA References: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> <0120C8CC-C695-4987-8B7B-86F015A1EC90@ntt-at.com> From: "Mary Barnes" To: "Shida Schubert" , "Dale Worley" Cc: BLISS Subject: Re: [BLISS] Bliss design group mailing lists 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, 12 Feb 2009 15:05:05 -0000 Dale and Shida, Just to clarify this concern (and not debate how BLISS is handling design teams) - per IETF WG process, it is actually okay to have a closed design team - per section 6.5 of RFC 2418, stated as: "In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings." The issue being that with open design teams folks can come and go as they desire, but this can result in a lot of inefficiency in bringing new attendees up to speed on conference calls for example. And, based on team efficiency studies, around 7 contributors is considered optimal and allows everyone to contribute, which is the intent for design team members. With too many folks , it's hard to stay focused AND to allow everyone to provide input. =20 The key is that nothing done by design teams is binding and it all MUST go through normal WG process to gain approval, etc.=20 Regards, Mary.=20 -----Original Message----- From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of Shida Schubert Sent: Wednesday, February 11, 2009 10:17 PM To: Worley, Dale (BL60:9D30) Cc: BLISS Subject: Re: [BLISS] Bliss design group mailing lists Hi Dale; I will attend to this before the next IETF.. Many thanks for bringing this up and there was never an intention to keep any of this secret Regards Shida On 12-Feb-09, at 8:12 AM, Dale Worley wrote: > As far as I can tell, there are no publicly-visible pointers to the=20 > Bliss design group mailing lists, or to the design groups themselves. > Relative to the concept that IETF participation is open to all, I=20 > think that this is a serious deficiency, and we should add appropriate > pointers from the IETF Bliss WG page > (http://www.ietf.org/html.charters/bliss-charter.html) to the secret=20 > Bliss WG page (http://bliss-ietf.org/) and from that page to the=20 > design group pages=20 > (http://bliss-ietf.org/mailman/listinfo/ccbs_bliss-ietf.org > , > etc.). > > Dale > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From worley@c-65-96-67-63.hsd1.ma.comcast.net Wed Feb 11 14:40:52 2009 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 910F83A6C89 for ; Wed, 11 Feb 2009 14:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994] 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 d0NdpMaU+SqT for ; Wed, 11 Feb 2009 14:40:52 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id C2E543A6C7E for ; Wed, 11 Feb 2009 14:40:51 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ElSH1b0011GhbT855mgxnC; Wed, 11 Feb 2009 22:40:57 +0000 Received: from dragon.ariadne.com ([65.96.67.63]) by OMTA07.westchester.pa.mail.comcast.net with comcast id Emgw1b00d1MtnpM3Tmgxx4; Wed, 11 Feb 2009 22:40:57 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id n1BMetLw020148 for ; Wed, 11 Feb 2009 17:40:55 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id n1BMerfU020144; Wed, 11 Feb 2009 17:40:53 -0500 Date: Wed, 11 Feb 2009 17:40:53 -0500 Message-Id: <200902112240.n1BMerfU020144@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net Sender: Dale.Worley@comcast.net In-reply-to: (Markus.Isomaki@nokia.com) References: <0D5F89FAC29E2C41B98A6A762007F5D00167DAE8@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [BLISS] ACH configuration requirements: replicating GSM functionality 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, 12 Feb 2009 17:54:59 -0000 From: If there is interest, I could write the GSM reqs in a proper brief Internet-Draft in a more verbose way with references to the corresponding GSM specs. It seems like a good idea to write a draft so we have a semi-archival description of these requirements. Dale From dworley@nortel.com Fri Feb 13 14:04:32 2009 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 DE4F43A6B40 for ; Fri, 13 Feb 2009 14:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hpDRG0TsQ3lV for ; Fri, 13 Feb 2009 14:04:32 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0E3693A693B for ; Fri, 13 Feb 2009 14:04:31 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1DM0KH07735; Fri, 13 Feb 2009 22:00:20 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Feb 2009 17:04:24 -0500 From: "Dale Worley" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1C3899F6@zrc2hxm0.corp.nortel.com> References: <1234393954.3785.124.camel@victoria-pingtel-com.us.nortel.com> <0120C8CC-C695-4987-8B7B-86F015A1EC90@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1C3899F6@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 13 Feb 2009 17:04:24 -0500 Message-Id: <1234562664.3765.36.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2009 22:04:25.0189 (UTC) FILETIME=[085C1150:01C98E27] Cc: BLISS Subject: Re: [BLISS] Bliss design group mailing lists 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: Fri, 13 Feb 2009 22:04:32 -0000 On Thu, 2009-02-12 at 10:07 -0500, Barnes, Mary (RICH2:AR00) wrote: > Just to clarify this concern (and not debate how BLISS is handling > design teams) - per IETF WG process, it is actually okay to have a > closed design team - [...] I can see the logic in this. What I'm more interested in is making sure that the information and mail archives are findable -- more than once, I've had to do some creating searching to find the pointers. Dale From shida@ntt-at.com Mon Feb 16 01:30:34 2009 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 AC9743A679F for ; Mon, 16 Feb 2009 01:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6] 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 plhvY0WeRCpl for ; Mon, 16 Feb 2009 01:30:33 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.243.5]) by core3.amsl.com (Postfix) with SMTP id 5AF673A6C2F for ; Mon, 16 Feb 2009 01:30:33 -0800 (PST) Received: (qmail 21412 invoked from network); 16 Feb 2009 09:49:00 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway16.websitewelcome.com with SMTP; 16 Feb 2009 09:49:00 -0000 Received: from flh1alz122.tky.mesh.ad.jp ([211.13.91.122]:59672 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LYzoG-0003ue-Bn for bliss@ietf.org; Mon, 16 Feb 2009 03:30:41 -0600 Message-Id: <9BC92238-5101-46DD-95FD-41BFD2D726BE@ntt-at.com> From: Shida Schubert To: bliss@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-1-918884625 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 16 Feb 2009 18:30:38 +0900 X-Mailer: Apple Mail (2.930.3) 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 Subject: [BLISS] Minutes from the BLISS-REST teleconf 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, 16 Feb 2009 09:30:34 -0000 --Apple-Mail-1-918884625 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All; Attached is a minutes from our first BLISS-REST design team meeting. I want to thank the members of design team to put aside time to attend the meeting and contribute. We really need some more use-cases beside what's already mentioned in the ACH analysis and ach-config-requirements draft. Please do submit a comment if you have any use-cases for REST like protocol in the context of ACH. Meeting Date: 2009.02.06 Note-taker: Shida Schubert Attendees: Andrew Christien Kemo Salvatore Sanjay Simon Shida Theo 1. Debate about the scoping of the REST-BLISS activity. - Need to distinguish from XCAP. - Chair asked the motivation behind what Nokia is doing with regards to XCAP/HTTP+CPL and the background behind Marku's comment. - Kemo explained that Markus's comment was based on the requirements draft. draft-zourzouvillys-bliss-ach-config-requirements - Kemo further went on to explain that in the req draft, something like time based policy etc. was being discussed. - Based on the req, if Common Policy based ruleset is necessary, it's already defined in 3GPP or may be something like CPL + HTTP may be considered? > Kemo suggested that if policy based ruleset is to be considered, the design team should look at the ongoing work in 3GPP.. - Salvatore expressed that even if REST approach is taken, there is still a need to identify the resources available for alteration. - Salvatore also added the need to decide anything that is important enough to be referenced as a thing in itself, namely resource. Then associate to each resource at least one URI, and decide the structure of that URI in a way that should vary in a predictable way. - Simon pointed out the following points about adopting REST like approach as it has been debated in XCON. > Application level error codes and transport level error codes, and where error codes are to be sent need to be carefully considered > Can simply use HTTP error + body with error indication > Salvatore explained that REST is a set of design criteria, not very well specified anywhere. However one defining feature of a RESTful architecture is its use of HTTP response code,where an error response code is a signal to the client that the metadata (headers) and entity-body should not be interpreted as a response to the request. In general a first step we should take is to agree on the set of design criteria we consider to be REST. > Debate on why use REST? XCAP? > Salvatore commented that XCAP can be considered a RESTful protocol, maybe not 100% pure REST. > Salvatore explained the possibility to modify XCAP to be 100% RESTful compliant, and re-utilize all the stuff that has been already defined for XCAP, like event packages, etc.etc. > Sanjay asked if we are designing SIP-REST general framework. > Shida explained that at the last meeting, as part of the scope of BLISS WG, BLISS will not design a general framework and focus only on the use-cases of ACH but do not limit the extensibility and further usage. > It was agreed that we need use-cases/requirements > Sanjay asked if we want to gather use-cases for anything or ACH? > Shida suggests to open up for anything. > Andrew argued that that we should focus on ACH only. > Shida agress. > Debate on the current requirements draft. draft-zourzouvillys-bliss-ach-config-requirements > Has a lot in there.. > Theo agreed, and explained that it was because it included everything people expressed for its potential uses. > It was pointed out that by presenting the draft, we were able to narrow the scope of this work a tad. Conclusion: We need use-cases/requirements. Especially use-cases beside what's mentioned in the ACH draft. Many Thanks Shida --Apple-Mail-1-918884625 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable draft-zourzouvillys-bliss-ach-config-requirements
 
    - Kemo further went on to = explain that in the req draft, something = like 
       time based policy etc. = was being discussed. 
    - Based on the = req, if Common Policy based ruleset is = necessary, 
       it's already = defined in 3GPP or may be something like CPL + = HTTP
       may be = considered?
   >  Kemo suggested that if policy = based ruleset is to be considered, 
     =    the design team should look at the ongoing work in = 3GPP..

  - Salvatore expressed that = even if REST approach is taken, there is = still 
    a need to identify = the resources available for alteration.
  - = Salvatore also added the need to decide anything that is = important
     enough to be referenced as a = thing in itself, namely resource.
     Then associate = to each resource at least one URI, and decide the structure of that = URI 
     in a way that should vary in a = predictable way.

  - Simon pointed = out the following points about adopting REST = like 
    approach as it has been debated = in XCON.  
     > Application level error = codes and transport level error codes, 
   =      and where error codes are to be sent need to be = carefully considered 
     > Can simply = use HTTP error + body with error = indication
  
    > = Salvatore explained that REST is a set of design criteria, not very = well 
specified anywhere. However one defining = feature of a RESTful architecture 
is its use of = HTTP response code,where an error response code is a = signal 
to the client that the metadata (headers) and = entity-body should not be 
interpreted as a response = to the request. In general a first step we = should 
take is to agree on the set of design criteria we = consider to be REST.

     > = Debate on why use REST? = XCAP? 

    > =  Salvatore commented that XCAP can be considered a RESTful = protocol,
        maybe not 100% = pure REST. 
    > Salvatore explained the = possibility to modify XCAP to be 100% RESTful compliant,
and = re-utilize all the stuff that has been already defined for XCAP, like = event packages, etc.etc.

> Sanjay asked if we = are designing SIP-REST general framework. 
  > = Shida explained that at the last meeting, as part of the scope of = BLISS 
     WG, BLISS will not design a = general framework and focus only on the 
   =   use-cases of ACH but do not limit the extensibility and further = usage.

> It was agreed that we need = use-cases/requirements
  > Sanjay asked if we want = to gather use-cases for anything or ACH?
   > Shida = suggests to open up for anything.
   > Andrew argued = that that we should focus on ACH only. 
   =   > Shida agress. 

> Debate on the = current requirements draft.
       draft-zourzouvillys-bliss-ach-config-requirements
 > Has a lot in there.. 
  > Theo = agreed, and explained that it was because it = included 
    everything = people expressed for its potential = uses. 
  > It was pointed out that by = presenting the draft, we were able 
     = to narrow the scope of this work a = tad.

Conclusion: We need = use-cases/requirements. Especially use-cases 
beside = what's mentioned in the ACH draft.  

Many = Thanks
  Shida 
= --Apple-Mail-1-918884625-- From Simo.Veikkolainen@nokia.com Mon Feb 16 03:10:19 2009 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 C476C3A6848 for ; Mon, 16 Feb 2009 03:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] 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 rFihvHBLPQGL for ; Mon, 16 Feb 2009 03:10:18 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8665D3A6963 for ; Mon, 16 Feb 2009 03:10:16 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1GBA1mM008210; Mon, 16 Feb 2009 13:10:22 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 13:10:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 13:10:12 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Mon, 16 Feb 2009 12:10:11 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Mon, 16 Feb 2009 12:10:10 +0100 From: To: , Date: Mon, 16 Feb 2009 12:10:10 +0100 Thread-Topic: [BLISS] Minutes from the BLISS-REST teleconf Thread-Index: AcmQGUbXcY7Oamf6S9yNaQHyCH1sPAADWrZA Message-ID: References: <9BC92238-5101-46DD-95FD-41BFD2D726BE@ntt-at.com> In-Reply-To: <9BC92238-5101-46DD-95FD-41BFD2D726BE@ntt-at.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_B23B311878A0B4438F5F09F47E01AAE027EAFC6ED1NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2009 11:10:12.0238 (UTC) FILETIME=[230452E0:01C99027] X-Nokia-AV: Clean Subject: Re: [BLISS] Minutes from the BLISS-REST teleconf 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, 16 Feb 2009 11:10:19 -0000 --_000_B23B311878A0B4438F5F09F47E01AAE027EAFC6ED1NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in case someone's wondering, Kemo =3D> Simo ;) Cheers, Simo ________________________________ From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of e= xt Shida Schubert Sent: 16 February, 2009 11:31 To: bliss@ietf.org Subject: [BLISS] Minutes from the BLISS-REST teleconf All; Attached is a minutes from our first BLISS-REST design team meeting. I want to thank the members of design team to put aside time to attend the meeting and contribute. We really need some more use-cases beside what's already mentioned in the ACH analysis and ach-config-requirements draft. Please do submit a comment if you have any use-cases for REST like protocol in the context of ACH. Meeting Date: 2009.02.06 Note-taker: Shida Schubert Attendees: Andrew Christien Kemo Salvatore Sanjay Simon Shida Theo 1. Debate about the scoping of the REST-BLISS activity. - Need to distinguish from XCAP. - Chair asked the motivation behind what Nokia is doing with regards to XCAP/HTTP+CPL and the background behind Marku's comment. - Kemo explained that Markus's comment was based on the requirements draft. draft-zourzouvillys-bliss-ach-config-requirements - Kemo further went on to explain that in the req draft, something like time based policy etc. was being discussed. - Based on the req, if Common Policy based ruleset is necessary, it's already defined in 3GPP or may be something like CPL + HTTP may be considered? > Kemo suggested that if policy based ruleset is to be considered, the design team should look at the ongoing work in 3GPP.. - Salvatore expressed that even if REST approach is taken, there is still a need to identify the resources available for alteration. - Salvatore also added the need to decide anything that is important enough to be referenced as a thing in itself, namely resource. Then associate to each resource at least one URI, and decide the struc= ture of that URI in a way that should vary in a predictable way. - Simon pointed out the following points about adopting REST like approach as it has been debated in XCON. > Application level error codes and transport level error codes, and where error codes are to be sent need to be carefully considere= d > Can simply use HTTP error + body with error indication > Salvatore explained that REST is a set of design criteria, not very w= ell specified anywhere. However one defining feature of a RESTful architecture is its use of HTTP response code,where an error response code is a signal to the client that the metadata (headers) and entity-body should not be interpreted as a response to the request. In general a first step we should take is to agree on the set of design criteria we consider to be REST. > Debate on why use REST? XCAP? > Salvatore commented that XCAP can be considered a RESTful protocol, maybe not 100% pure REST. > Salvatore explained the possibility to modify XCAP to be 100% RESTful= compliant, and re-utilize all the stuff that has been already defined for XCAP, like e= vent packages, etc.etc. > Sanjay asked if we are designing SIP-REST general framework. > Shida explained that at the last meeting, as part of the scope of BLISS WG, BLISS will not design a general framework and focus only on the use-cases of ACH but do not limit the extensibility and further usage. > It was agreed that we need use-cases/requirements > Sanjay asked if we want to gather use-cases for anything or ACH? > Shida suggests to open up for anything. > Andrew argued that that we should focus on ACH only. > Shida agress. > Debate on the current requirements draft. draft-zourzouvillys-bliss-ach-config-requirements > Has a lot in there.. > Theo agreed, and explained that it was because it included everything people expressed for its potential uses. > It was pointed out that by presenting the draft, we were able to narrow the scope of this work a tad. Conclusion: We need use-cases/requirements. Especially use-cases beside what's mentioned in the ACH draft. Many Thanks Shida --_000_B23B311878A0B4438F5F09F47E01AAE027EAFC6ED1NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
in case someone's wondering, Kemo =3D> Simo=20 ;)

Cheers,
Simo

From: bliss-bounces@ietf.org=20 [mailto:bliss-bounces@ietf.org] On Behalf Of ext Shida=20 Schubert
Sent: 16 February, 2009 11:31
To:=20 bliss@ietf.org
Subject: [BLISS] Minutes from the BLISS-REST=20 teleconf

All;

 Attached is a minutes from our first BLISS-REST design=20 team 
meeting. I want to thank the members of design team to put=20 aside 
time to attend the meeting and contribute.

 We really need some more use-cases beside what's=20 already 
mentioned in the ACH analysis and ach-config-requirements
 draft. Please do submit a comment if you have any=20 use-cases 
for REST like protocol in the context of ACH. 

Meeting Date: 2009.02.06
Note-taker: Shida Schubert
Attendees: 
   Andrew
   Christien
   Kemo
   Salvatore
   Sanjay
   Simon
   Shida
   Theo 

1. Debate about the scoping of the REST-BLISS activity. 
  - Need to distinguish from XCAP. 
    - Chair asked the motivation behind what Nokia is= =20 doing with regards
       to XCAP/HTTP+CPL and the background behin= d=20 Marku's comment. 

    - Kemo explained that Markus's comment was based = on=20 the 
       requirements draft. 
       draft-zourzouvillys-bliss-ach-config-requirements
 
    - Kemo further went on to explain that in the req= =20 draft, something like 
       time based policy etc. was being=20 discussed. 
    - Based on the req, if Common Policy based rulese= t is=20 necessary, 
       it's already defined in 3GPP or may = be=20 something like CPL + HTTP
       may be considered?
   >  Kemo suggested that if policy based ruleset = is to=20 be considered, 
        the design team should look at the= =20 ongoing work in 3GPP..

  - Salvatore expressed that even if REST approach is take= n,=20 there is still 
    a need to identify the resources available f= or=20 alteration.
  - Salvatore also added the need to decide anything = that=20 is important
     enough to be referenced as a thing in itself, na= mely=20 resource.
     Then associate to each resource at least= one=20 URI, and decide the structure of that URI 
     in= a=20 way that should vary in a predictable way.

  - Simon pointed out the following points about adopting = REST=20 like 
    approach as it has been debated in XCON.  
     > Application level error codes and transport= =20 level error codes, 
        and where error codes are to be sen= t=20 need to be carefully considered 
     > Can simply use HTTP error + body with error= =20 indication
  
    > Salvatore explained that REST is a set of de= sign=20 criteria, not very well 
specified anywhere. However one defining feature of a RESTful=20 architecture 
is its use of HTTP response code,where an error response code i= s a=20 signal 
to the client that the metadata (headers) and entity-body should=20 not be 
interpreted as a response to the request. In general a first st= ep we=20 should 
take is to agree on the set of design criteria we consider to be=20 REST.

     > Debate on why use REST? XCAP? 

    >  Salvatore commented that XCAP can be=20 considered a RESTful protocol,
        maybe not 100% pure REST. 
    > Salvatore explained the possibility to modif= y=20 XCAP to be 100% RESTful compliant,
and re-utilize all the stuff that h= as=20 been already defined for XCAP, like event packages, etc.etc.

> Sanjay asked if we are designing SIP-REST general=20 framework. 
  > Shida explained that at the last meeting, as part o= f the=20 scope of BLISS 
     WG, BLISS will not design a general framework an= d=20 focus only on the 
     use-cases of ACH but do not limit the extensibil= ity=20 and further usage.

> It was agreed that we need use-cases/requirements
  > Sanjay asked if we want to gather use-cases for any= thing=20 or ACH?
   > Shida suggests to open up for anything.
   > Andrew argued that that we should focus on ACH=20 only. 
     > Shida agress. 

> Debate on the current requirements draft.
       draft-zourzouvillys-bliss-ach-config-requirements
 > Has a lot in there.. 
  > Theo agreed, and explained that it was because it=20 included 
    everything people expressed for its potentia= l=20 uses. 
  > It was pointed out that by presenting the draft, we= were=20 able 
     to narrow the scope of this work a tad.

Conclusion: We need use-cases/requirements. Especially=20 use-cases 
beside what's mentioned in the ACH draft.  

Many Thanks
  Shida 
--_000_B23B311878A0B4438F5F09F47E01AAE027EAFC6ED1NOKEUMSG01mgd_-- From shida@ntt-at.com Wed Feb 25 18:22:03 2009 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 B7FA728C258 for ; Wed, 25 Feb 2009 18:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Y1zwIMuJF5-H for ; Wed, 25 Feb 2009 18:22:03 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.179.27]) by core3.amsl.com (Postfix) with SMTP id 4A79D3A6783 for ; Wed, 25 Feb 2009 18:21:59 -0800 (PST) Received: (qmail 1377 invoked from network); 26 Feb 2009 02:39:35 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway09.websitewelcome.com with SMTP; 26 Feb 2009 02:39:35 -0000 Received: from fl1-119-242-13-244.tky.mesh.ad.jp ([119.242.13.244]:49748 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LcVtC-0002RS-DO for bliss@ietf.org; Wed, 25 Feb 2009 20:22:18 -0600 Message-Id: <5683CA29-A9D9-457D-BA76-4BB081AEFFFB@ntt-at.com> From: Shida Schubert To: bliss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 11:22:15 +0900 X-Mailer: Apple Mail (2.930.3) 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 Subject: [BLISS] Minutes from BLISS-REST teleconference #2 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, 26 Feb 2009 02:22:03 -0000 Below is the minutes from the 2nd meeting on REST usage for ACH. I like to thank who attended the call and send my special thanks to Theo who lead the call and took notes. ** Minutes ** Note-Taker: Theo Zourzouvillys Attendees: - Christian Schmidt - Salvatore Loreto - Theo Zourzouvillys 1. Discussion on comments sent to list from Salvatore - Salvatore believes it would be possible implement an "XCAP-Lite" that would be simple for implements but "forward compatable" with full XCAP implementations - Theo re-iterated the current goals of the group: solve real world issues by using a simple solution that addresses just our current 12 use cases. 2. Review of use cases provided by Shida: * Call forwarding unconditional: either to voicemail or to any other number. * Call forwarding on busy: either to voicemail or to any other number. * Call forwarding on no answer: either to voicemail or to any other number. * Call forwarding when not registered: either to voicemail or to any other number. * Call forwarding when not reachable: either to voicemail or to any other number. * Barring on all outgoing calls: on/off * Barring on all outgoing international calls: on/off * Barring on all outgoing calls when roaming except to own service provider: on/off * Barring on all incoming calls: on/off * Barring on all incoming calls when roaming: on/off * Enabling/Disabling anonymous call reject. * Enabling/Disabling the ability to reject call when call is anonymous. * Enabling/Disabling call-waiting * Enabling/Disabling voicemail (This is probably equal to the forwarding Markus presented) * Enabling/Disabling DND Outcome: There were no objections or additions to this list - theo commented that we should limit the solution to these 12 for the SF draft. - all present agreed - theo commented that our initial solution should not try to be extensible. 3. Discussion on how to approach. - Salvatore will try and outline an XCAP-Lite solution in an email - no thoughts on potential solutions - theo will submit an initial -00 draft solution to start some discussion on list - It would be good to have some more infor on "XCAP-Lite" so we can compare - but Salvatore has no time before SF. will try though. 4. Action Items - Salvatore will try to outline XCAP-Lite ideas in an email to the list - Theo will write a -00 draft that provides a simple RESTful solution the 12 use cases we've agreed to tackle - Theo will talk to Shida about updating the ach reqs draft 5. Next Meeting - only 3 (!!) participants. Perhaps Thursday would be better. - will ask list - next call tentatively scheduled for Thursday 26th Feb 1400 GMT. From shida@ntt-at.com Wed Feb 25 18:24:31 2009 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 B17E628C2D9 for ; Wed, 25 Feb 2009 18:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 sGJmX+k0r1na for ; Wed, 25 Feb 2009 18:24:31 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.15.8]) by core3.amsl.com (Postfix) with SMTP id E398D28C2A7 for ; Wed, 25 Feb 2009 18:24:30 -0800 (PST) Received: (qmail 5953 invoked from network); 26 Feb 2009 02:42:07 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway09.websitewelcome.com with SMTP; 26 Feb 2009 02:42:07 -0000 Received: from fl1-119-242-13-244.tky.mesh.ad.jp ([119.242.13.244]:49750 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LcVve-00032g-BF for bliss@ietf.org; Wed, 25 Feb 2009 20:24:51 -0600 Message-Id: From: Shida Schubert To: bliss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 11:24:47 +0900 X-Mailer: Apple Mail (2.930.3) 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 Subject: [BLISS] Use-Cases for ACH 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, 26 Feb 2009 02:24:31 -0000 All; Below are the use-cases that have come up so far on the list and among the design team. We will use these as a starting point to evaluate REST usage for ACH but would like more feedback on the use-cases presented below. * Call forwarding unconditional: either to voicemail or to any other number. * Call forwarding on busy: either to voicemail or to any other number. * Call forwarding on no answer: either to voicemail or to any other number. * Call forwarding when not registered: either to voicemail or to any other number. * Call forwarding when not reachable: either to voicemail or to any other number. * Barring on all outgoing calls: on/off * Barring on all outgoing international calls: on/off * Barring on all outgoing calls when roaming except to own service provider: on/off * Barring on all incoming calls: on/off * Barring on all incoming calls when roaming: on/off * Enabling/Disabling anonymous call reject. * Enabling/Disabling the ability to reject call when call is anonymous. * Enabling/Disabling call-waiting * Enabling/Disabling voicemail (This is probably equal to the forwarding Markus presented) * Enabling/Disabling DND Regards Shida From dworley@nortel.com Fri Feb 27 11:44:55 2009 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 6C4423A67E4 for ; Fri, 27 Feb 2009 11:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 gVaL8N-gjSke for ; Fri, 27 Feb 2009 11:44:54 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 628DD3A63D3 for ; Fri, 27 Feb 2009 11:44:54 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n1RJj9J03799; Fri, 27 Feb 2009 19:45:09 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 14:45:08 -0500 From: "Dale Worley" To: Shida Schubert In-Reply-To: References: Content-Type: text/plain Organization: Nortel Networks Date: Fri, 27 Feb 2009 14:45:07 -0500 Message-Id: <1235763907.3834.37.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2009 19:45:08.0493 (UTC) FILETIME=[E529F3D0:01C99913] Cc: bliss@ietf.org Subject: Re: [BLISS] Use-Cases for ACH 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: Fri, 27 Feb 2009 19:44:55 -0000 The following list of settings has been proposed. I'd like to make sure that there is consensus on the interaction between them. On Thu, 2009-02-26 at 11:24 +0900, Shida Schubert wrote: > * Call forwarding unconditional: either to voicemail or to any other > number. > * Call forwarding on busy: either to voicemail or to any other number. > * Call forwarding on no answer: either to voicemail or to any other > number. > * Call forwarding when not registered: either to voicemail or to any > other number. > * Call forwarding when not reachable: either to voicemail or to any > other number. My impression is that each of these "call forwarding" conditions can be set or cleared independently, but that "unconditional" overrides the other settings, and "no answer" is overridden by "not registered" and "not reachable" when they are applicable. > * Barring on all outgoing calls: on/off > * Barring on all outgoing international calls: on/off > * Barring on all outgoing calls when roaming except to own service > provider: on/off > * Barring on all incoming calls: on/off > * Barring on all incoming calls when roaming: on/off > > * Enabling/Disabling anonymous call reject. > * Enabling/Disabling the ability to reject call when call is > anonymous. > * Enabling/Disabling call-waiting > * Enabling/Disabling voicemail (This is probably equal to the > forwarding Markus presented) > * Enabling/Disabling DND Each of the barring and enable/disable settings seem to be independent. Call-waiting is always implemented locally on the phone in SIP, so I don't see the need for a SIP ACH function for it. I originally thought that barring outgoing calls is not sensible for ACH, because SIP ACH is a user-operated feature and the user has control of what calls the phone makes, but I was wrong -- the UA can initiate INVITEs due to in-dialog REFER, and so "barring outgoing" functions prevent the UA from automatically following REFERs that the user doesn't want followed. But it looks like "barring outgoing" functions are all implemented in the UA, and so aren't an ACH function per se. ("Barring incoming" needs to be done at the proxy, so that's an ACH function.) Dale From dworley@nortel.com Fri Feb 27 12:59:32 2009 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 DBDB73A657C for ; Fri, 27 Feb 2009 12:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 3u68hwcwP8BX for ; Fri, 27 Feb 2009 12:59:31 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 856423A6358 for ; Fri, 27 Feb 2009 12:59:31 -0800 (PST) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n1RKxfO07999 for ; Fri, 27 Feb 2009 20:59:41 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 15:59:49 -0500 From: "Dale Worley" To: BLISS Content-Type: text/plain Organization: Nortel Networks Date: Fri, 27 Feb 2009 15:59:48 -0500 Message-Id: <1235768388.3834.73.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Feb 2009 20:59:49.0139 (UTC) FILETIME=[53D64630:01C9991E] Subject: [BLISS] Some of Andrew Hutton's concerns about draft-ietf-bliss-call-completion-03 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: Fri, 27 Feb 2009 20:59:32 -0000 [These are keyed to the issue identifiers in the list of open issues we keep on the BLISS-CC mailing list.] > * 1003 Hutton: CC URI > > "Hutton, Andrew" > Section 5.6: "Question: Should the callee's monitor supply a URI which > should be used in the CC call?" > I think it should. This text has been moved to section 5.7 of -03. The current text is: "The notification MAY also contain also a URI which should be used in the CC call. In practice, this may be the AOR of the callee." I think we should change the MAY to SHOULD. > * 1005 Hutton: Failure > > "Hutton, Andrew" > Section 5.6: "Can a call appear to succeed from the monitor's point of > view but fail from the calling user's point of view?" > It is not clear to me what constitutes success from the monitor's point > of view. Does just getting back a 180 constitute success? If so, from > the caller's perspective the call could still fail to be answered, so it > would be up to the caller to invoke CCNR (again) if that is what he > wants In section 5.5 of -03, the text is: Note that from the SIP point of view, the INVITE may be successful, but from the user's point of view, the call may be unsuccessful. E.g., the call may have connected to the callee's voicemail, which would return a 200 status to the INVITE but from the caller's point of view is "no reply". I think this satisfies your concern. > * 3004 Hutton: Failure of initial call > > "Hutton, Andrew" > Terminology: "CC request: (1) the indication by the caller to the > caller's agent that the caller desires CC for a failed original call". > Why does there have to be a failed original call should it be possible > to initiate a CC request with no previous call or even if the previous > call was "successful". The concept of "failure" really only applies to > the user and cannot be specified. > * 3005 Hutton: Queue > > "Hutton, Andrew" > Terminology: "Call-completion queue: a buffer at the callee' monitor > which stores incoming calls which have failed or may have failed" > Presumably this means that it is left to the implementation to decide > what failed means and that potentially all calls will be in this "queue"? It does appear that these definitions need to be revised so that "failed" is not seen as restrictive. > * 1006 Hutton: 180 Ringing > > "Hutton, Andrew" > Section 6: I think that the URI of the monitor (i.e. Call-Info) should > be included also in a 180 Ringing because the caller may need to know > that callback is available before deciding to give up on the ringing > call. That is a good point, and I think that the group agreed with it when you made it, but the -03 text does not reflect that consensus. I will propose some edits about this. > * 3002 Hutton: Location of agents > > "Hutton, Andrew" : > Abstract: "implementations at the caller's and callee's endpoints > cooperate to place the caller's request for call completion into a queue > at the callee's endpoint". > I think the draft gives some mixed messages regarding the options for > where the caller's and callee's agent may be located and some > clarification is needed. Maybe the abstract should make it clear that > the document does not specify the location of the agents. Yes, I think that sentence in the Abstract needs to be revised. The idea we want to convey is that the agent/monitor can be in the UAs themselves, or be in "servers" that are presumably involved in the endpoint's networks. > * 3003 Hutton: Appendixes > > "Hutton, Andrew" > Introduction: "As a proof-of-concept, simple agents and monitors can be > devised that interact with users and UAs entirely through standard SIP > mechanisms [RFC3265], [RFC4235] and [RFC3515], as described in the > Appendixes". > The appendixes do I think add to the confusion regarding where the > caller's agent is located as it describes features codes being used to > invoke the service which seems at odd's with the abstract. > * 3009 Hutton: Example > > "Hutton, Andrew" > Appendix A. "Example Caller's Agent". > This is an example of using a feature code to invoke the feature from > the "UA" would it be possible to also include an example where the agent > is in the UA ? We could write such an example, but I don't think that it would add much to the document. The call flow example in section 6 of -03 shows what behavior would look like if the agent/monitor were integrated into the UAs. Indeed, the point of the Appendixes is to show that one can separate the agent/monitor from the UAs and still use SIP signaling to coordinate the agent/monitor with their respective UAs. Dale From sanjsinh@cisco.com Fri Feb 27 22:01:06 2009 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 E8F6B3A6A8D for ; Fri, 27 Feb 2009 22:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 EefJYsQ9+EOF for ; Fri, 27 Feb 2009 22:01:05 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 932073A699D for ; Fri, 27 Feb 2009 22:01:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,280,1233532800"; d="scan'208";a="258642558" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2009 06:01:29 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1S61STe024093; Fri, 27 Feb 2009 22:01:28 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1S61SrY011630; Sat, 28 Feb 2009 06:01:28 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Feb 2009 01:01:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Feb 2009 01:01:25 -0500 Message-ID: In-Reply-To: <1235763907.3834.37.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use-Cases for ACH Thread-Index: AcmZE+5DyvOg8KjyT9iREdtxDcU6lAAVRZxw References: <1235763907.3834.37.camel@victoria-pingtel-com.us.nortel.com> From: "Sanjay Sinha (sanjsinh)" To: "Dale Worley" , "Shida Schubert" X-OriginalArrivalTime: 28 Feb 2009 06:01:28.0586 (UTC) FILETIME=[FF0456A0:01C99969] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3097; t=1235800889; x=1236664889; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[BLISS]=20Use-Cases=20for=20ACH |Sender:=20; bh=ljxdslnrnrDqiArGXYNIHbj326339ZCzZya5zQs2tzI=; b=mVYAOjxxFRKRDfqZAQjIIqgGqiYng9jY/X01zq/SA0oR+rLSPIo2rZQLjw PB8UOwRQRaub0Q6ZlPNpwnb7/BZfWJbqg2EDKpGwaoSetpgthFUwhB1jfDlS 6PPfILnaGx; Authentication-Results: sj-dkim-3; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: bliss@ietf.org Subject: Re: [BLISS] Use-Cases for ACH 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: Sat, 28 Feb 2009 06:01:07 -0000 Pl. see inline .. >-----Original Message----- >From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 >On Behalf Of Dale Worley >Sent: Saturday, February 28, 2009 1:15 AM >To: Shida Schubert >Cc: bliss@ietf.org >Subject: Re: [BLISS] Use-Cases for ACH > >The following list of settings has been proposed. I'd like to=20 >make sure that there is consensus on the interaction between them. > >On Thu, 2009-02-26 at 11:24 +0900, Shida Schubert wrote: >> * Call forwarding unconditional: either to voicemail or to=20 >any other=20 >> number. >> * Call forwarding on busy: either to voicemail or to any=20 >other number. >> * Call forwarding on no answer: either to voicemail or to=20 >any other=20 >> number. >> * Call forwarding when not registered: either to voicemail=20 >or to any=20 >> other number. >> * Call forwarding when not reachable: either to voicemail=20 >or to any=20 >> other number. > >My impression is that each of these "call forwarding"=20 >conditions can be set or cleared independently, but that=20 >"unconditional" overrides the other settings, and "no answer"=20 >is overridden by "not registered" and "not reachable" when=20 >they are applicable. > >> * Barring on all outgoing calls: on/off >> * Barring on all outgoing international calls: on/off >> * Barring on all outgoing calls when roaming except to own service >> provider: on/off >> * Barring on all incoming calls: on/off >> * Barring on all incoming calls when roaming: on/off >>=20 >> * Enabling/Disabling anonymous call reject. >> * Enabling/Disabling the ability to reject call when call is=20 >> anonymous. >> * Enabling/Disabling call-waiting >> * Enabling/Disabling voicemail (This is probably equal to the=20 >> forwarding Markus presented) >> * Enabling/Disabling DND > >Each of the barring and enable/disable settings seem to be independent. > >Call-waiting is always implemented locally on the phone in=20 >SIP, so I don't see the need for a SIP ACH function for it. I think it is an ACH feature in the sense that the proxy can decide whether to extend the call to called party or send 486 otherwise. =20 > >I originally thought that barring outgoing calls is not=20 >sensible for ACH, because SIP ACH is a user-operated feature=20 >and the user has control of what calls the phone makes, but I=20 >was wrong -- the UA can initiate INVITEs due to in-dialog=20 >REFER, and so "barring outgoing" functions prevent the UA from=20 >automatically following REFERs that the user doesn't want followed. > >But it looks like "barring outgoing" functions are all=20 >implemented in the UA, and so aren't an ACH function per se. =20 >("Barring incoming" needs to be done at the proxy, so that's=20 >an ACH function.) How about the case where a system administrator sets barring outgoing calls based on Class of Service for a given user. Sanjay > >Dale > > >_______________________________________________ >BLISS mailing list >BLISS@ietf.org >https://www.ietf.org/mailman/listinfo/bliss >