From pkyzivat@alum.mit.edu Tue Sep 4 08:06:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5231F0417 for ; Tue, 4 Sep 2012 08:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qkPTHLYoS5e for ; Tue, 4 Sep 2012 08:06:57 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCB91F040A for ; Tue, 4 Sep 2012 08:06:50 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id uxgw1j00C16LCl05336tRE; Tue, 04 Sep 2012 15:06:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id v36Z1j0023ZTu2S3S36Z4q; Tue, 04 Sep 2012 15:06:33 +0000 Message-ID: <50461908.5090001@alum.mit.edu> Date: Tue, 04 Sep 2012 11:06:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <503BD22D.2060007@alum.mit.edu> In-Reply-To: <503BD22D.2060007@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 15:06:59 -0000 This WGLC is now closed. I would like to thank Atle Monrad for being the *one* person to respond to it. That doesn't indicate a very high level of interest in this draft. But given the generally superficial nature of the changes I am interpreting the absence of comment as indication that there is no objection. Thank you, Paul (as co-chair) On 8/27/12 4:01 PM, Paul Kyzivat wrote: > Sorry to do this again, but we need to do another WGLC on > draft-ietf-sipcore-proxy-feature-08. > > The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, > September 3, 2012. (A week should be enough considering the nature of > the changes since the last WGLC.) > > This covers changes since the last WGLC, which was for the -02 version. > Those changes were to cover things I found while writing the document up > for submission to the iesg, and things found by Robert Sparks in his AD > review. Most of those things were editorial, but some of them were quite > heavy editorial, such as rearranging sections of the document. (This > causes the diff to version -02 to be largely worthless.) > > There was one significant change that isn't editorial. We changed the > review policy for registering new feature capability indicators in the > global tree from Expert Reveiw to Specification Required. This isn't a > big change, since we were always requiring a specification. But it is a > better fit. (This doesn't require an RFC, only a specification that can > be referenced permanently.) > > Please look at this and then indicate you acceptance or issues here on > the mailing list. We really need responses to indicate that it has been > reviewed. > > Some helpful links: > > The draft version being reviewed: > http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 > > Diff from version -06 (recent changes): > http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-06.txt > > > Diff from version -02 (the subject of the last WGLC): > http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-02.txt > > > Thanks, > Paul (as co-chair) > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From internet-drafts@ietf.org Tue Sep 4 10:19:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7A221E803A; Tue, 4 Sep 2012 10:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6J1-96j7Lt0q; Tue, 4 Sep 2012 10:19:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B601911E809A; Tue, 4 Sep 2012 10:19:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120904171938.4583.36740.idtracker@ietfa.amsl.com> Date: Tue, 04 Sep 2012 10:19:38 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:19:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-09.txt Pages : 21 Date : 2012-09-04 Abstract: This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Tue Sep 4 10:20:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4F11E809A for ; Tue, 4 Sep 2012 10:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiMZm2QWe+EX for ; Tue, 4 Sep 2012 10:20:42 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8749B11E80A5 for ; Tue, 4 Sep 2012 10:20:41 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-7d-50463868656a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C8.67.17130.86836405; Tue, 4 Sep 2012 19:20:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 4 Sep 2012 19:20:40 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "sipcore@ietf.org" Date: Tue, 4 Sep 2012 19:20:39 +0200 Thread-Topic: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 Thread-Index: Ac2KrvMO7A64bgcKShGr0oYtQ84X9QAEo+og Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A9D@ESESSCMS0356.eemea.ericsson.se> References: <503BD22D.2060007@alum.mit.edu> <50461908.5090001@alum.mit.edu> In-Reply-To: <50461908.5090001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvrW6GhVuAwdo1WhYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXR/msmS0GjZMWmVb9ZGhjvinQxcnJICJhI 3F75gBXCFpO4cG89WxcjF4eQwClGicc7vjJBOPMZJfq+XmDuYuTgYBOwkOj+pw3SICIQLPGu qZkFxGYRUJE4sqKTHcQWBorfndDIDFETInHl8jM2CNtIYsfS/2D1vALhEs8XTQWzhQS8JX49 v8QIYnMK6Eg8WNcBVs8IdND3U2uYQGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sEPWiEnfa 1zNC1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo3BuYmZO erm5XmpRZnJxcX6eXnHqJkZgjBzc8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYJSvnnbsTPW6kDc6tQmpopvzL3+2S4tU2vNG9W183KunNxN/Xt+z2OTb jOenfJVWWqmvMzjDZbLKeqJB6RQfqW0lF2Pv8V84sM+wNFi8NaGlXMRHgmlyscyqRu9LapNn TNte84+F4yPbyS2J39sXFfgK1O9ScXxVt37C/p1XPa5ZM0Wu3Bj41ECJpTgj0VCLuag4EQAI +wB6XwIAAA== Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:20:43 -0000 Hi, Based on off-line discussion with Paul, I've submitted a new version (-09) = of the proxy-feature draft, implementing the changes based on Atle's commen= ts. Thanks! Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 4. syyskuuta 2012 18:07 To: sipcore@ietf.org Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feat= ure-08 This WGLC is now closed. I would like to thank Atle Monrad for being the *one* person to respond to it. That doesn't indicate a very high level of interest in this draft. But give= n the generally superficial nature of the changes I am interpreting the abs= ence of comment as indication that there is no objection. Thank you, Paul (as co-chair) On 8/27/12 4:01 PM, Paul Kyzivat wrote: > Sorry to do this again, but we need to do another WGLC on=20 > draft-ietf-sipcore-proxy-feature-08. > > The WGLC will run for a week. It will conclude at 23:59 UTC on Monday,=20 > September 3, 2012. (A week should be enough considering the nature of=20 > the changes since the last WGLC.) > > This covers changes since the last WGLC, which was for the -02 version. > Those changes were to cover things I found while writing the document=20 > up for submission to the iesg, and things found by Robert Sparks in=20 > his AD review. Most of those things were editorial, but some of them=20 > were quite heavy editorial, such as rearranging sections of the=20 > document. (This causes the diff to version -02 to be largely=20 > worthless.) > > There was one significant change that isn't editorial. We changed the=20 > review policy for registering new feature capability indicators in the=20 > global tree from Expert Reveiw to Specification Required. This isn't a=20 > big change, since we were always requiring a specification. But it is=20 > a better fit. (This doesn't require an RFC, only a specification that=20 > can be referenced permanently.) > > Please look at this and then indicate you acceptance or issues here on=20 > the mailing list. We really need responses to indicate that it has=20 > been reviewed. > > Some helpful links: > > The draft version being reviewed: > http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 > > Diff from version -06 (recent changes): > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-08 > .txt;url1=3Ddraft-ietf-sipcore-proxy-feature-06.txt > > > Diff from version -02 (the subject of the last WGLC): > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-08 > .txt;url1=3Ddraft-ietf-sipcore-proxy-feature-02.txt > > > Thanks, > Paul (as co-chair) > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From iesg-secretary@ietf.org Tue Sep 4 14:04:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED3A21E8054; Tue, 4 Sep 2012 14:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOXlgvV9Cg1c; Tue, 4 Sep 2012 14:04:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AC711E809A; Tue, 4 Sep 2012 14:04:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120904210403.31502.13552.idtracker@ietfa.amsl.com> Date: Tue, 04 Sep 2012 14:04:03 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:04:04 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature/ballot/ No IPR declarations have been submitted directly on this I-D. From keith.drage@alcatel-lucent.com Wed Sep 5 01:26:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9753D21F8698 for ; Wed, 5 Sep 2012 01:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE5ujg2kSyw9 for ; Wed, 5 Sep 2012 01:26:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B45E321F8690 for ; Wed, 5 Sep 2012 01:26:35 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q858QPGg005469 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Sep 2012 10:26:32 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 5 Sep 2012 10:26:22 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 5 Sep 2012 10:24:54 +0200 Thread-Topic: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 Thread-Index: Ac2KrvYvvYq/k3aAQ/6NtNHrYsQY1gAkOD2w Message-ID: References: <503BD22D.2060007@alum.mit.edu> <50461908.5090001@alum.mit.edu> In-Reply-To: <50461908.5090001@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:26:36 -0000 I did check my prior comments were adequately handled, but I thought that w= as already clear. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 04 September 2012 16:07 > To: sipcore@ietf.org > Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy- > feature-08 >=20 > This WGLC is now closed. I would like to thank Atle Monrad for being the > *one* person to respond to it. >=20 > That doesn't indicate a very high level of interest in this draft. But > given the generally superficial nature of the changes I am interpreting > the absence of comment as indication that there is no objection. >=20 > Thank you, > Paul (as co-chair) >=20 > On 8/27/12 4:01 PM, Paul Kyzivat wrote: > > Sorry to do this again, but we need to do another WGLC on > > draft-ietf-sipcore-proxy-feature-08. > > > > The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, > > September 3, 2012. (A week should be enough considering the nature of > > the changes since the last WGLC.) > > > > This covers changes since the last WGLC, which was for the -02 version. > > Those changes were to cover things I found while writing the document u= p > > for submission to the iesg, and things found by Robert Sparks in his AD > > review. Most of those things were editorial, but some of them were quit= e > > heavy editorial, such as rearranging sections of the document. (This > > causes the diff to version -02 to be largely worthless.) > > > > There was one significant change that isn't editorial. We changed the > > review policy for registering new feature capability indicators in the > > global tree from Expert Reveiw to Specification Required. This isn't a > > big change, since we were always requiring a specification. But it is a > > better fit. (This doesn't require an RFC, only a specification that can > > be referenced permanently.) > > > > Please look at this and then indicate you acceptance or issues here on > > the mailing list. We really need responses to indicate that it has been > > reviewed. > > > > Some helpful links: > > > > The draft version being reviewed: > > http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 > > > > Diff from version -06 (recent changes): > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature- > 08.txt;url1=3Ddraft-ietf-sipcore-proxy-feature-06.txt > > > > > > Diff from version -02 (the subject of the last WGLC): > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature- > 08.txt;url1=3Ddraft-ietf-sipcore-proxy-feature-02.txt > > > > > > Thanks, > > Paul (as co-chair) > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Wed Sep 5 15:41:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691A21F86C7; Wed, 5 Sep 2012 15:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hen1P2JhkYSY; Wed, 5 Sep 2012 15:41:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED9A21F86C8; Wed, 5 Sep 2012 15:41:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905224139.14182.51191.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 15:41:39 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 22:41:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-09.txt Pages : 36 Date : 2012-09-05 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Wed Sep 5 16:03:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132AA21F86D5 for ; Wed, 5 Sep 2012 16:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd2Dr3+paV4n for ; Wed, 5 Sep 2012 16:03:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89BFB21F86CF for ; Wed, 5 Sep 2012 16:03:46 -0700 (PDT) Received: by lbky2 with SMTP id y2so842129lbk.31 for ; Wed, 05 Sep 2012 16:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9p/hOdVJQTSEcJda8hS20ut/CXth+mVGWtxNB7658xk=; b=eblLsPw6iaHWczQDAPm4/vhEoRpwd98nhm8dditBs9k8tIoqKpQgxcJyaVcxBP19d0 IFDLtvHOkpBoEOsHd9MdSs6IC6gW7UG98AQAw71v0ZQcuOOUar7Ho1qgFkuw8nBsArUk +76GgtsWGpYGlAE0Bpc+9I/3mK9JI5gX3ilt06VfvTUjLY6fD7DUyuxpyYgsHeJEYlQo GsI7pbACGxFFcVnz290uYJeAeuYqrXTSC9e7Cx9nt1HxUyI1Fhf6yUc1COZo5MHhJVyZ az9mQNNQkhW743s2VIEGKcaRLCcROWhakwyUGWKQDuhpclOINCMcqXp8OEqDKJ781ubs SRbw== MIME-Version: 1.0 Received: by 10.112.17.161 with SMTP id p1mr173882lbd.64.1346886225275; Wed, 05 Sep 2012 16:03:45 -0700 (PDT) Received: by 10.112.17.202 with HTTP; Wed, 5 Sep 2012 16:03:45 -0700 (PDT) In-Reply-To: <5037CBE7.6070006@nostrum.com> References: <5037CBE7.6070006@nostrum.com> Date: Wed, 5 Sep 2012 18:03:45 -0500 Message-ID: From: Mary Barnes To: Robert Sparks Content-Type: multipart/alternative; boundary=bcaec554d32202ad8904c8fc63b3 Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "sipcore@ietf.org" Subject: Re: [sipcore] AD review: draft-ietf-sipcore-rfc4244bis-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:03:48 -0000 --bcaec554d32202ad8904c8fc63b3 Content-Type: text/plain; charset=ISO-8859-1 Robert and WG, We have submitted an updated version that we believe addresses the concerns raised, per the responses below. Here's the diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-09 * * Please let us know if you are okay with these changes. Regards, Mary et al On Fri, Aug 24, 2012 at 1:45 PM, Robert Sparks wrote: > Summary: There are a couple of questions to discuss before progressing to > IETF LC. > > This document is much easier to follow than RFC4244. It is still complex, > but the rewrite effort improved its readability significantly. > > There are a couple of things I would like the WG to consider before moving > into IETF LC. > > 1) Since the WG adopted the call-flows document, does this document still > need Appendix A, or should any of the examples there that are not already > in the call-flows document be moved to that document? > [MB] No. We have removed the call flows from this document and have added a reference to the call flows document. [/MB] > > 2) The document requires that redirect servers include an hi-target-param > in the Contact header fields it provides, and requires elements recursing > on redirect responses to only include hi-target-params that it finds in > those Contacts. They are specifically forbidden from providing the param if > there are no params in the Contact. Please consider saying why this is > required. If I recall the conversation correctly, it's because the redirect > server is the only element that can tell whether mp or rc would be > appropriate. For np, however, it's not clear why this requirement exists. > Is it just to keep things simple? > [MB] We have updated the text to reflect that only mp and rc are relevant in this scenario. [/MB] > > 3) Section 103 step 6 says "If the request clearly has a gap", but I don't > see any description of what an element is supposed to look for to determine > there is a gap. From a discussion with Mary, it should be as simple as > comparing the last HI entry to the Request-URI. If that's right, please add > that to this description, and make it clear that you would only add one .0. > when identifying a gap, not try to figure out how many elements may have > not added history (that is, you would never produce something that looked > like 1.0.0.1). > [MB] We have added text to indicate that it is simply that the URI in the hi-entry doesn't match the request URI. Hopefully, the text around the .0 is more clear. [/MB] > > 4) The Changes from RFC4244 section doesn't call out the new .0. gap > detection/representation mechanic. > [MB] That's been added. [/MB} > > 5) The backwards compatibility consideration focuses on exploring how > RFC4244 elements will deal with messages created following this > specification. There should be some additional exploration of how elements > implementing this specification will deal with messages created by RFC4244 > elements. Those messages could be missing things this specification says > MUST be there. Can we make it more likely that an implementer won't create > code that rejects such messages as malformed? > [MB] We added text indicating that this needs to be considered per the application considerations section (i.e., applications need default behavior in the case of missing information in per 4244 and now this document). [/MB] > > > Nits: > > At the definition of hi-index, the document talks of "nesting of > requests". It's the only place the word nesting occurs in the document. > Could you provide a description/definition or a pointer to one? > [MB] We just clarified that this reflects the retargeting. The "nesting" concept is leftover from 4244 - it was referring to the number of dots. [/MB] > > The description of using an internal cache to describe how an element will > construct the history-info values it emits is likely to draw discussion > during IETF/IESG review. It uses 2119 language to describe a possible > implementation. Please consider changing the phrasing to make it clear that > the normative constraints are on what's emitted, not on they way you store > the information internally. > [MB] It really makes the text much less clear when we lose the concept of a cache. That was John Elwell's suggestion and it really describes how the information in the incoming request needs to be somehow maintained to build the outgoing requests. We have added text noting that the cache is just a copy. This is actually quite consistent (including use of normative language) with RFC 3261 when it describes the copying of information for the process of forwarding a request. [/MB] > > First paragraph of 10.4 still says "two header field parameters" and > "Both", but talks about three. > [MB] Fixed. [/MB] > > "As for the behavior of the entity followings have changed" does not parse. > [MB] Fixed. [/MB] > > In the first example in appendix A, the Contact in F3 has no parameters, > but the corresponding H-I value in F4 has an mp=1. The version of this > example in the callflow doc has the mp=1 in the Contact in the 302. > [MB] No longer there since we removed the call flows. [/MB] > > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --bcaec554d32202ad8904c8fc63b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Robert and WG,

We have submitted an updated version that= we believe addresses the concerns raised, per the responses below. =A0Here= 's the diff:

Please let us know if you are okay with these changes.

Regards,
Mary et al

On Fri, Aug= 24, 2012 at 1:45 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
Summary: There are a couple of questions to = discuss before progressing to IETF LC.

This document is much easier to follow than RFC4244. It is still complex, b= ut the rewrite effort improved its readability significantly.

There are a couple of things I would like the WG to consider before moving = into IETF LC.

1) Since the WG adopted the call-flows document, does this document still n= eed Appendix A, or should any of the examples there that are not already in= the call-flows document be moved to that document?
[MB] No. =A0We have removed the call flows from this document and have adde= d a reference to the call flows document. [/MB]=A0

2) The document requires that redirect servers include an hi-target-param i= n the Contact header fields it provides, and requires elements recursing on= redirect responses to only include hi-target-params that it finds in those= Contacts. They are specifically forbidden from providing the param if ther= e are no params in the Contact. Please consider saying why this is required= . If I recall the conversation correctly, it's because the redirect ser= ver is the only element that can tell whether mp or rc would be appropriate= . For np, however, it's not clear why this requirement exists. =A0Is it= just to keep things simple?
[MB] =A0We have updated the text to reflect that only mp = and rc are relevant in this scenario. =A0[/MB]=A0

3) Section 103 step 6 says "If the request clearly has a gap", bu= t I don't see any description of what an element is supposed to look fo= r to determine there is a gap. From a discussion with Mary, it should be as= simple as comparing the last HI entry to the Request-URI. If that's ri= ght, please add that to this description, and make it clear that you would = only add one .0. when identifying a gap, not try to figure out how many ele= ments may have not added history (that is, you would never produce somethin= g that looked like 1.0.0.1).
[MB] We have added text to indicate that it is simply tha= t the URI in the hi-entry doesn't match the request URI. =A0Hopefully, = the text around the .0 is more clear. [/MB]=A0

4) The Changes from RFC4244 section doesn't call out the new .0. gap de= tection/representation mechanic.
[MB] That's been = added. [/MB}=A0

5) The backwards compatibility consideration focuses on exploring how RFC42= 44 elements will deal with messages created following this specification. T= here should be some additional exploration of how elements implementing thi= s specification will deal with messages created by RFC4244 elements. Those = messages could be missing things this specification says MUST be there. Can= we make it more likely that an implementer won't create code that reje= cts such messages as malformed?
[MB] We added text indicating that this needs to be consi= dered per the application considerations section (i.e., applications need d= efault behavior in the case of missing information in per 4244 and now this= document). =A0[/MB]


Nits:

At the definition of hi-index, the document talks of "nesting of reque= sts". It's the only place the word nesting occurs in the document.= Could you provide a description/definition or a pointer to one?
[MB] We just clarified that this reflects the retargeting. =A0The &quo= t;nesting" concept is leftover from 4244 - it was referring to the num= ber of dots. =A0[/MB]=A0

The description of using an internal cache to describe how an element will = construct the history-info values it emits is likely to draw discussion dur= ing IETF/IESG review. It uses 2119 language to describe a possible implemen= tation. Please consider changing the phrasing to make it clear that the nor= mative constraints are on what's emitted, not on they way you store the= information internally.
[MB] It really makes the text much less clear when we los= e the concept of a cache. =A0That was John Elwell's suggestion and it r= eally describes how the information in the incoming request needs to be som= ehow maintained to build the outgoing requests. =A0We have added text notin= g that the cache is just a copy. This is actually quite consistent (includi= ng use of normative language) with RFC 3261 when it describes the copying o= f information for the process of forwarding a request. =A0[/MB]

First paragraph of 10.4 still says "two header field parameters" = and "Both", but talks about three.
[MB] Fixe= d. [/MB]=A0

"As for the behavior of the entity followings have changed" does = not parse.
[MB] Fixed. [/MB]=A0

In the first example in appendix A, the Contact in F3 has no parameters, bu= t the corresponding H-I value in F4 has an mp=3D1. The version of this exam= ple in the callflow doc has the mp=3D1 in the Contact in the 302.
[MB] No longer there since we removed the call flows. [/MB]=A0

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--bcaec554d32202ad8904c8fc63b3-- From rjsparks@nostrum.com Thu Sep 6 11:18:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D86B21F877C for ; Thu, 6 Sep 2012 11:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFT5kE-ka82L for ; Thu, 6 Sep 2012 11:18:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A72F21F8742 for ; Thu, 6 Sep 2012 11:18:35 -0700 (PDT) Received: from unnumerable.local (pool-173-57-93-208.dllstx.fios.verizon.net [173.57.93.208]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86IIU0e066669 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Sep 2012 13:18:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5048E8F6.6030202@nostrum.com> Date: Thu, 06 Sep 2012 13:18:30 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Mary Barnes References: <5037CBE7.6070006@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080204030601070803000006" Received-SPF: pass (nostrum.com: 173.57.93.208 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "sipcore@ietf.org" Subject: Re: [sipcore] AD review: draft-ietf-sipcore-rfc4244bis-08 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:18:37 -0000 This is a multi-part message in MIME format. --------------080204030601070803000006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Mary - I agree these address my points. I'm requesting IETF LC on this version. SIPCORE - please review these changes carefully. RjS On 9/5/12 6:03 PM, Mary Barnes wrote: > Robert and WG, > > We have submitted an updated version that we believe addresses the > concerns raised, per the responses below. Here's the diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-09 > / > / > Please let us know if you are okay with these changes. > > Regards, > Mary et al > > On Fri, Aug 24, 2012 at 1:45 PM, Robert Sparks > wrote: > > Summary: There are a couple of questions to discuss before > progressing to IETF LC. > > This document is much easier to follow than RFC4244. It is still > complex, but the rewrite effort improved its readability > significantly. > > There are a couple of things I would like the WG to consider > before moving into IETF LC. > > 1) Since the WG adopted the call-flows document, does this > document still need Appendix A, or should any of the examples > there that are not already in the call-flows document be moved to > that document? > > [MB] No. We have removed the call flows from this document and have > added a reference to the call flows document. [/MB] > > > 2) The document requires that redirect servers include an > hi-target-param in the Contact header fields it provides, and > requires elements recursing on redirect responses to only include > hi-target-params that it finds in those Contacts. They are > specifically forbidden from providing the param if there are no > params in the Contact. Please consider saying why this is > required. If I recall the conversation correctly, it's because the > redirect server is the only element that can tell whether mp or rc > would be appropriate. For np, however, it's not clear why this > requirement exists. Is it just to keep things simple? > > [MB] We have updated the text to reflect that only mp and rc are > relevant in this scenario. [/MB] > > > 3) Section 103 step 6 says "If the request clearly has a gap", but > I don't see any description of what an element is supposed to look > for to determine there is a gap. From a discussion with Mary, it > should be as simple as comparing the last HI entry to the > Request-URI. If that's right, please add that to this description, > and make it clear that you would only add one .0. when identifying > a gap, not try to figure out how many elements may have not added > history (that is, you would never produce something that looked > like 1.0.0.1). > > [MB] We have added text to indicate that it is simply that the URI in > the hi-entry doesn't match the request URI. Hopefully, the text > around the .0 is more clear. [/MB] > > > 4) The Changes from RFC4244 section doesn't call out the new .0. > gap detection/representation mechanic. > > [MB] That's been added. [/MB} > > > 5) The backwards compatibility consideration focuses on exploring > how RFC4244 elements will deal with messages created following > this specification. There should be some additional exploration of > how elements implementing this specification will deal with > messages created by RFC4244 elements. Those messages could be > missing things this specification says MUST be there. Can we make > it more likely that an implementer won't create code that rejects > such messages as malformed? > > [MB] We added text indicating that this needs to be considered per the > application considerations section (i.e., applications need default > behavior in the case of missing information in per 4244 and now this > document). [/MB] > > > > Nits: > > At the definition of hi-index, the document talks of "nesting of > requests". It's the only place the word nesting occurs in the > document. Could you provide a description/definition or a pointer > to one? > > [MB] We just clarified that this reflects the retargeting. The > "nesting" concept is leftover from 4244 - it was referring to the > number of dots. [/MB] > > > The description of using an internal cache to describe how an > element will construct the history-info values it emits is likely > to draw discussion during IETF/IESG review. It uses 2119 language > to describe a possible implementation. Please consider changing > the phrasing to make it clear that the normative constraints are > on what's emitted, not on they way you store the information > internally. > > [MB] It really makes the text much less clear when we lose the concept > of a cache. That was John Elwell's suggestion and it really describes > how the information in the incoming request needs to be somehow > maintained to build the outgoing requests. We have added text noting > that the cache is just a copy. This is actually quite consistent > (including use of normative language) with RFC 3261 when it describes > the copying of information for the process of forwarding a request. [/MB] > > > First paragraph of 10.4 still says "two header field parameters" > and "Both", but talks about three. > > [MB] Fixed. [/MB] > > > "As for the behavior of the entity followings have changed" does > not parse. > > [MB] Fixed. [/MB] > > > In the first example in appendix A, the Contact in F3 has no > parameters, but the corresponding H-I value in F4 has an mp=1. The > version of this example in the callflow doc has the mp=1 in the > Contact in the 302. > > [MB] No longer there since we removed the call flows. [/MB] > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --------------080204030601070803000006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Mary -

I agree these address my points. I'm requesting IETF LC on this version.

SIPCORE - please review these changes carefully.

RjS

On 9/5/12 6:03 PM, Mary Barnes wrote:
Robert and WG,

We have submitted an updated version that we believe addresses the concerns raised, per the responses below.  Here's the diff:

Please let us know if you are okay with these changes.

Regards,
Mary et al

On Fri, Aug 24, 2012 at 1:45 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
Summary: There are a couple of questions to discuss before progressing to IETF LC.

This document is much easier to follow than RFC4244. It is still complex, but the rewrite effort improved its readability significantly.

There are a couple of things I would like the WG to consider before moving into IETF LC.

1) Since the WG adopted the call-flows document, does this document still need Appendix A, or should any of the examples there that are not already in the call-flows document be moved to that document?
[MB] No.  We have removed the call flows from this document and have added a reference to the call flows document. [/MB] 

2) The document requires that redirect servers include an hi-target-param in the Contact header fields it provides, and requires elements recursing on redirect responses to only include hi-target-params that it finds in those Contacts. They are specifically forbidden from providing the param if there are no params in the Contact. Please consider saying why this is required. If I recall the conversation correctly, it's because the redirect server is the only element that can tell whether mp or rc would be appropriate. For np, however, it's not clear why this requirement exists.  Is it just to keep things simple?
[MB]  We have updated the text to reflect that only mp and rc are relevant in this scenario.  [/MB] 

3) Section 103 step 6 says "If the request clearly has a gap", but I don't see any description of what an element is supposed to look for to determine there is a gap. From a discussion with Mary, it should be as simple as comparing the last HI entry to the Request-URI. If that's right, please add that to this description, and make it clear that you would only add one .0. when identifying a gap, not try to figure out how many elements may have not added history (that is, you would never produce something that looked like 1.0.0.1).
[MB] We have added text to indicate that it is simply that the URI in the hi-entry doesn't match the request URI.  Hopefully, the text around the .0 is more clear. [/MB] 

4) The Changes from RFC4244 section doesn't call out the new .0. gap detection/representation mechanic.
[MB] That's been added. [/MB} 

5) The backwards compatibility consideration focuses on exploring how RFC4244 elements will deal with messages created following this specification. There should be some additional exploration of how elements implementing this specification will deal with messages created by RFC4244 elements. Those messages could be missing things this specification says MUST be there. Can we make it more likely that an implementer won't create code that rejects such messages as malformed?
[MB] We added text indicating that this needs to be considered per the application considerations section (i.e., applications need default behavior in the case of missing information in per 4244 and now this document).  [/MB]


Nits:

At the definition of hi-index, the document talks of "nesting of requests". It's the only place the word nesting occurs in the document. Could you provide a description/definition or a pointer to one?
[MB] We just clarified that this reflects the retargeting.  The "nesting" concept is leftover from 4244 - it was referring to the number of dots.  [/MB] 

The description of using an internal cache to describe how an element will construct the history-info values it emits is likely to draw discussion during IETF/IESG review. It uses 2119 language to describe a possible implementation. Please consider changing the phrasing to make it clear that the normative constraints are on what's emitted, not on they way you store the information internally.
[MB] It really makes the text much less clear when we lose the concept of a cache.  That was John Elwell's suggestion and it really describes how the information in the incoming request needs to be somehow maintained to build the outgoing requests.  We have added text noting that the cache is just a copy. This is actually quite consistent (including use of normative language) with RFC 3261 when it describes the copying of information for the process of forwarding a request.  [/MB]

First paragraph of 10.4 still says "two header field parameters" and "Both", but talks about three.
[MB] Fixed. [/MB] 

"As for the behavior of the entity followings have changed" does not parse.
[MB] Fixed. [/MB] 

In the first example in appendix A, the Contact in F3 has no parameters, but the corresponding H-I value in F4 has an mp=1. The version of this example in the callflow doc has the mp=1 in the Contact in the 302.
[MB] No longer there since we removed the call flows. [/MB] 

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--------------080204030601070803000006-- From iesg-secretary@ietf.org Thu Sep 6 13:10:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7421F877F; Thu, 6 Sep 2012 13:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ediw-Rj0wt; Thu, 6 Sep 2012 13:10:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388BD21F8718; Thu, 6 Sep 2012 13:10:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906201032.11133.84911.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 13:10:32 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (An Extension to the Session Initiation Protocol (SIP) for Request History Information) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:10:32 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'An Extension to the Session Initiation Protocol (SIP) for Request History Information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Fri Sep 7 05:41:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F8D21F8690; Fri, 7 Sep 2012 05:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncycfYWD9ew9; Fri, 7 Sep 2012 05:41:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD6C21F85AC; Fri, 7 Sep 2012 05:41:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 05:41:00 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:41:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : The WebSocket Protocol as a Transport for the Session In= itiation Protocol (SIP) Author(s) : Inaki Baz Castillo Jose Luis Millan Villegas Victor Pascual Filename : draft-ietf-sipcore-sip-websocket-03.txt Pages : 20 Date : 2012-09-07 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in new scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmillan@aliax.net Fri Sep 7 06:27:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58B821F84FC for ; Fri, 7 Sep 2012 06:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sg1EJnJbqqzi for ; Fri, 7 Sep 2012 06:27:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8821F8469 for ; Fri, 7 Sep 2012 06:27:21 -0700 (PDT) Received: by lahm15 with SMTP id m15so2036496lah.31 for ; Fri, 07 Sep 2012 06:27:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=TECyNCzUUKBOogLxhAJReDdyY/G9B3jWilnEUML1xis=; b=LztvaJHP0u3eH7Ov0Ufg/zZpOMDjl5S3YxjcxNpZsvOQc9taoOfcS7aWkkNQalQzhB KZTy5115mFDAK0HIu7FVLY2WRareXuBl/chqyabpjljituRGZi9zBtxXc+owBr8vT3XR Z0N7gGOIc5xfDlJ/qg3YjgOsCaV33nN8erQqdrVtx+JvTTKJcil4lyqoU1mVSgh3zNnI PevA3WvNiY5tQchSPOXKL8ql+GCRSQtq+Xcj0XBNSD5N2wHtLAKaCNNtTVJNHirT1nU1 87ZyN1mEtwZplroYG4VqlO93YXBrE9v+nAeoo2vom9f2rcDEh258nhBQmpqnQyTKIifb 4WCg== MIME-Version: 1.0 Received: by 10.152.104.146 with SMTP id ge18mr5459987lab.7.1347024440712; Fri, 07 Sep 2012 06:27:20 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Fri, 7 Sep 2012 06:27:20 -0700 (PDT) In-Reply-To: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> Date: Fri, 7 Sep 2012 15:27:20 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnPspZmIcrbfIPVX6yDNoaDxLz95b0je2kV0MMKdyWzHrx8hXNGuojscUvHafqFoEjacqOp Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:27:22 -0000 Hi, This is the summary of the change log: * Removed Appendix B "HTTP Topology Hiding" * Added "Via received parameter" section as an update to RFC3261 * Added "SIP transport implementation requirements" section as and update to RFC3261 This modifications address the comments and feedback received on draft-ibc-sipcore-sip-websocket-02 Regards. 2012/9/7 : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > Title : The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) > Author(s) : Inaki Baz Castillo > Jose Luis Millan Villegas > Victor Pascual > Filename : draft-ietf-sipcore-sip-websocket-03.txt > Pages : 20 > Date : 2012-09-07 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities to enable usage of SIP in new > scenarios. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-websocket-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From richard@shockey.us Fri Sep 7 13:51:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D7921E80DE for ; Fri, 7 Sep 2012 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.544 X-Spam-Level: X-Spam-Status: No, score=-98.544 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljPenE0fBFwD for ; Fri, 7 Sep 2012 13:51:29 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id DF35C21E80DF for ; Fri, 7 Sep 2012 13:51:28 -0700 (PDT) Received: (qmail 24599 invoked by uid 0); 7 Sep 2012 20:51:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 7 Sep 2012 20:51:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=m4jC7aRFLu3tCMG6QA42OHu+uezRCTBCu55qKmyGA0Y=; b=VdPPosJfkU6VhSh83ftByuW7VsUwwLkNmsysnS5WQV3FQcW0RLQnETSWGIcpUZvO/8BFhMxzuPv2OttqfHi2T11Ry9z3tzv5XqpNNy1QpFzAFpIVi3q3fY08EWT+LOHp; Received: from [71.191.243.130] (port=55185 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TA5WR-0007X7-Tg; Fri, 07 Sep 2012 14:51:28 -0600 From: "Richard Shockey" To: "'DISPATCH'" , , Date: Fri, 7 Sep 2012 16:51:26 -0400 Message-ID: <021401cd8d3a$8cf46960$a6dd3c20$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01CD8D19.05E2C960" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2NOowOW92M10WOQ3+sn3sHdFeGrQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: [sipcore] For your weekend reading... X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:51:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0215_01CD8D19.05E2C960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our dear and beloved colleagues at ATT strolled up to the 8th floor of the US Federal Communications Commission and respectfully suggested they "retire" Time Division Multiplexing networks and services in favor of a all IP ( read SIP ) based Network/Ecosystem. http://apps.fcc.gov/ecfs/document/view?id=7022008762 < insert applause> Gives a whole new meaning to the Death Star logo. don't you think? Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0215_01CD8D19.05E2C960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our dear = and beloved colleagues at  ATT strolled up to the 8th = floor of the US Federal Communications Commission and respectfully = suggested they “retire”  Time Division Multiplexing = networks and services in favor of a all IP  ( read SIP ) =  based Network/Ecosystem.

 

http://ap= ps.fcc.gov/ecfs/document/view?id=3D7022008762

 

< insert applause> =

 

Gives a whole new meaning to the Death Star = logo… don’t you think? 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0215_01CD8D19.05E2C960-- From internet-drafts@ietf.org Tue Sep 11 12:50:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9425F21F86FD; Tue, 11 Sep 2012 12:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibcBL0YsOB+M; Tue, 11 Sep 2012 12:50:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECAA21F868A; Tue, 11 Sep 2012 12:50:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911195049.4345.82891.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2012 12:50:49 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:50:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-00.txt Pages : 30 Date : 2012-08-01 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From victor.pascual.avila@gmail.com Wed Sep 12 13:36:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF421F85C3 for ; Wed, 12 Sep 2012 13:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FhlU9a6tOnz for ; Wed, 12 Sep 2012 13:36:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1DC21F861E for ; Wed, 12 Sep 2012 13:36:30 -0700 (PDT) Received: by iabz21 with SMTP id z21so1799385iab.31 for ; Wed, 12 Sep 2012 13:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=bFIM1rFzDUnRLAsylgsiFW8oeS4eSOTq6tF/iCitV4Q=; b=Aqht5+j+1jwcEAGnGBYiSMZ1NwerPFHmbm8cUcxpaZW04blmj51E18WxgUDKv/o/4O UYfUTk/BwHG0JYjEAResGUXIgW08nXKQPwuv6TO4c0Dv8UvD+2U2Hl6qMtAakNkLEo1V 4I8W+gM0isdTt83VJ6kWTMOz/Kby6rMyTFzxEzFqyBKMlKsfh6bqeYlz1McKtpoyMkt8 REBmuzNZZ0qaTg6bgJSkFo1E9RnC0EVs17NchSt1Wb/ZF9kNxBLVwaZoQIcY6BBqK3Fm +VWgPqLof3YtU2Mw8N3fc/7kGe9rF/pv8OP7nCAkh9O/IId6HB6dlmyuz/EH44yWs/7G T5lg== MIME-Version: 1.0 Received: by 10.50.76.137 with SMTP id k9mr21979311igw.58.1347482187567; Wed, 12 Sep 2012 13:36:27 -0700 (PDT) Received: by 10.64.46.105 with HTTP; Wed, 12 Sep 2012 13:36:27 -0700 (PDT) In-Reply-To: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 22:36:27 +0200 Message-ID: From: Victor Pascual Avila To: SIPCORE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 20:36:31 -0000 Could you please take a new look at the document (-03), and indicate whether you are ok with the changes? Thanks! -Victor On Fri, Sep 7, 2012 at 3:27 PM, Jos=C3=A9 Luis Mill=C3=A1n wrote: > Hi, > > This is the summary of the change log: > > * Removed Appendix B "HTTP Topology Hiding" > > * Added "Via received parameter" section as an update to RFC3261 > > * Added "SIP transport implementation requirements" section as and > update to RFC3261 > > > This modifications address the comments and feedback received on > draft-ibc-sipcore-sip-websocket-02 > > Regards. > > 2012/9/7 : >> >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Session Initiation Protocol Core Worki= ng Group of the IETF. >> >> Title : The WebSocket Protocol as a Transport for the = Session Initiation Protocol (SIP) >> Author(s) : Inaki Baz Castillo >> Jose Luis Millan Villegas >> Victor Pascual >> Filename : draft-ietf-sipcore-sip-websocket-03.txt >> Pages : 20 >> Date : 2012-09-07 >> >> Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers. This document specifies a new WebSocket sub- >> protocol as a reliable transport mechanism between SIP (Session >> Initiation Protocol) entities to enable usage of SIP in new >> scenarios. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From lishitao@huawei.com Wed Sep 12 23:31:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00321E8049 for ; Wed, 12 Sep 2012 23:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci35QN3RuBKA for ; Wed, 12 Sep 2012 23:31:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 15AED21E8056 for ; Wed, 12 Sep 2012 23:31:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJP84661; Thu, 13 Sep 2012 06:31:15 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 07:30:47 +0100 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Sep 2012 07:31:00 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 14:29:52 +0800 From: Lishitao To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= , "SIPCORE (Session Initiation Protocol Core) WG" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt Thread-Index: AQHNjPYQ7gNsvsmFIEWk/JnUAeqm2Jd+WPsAgAl9KBA= Date: Thu, 13 Sep 2012 06:29:52 +0000 Message-ID: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 06:31:19 -0000 Hi I get one question about how to use this sip-websocket protocol.=20 If my browser has already establish a websocket connection, and has a phone= call using it, and I want to initiate another call, can I use the same web= socket connection,=20 or I need to establish a new websocket connection, or using websocket multi= plexing? Regards shitao > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Jos=E9 Luis Mill=E1n > Sent: Friday, September 07, 2012 9:27 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.tx= t >=20 > Hi, >=20 > This is the summary of the change log: >=20 > * Removed Appendix B "HTTP Topology Hiding" >=20 > * Added "Via received parameter" section as an update to RFC3261 >=20 > * Added "SIP transport implementation requirements" section as and > update to RFC3261 >=20 >=20 > This modifications address the comments and feedback received on > draft-ibc-sipcore-sip-websocket-02 >=20 > Regards. >=20 > 2012/9/7 : > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Session Initiation Protocol Core Work= ing > Group of the IETF. > > > > Title : The WebSocket Protocol as a Transport for the > Session Initiation Protocol (SIP) > > Author(s) : Inaki Baz Castillo > > Jose Luis Millan Villegas > > Victor Pascual > > Filename : draft-ietf-sipcore-sip-websocket-03.txt > > Pages : 20 > > Date : 2012-09-07 > > > > Abstract: > > The WebSocket protocol enables two-way realtime communication > between > > clients and servers. This document specifies a new WebSocket sub- > > protocol as a reliable transport mechanism between SIP (Session > > Initiation Protocol) entities to enable usage of SIP in new > > scenarios. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jmillan@aliax.net Thu Sep 13 03:10:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956D21F8568 for ; Thu, 13 Sep 2012 03:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVadYWT-GKr2 for ; Thu, 13 Sep 2012 03:10:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E121F8570 for ; Thu, 13 Sep 2012 03:10:39 -0700 (PDT) Received: by lahm15 with SMTP id m15so1905693lah.31 for ; Thu, 13 Sep 2012 03:10:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Uhc7xl0BGDlUFAlEo8NVH6WeMhk9ysdrnl1t5HQFdxI=; b=ohANvs9dCPD5/paUTZ3rb1ap40CqoCVOXBXW4IzO+EDdffHxwr64wjiH7+OTqrDlCS aEcyo6MJxo94+nzFAQ5LZWbLprymrGbMtdYdH9u3f639KTugibd+Xf60gotI79KYT2Ci wu7ry/u0q5Tm6dvTR/04aBHaoFnbaaqCGJs3qlwhVlXyTK0ern3myWmWMJnF2SYoTbe8 LnbyQxlXSk4hiz4gpRtyWCWtDdo/hGuvJfRxjjUKKLyBK5wPxgNCSFYNTY81+xlewi8P mKzRq0EksAQc2tgEJ23mFGnl2QDxh0FENz2wD7kg9SEG5o/f+FIUBOAopXldqiGBURhl vbBg== MIME-Version: 1.0 Received: by 10.152.144.2 with SMTP id si2mr1458625lab.26.1347531035825; Thu, 13 Sep 2012 03:10:35 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Thu, 13 Sep 2012 03:10:35 -0700 (PDT) In-Reply-To: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 12:10:35 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Lishitao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7PEc0EfJfxkR+tqAJtw8Fkzxfy8/pk7NgO+8qCBV+GuJgToR9EMEid0ZBtWhP06/Tx7FP Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 10:10:42 -0000 Hi, 2012/9/13 Lishitao : > Hi > I get one question about how to use this sip-websocket protocol. > > If my browser has already establish a websocket connection, and has a pho= ne call using it, and I want to initiate another call, can I use the same w= ebsocket connection, > or I need to establish a new websocket connection, or using websocket mul= tiplexing? The same rules for other connection oriented transports in SIP applies to this one. You can use a persistent connection to send and receive multiple even unrelated requests over the same connection. Regards. > > Regards > shitao > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> Of Jos=E9 Luis Mill=E1n >> Sent: Friday, September 07, 2012 9:27 PM >> To: SIPCORE (Session Initiation Protocol Core) WG >> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.t= xt >> >> Hi, >> >> This is the summary of the change log: >> >> * Removed Appendix B "HTTP Topology Hiding" >> >> * Added "Via received parameter" section as an update to RFC3261 >> >> * Added "SIP transport implementation requirements" section as and >> update to RFC3261 >> >> >> This modifications address the comments and feedback received on >> draft-ibc-sipcore-sip-websocket-02 >> >> Regards. >> >> 2012/9/7 : >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> > This draft is a work item of the Session Initiation Protocol Core Wor= king >> Group of the IETF. >> > >> > Title : The WebSocket Protocol as a Transport for th= e >> Session Initiation Protocol (SIP) >> > Author(s) : Inaki Baz Castillo >> > Jose Luis Millan Villegas >> > Victor Pascual >> > Filename : draft-ietf-sipcore-sip-websocket-03.txt >> > Pages : 20 >> > Date : 2012-09-07 >> > >> > Abstract: >> > The WebSocket protocol enables two-way realtime communication >> between >> > clients and servers. This document specifies a new WebSocket sub- >> > protocol as a reliable transport mechanism between SIP (Session >> > Initiation Protocol) entities to enable usage of SIP in new >> > scenarios. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-03 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Thu Sep 20 15:00:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2B411E80B8; Thu, 20 Sep 2012 15:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVOMmqyKy+E8; Thu, 20 Sep 2012 15:00:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6EC11E808A; Thu, 20 Sep 2012 15:00:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920220005.4248.47136.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 15:00:05 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 22:00:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-01.txt Pages : 45 Date : 2012-09-11 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 21 04:55:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5D221F8452; Fri, 21 Sep 2012 04:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsiFTnjzd8XG; Fri, 21 Sep 2012 04:55:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6879321F8797; Fri, 21 Sep 2012 04:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921115556.14655.62433.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 04:55:56 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:55:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-10.txt Pages : 21 Date : 2012-09-21 Abstract: This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the header field to indicate support of features and capabilities. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lishitao@huawei.com Fri Sep 21 18:59:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F7221E805E for ; Fri, 21 Sep 2012 18:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVPdkVRvfNyS for ; Fri, 21 Sep 2012 18:59:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF421E80EC for ; Fri, 21 Sep 2012 18:59:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX85184; Sat, 22 Sep 2012 01:59:49 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 02:59:10 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 09:59:48 +0800 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Sat, 22 Sep 2012 09:59:46 +0800 From: Lishitao To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt Thread-Index: AQHNjPYQ7gNsvsmFIEWk/JnUAeqm2Jd+WPsAgAl9KBD//7ncgIAOHwBQ Date: Sat, 22 Sep 2012 01:59:45 +0000 Message-ID: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 01:59:53 -0000 Hi Thanks for your relay.=20 In section 8.1, the example for registration, it mentioned that it support = outbound and GRUU, my another question is how does the SIP agent get the in= stance-ID? Does it come from Javascript or by the browser? That every time when JS dow= nloaded into the browser, it will assign a new instance-ID for the user, or= wherever the user register from, the JS(or the browser) always assign the = same instance-ID for the same user. Regards shitao=20 > -----Original Message----- > From: Jos=E9 Luis Mill=E1n [mailto:jmillan@aliax.net] > Sent: Thursday, September 13, 2012 6:11 PM > To: Lishitao > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.tx= t >=20 > Hi, >=20 > 2012/9/13 Lishitao : > > Hi > > I get one question about how to use this sip-websocket protocol. > > > > If my browser has already establish a websocket connection, and has a p= hone > call using it, and I want to initiate another call, can I use the same we= bsocket > connection, > > or I need to establish a new websocket connection, or using websocket > multiplexing? >=20 > The same rules for other connection oriented transports in SIP applies > to this one. You can use a persistent connection to send and receive > multiple even unrelated requests over the same connection. >=20 > Regards. > > > > Regards > > shitao > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > >> Of Jos=E9 Luis Mill=E1n > >> Sent: Friday, September 07, 2012 9:27 PM > >> To: SIPCORE (Session Initiation Protocol Core) WG > >> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03= .txt > >> > >> Hi, > >> > >> This is the summary of the change log: > >> > >> * Removed Appendix B "HTTP Topology Hiding" > >> > >> * Added "Via received parameter" section as an update to RFC3261 > >> > >> * Added "SIP transport implementation requirements" section as and > >> update to RFC3261 > >> > >> > >> This modifications address the comments and feedback received on > >> draft-ibc-sipcore-sip-websocket-02 > >> > >> Regards. > >> > >> 2012/9/7 : > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> > This draft is a work item of the Session Initiation Protocol Core W= orking > >> Group of the IETF. > >> > > >> > Title : The WebSocket Protocol as a Transport for > the > >> Session Initiation Protocol (SIP) > >> > Author(s) : Inaki Baz Castillo > >> > Jose Luis Millan Villegas > >> > Victor Pascual > >> > Filename : draft-ietf-sipcore-sip-websocket-03.txt > >> > Pages : 20 > >> > Date : 2012-09-07 > >> > > >> > Abstract: > >> > The WebSocket protocol enables two-way realtime communication > >> between > >> > clients and servers. This document specifies a new WebSocket sub= - > >> > protocol as a reliable transport mechanism between SIP (Session > >> > Initiation Protocol) entities to enable usage of SIP in new > >> > scenarios. > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-03 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-= 03 > >> > > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > _______________________________________________ > >> > sipcore mailing list > >> > sipcore@ietf.org > >> > https://www.ietf.org/mailman/listinfo/sipcore > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Sat Sep 22 08:09:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B32921F86CB for ; Sat, 22 Sep 2012 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db5ywPy2Q30U for ; Sat, 22 Sep 2012 08:09:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDFB21F86C9 for ; Sat, 22 Sep 2012 08:09:29 -0700 (PDT) Received: by lboj14 with SMTP id j14so4976201lbo.31 for ; Sat, 22 Sep 2012 08:09:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=F3bYQN/lQrjUoJds+82iNVZ/iOk1gf+zbXxJ8EtJ74U=; b=Lge6DD4CU20alfGNIWa9njEcSkoUD784LACkknd2Spb72yvUgfjmmRSLn3luDeHZlD EGx9gufCCgNGcldhqegW7suM3aBLBpJeviWC+eSNwD9Rwtf3aCdlVQQDTfvm+PFDqJjE Imgp9IZRIXkQscqrLIjdD/XjS9fV2X4psfhTHOt1DZyYCuuGRcuclGOZZsAvn7GcPzo3 bV6ljcoAjlo+BQ+6xuJYchToEmflGK9uKd5vIA2QN1Hj3Iw82dhOlCZW9XJYm/VmPJxb WN1yr2vPQKuMk/0wYWsyTXQYYRAyZS7q7BA2xcdEfXDqCTYVine+zqh0ztqriAW1kM5n rMqw== Received: by 10.112.48.200 with SMTP id o8mr1831073lbn.27.1348326568698; Sat, 22 Sep 2012 08:09:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Sat, 22 Sep 2012 08:09:08 -0700 (PDT) In-Reply-To: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 22 Sep 2012 17:09:08 +0200 Message-ID: To: Lishitao Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkGEm7zWzTzbJekrROs5Q5b7VleyREG2xHHSgMhBAMwuTyTZ/hDz6x/3TyvpXwmF5SSE4KA Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 15:09:31 -0000 2012/9/22 Lishitao : > Hi > Thanks for your relay. > > In section 8.1, the example for registration, it mentioned that it suppor= t outbound and GRUU, my another question is how does the SIP agent get the = instance-ID? > > Does it come from Javascript or by the browser? That every time when JS d= ownloaded into the browser, it will assign a new instance-ID for the user, = or wherever the user register from, the JS(or the browser) always assign th= e same instance-ID for the same user. Since the instance-id must be unique per device, and here the device is the web browser (or the mobile app or whatever) IMHO the instance -id must be generated by the JS application the first time it is executed, so it generates a random instance-id and stores it via Cookie or via local storage of HTML5 (in the hard disk). IMHO that would be a good approach. Regards. --=20 I=C3=B1aki Baz Castillo From lishitao@huawei.com Wed Sep 26 23:24:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228821F8516 for ; Wed, 26 Sep 2012 23:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38wqICek2mFz for ; Wed, 26 Sep 2012 23:24:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72E21F846A for ; Wed, 26 Sep 2012 23:24:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKB37670; Thu, 27 Sep 2012 06:24:38 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 07:23:40 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 07:24:23 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Thu, 27 Sep 2012 14:23:50 +0800 From: Lishitao To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt Thread-Index: AQHNjPYQ7gNsvsmFIEWk/JnUAeqm2Jd+WPsAgAl9KBD//7ncgIAOHwBQgABZZQCAB8e5IA== Date: Thu, 27 Sep 2012 06:23:50 +0000 Message-ID: References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.45] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , =?utf-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 06:24:40 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgST9ha2kgQmF6IENhc3RpbGxvDQo+IFNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMjIsIDIw MTIgMTE6MDkgUE0NCj4gVG86IExpc2hpdGFvDQo+IENjOiBTSVBDT1JFIChTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgQ29yZSkgV0c7IEpvc8OpIEx1aXMgTWlsbMOhbg0KPiBTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtd2Vic29ja2V0 LTAzLnR4dA0KPiANCj4gMjAxMi85LzIyIExpc2hpdGFvIDxsaXNoaXRhb0BodWF3ZWkuY29tPjoN Cj4gPiBIaQ0KPiA+IFRoYW5rcyBmb3IgeW91ciByZWxheS4NCj4gPg0KPiA+IEluIHNlY3Rpb24g OC4xLCB0aGUgZXhhbXBsZSBmb3IgcmVnaXN0cmF0aW9uLCBpdCBtZW50aW9uZWQgdGhhdCBpdCBz dXBwb3J0DQo+IG91dGJvdW5kIGFuZCBHUlVVLCBteSBhbm90aGVyIHF1ZXN0aW9uIGlzIGhvdyBk b2VzIHRoZSBTSVAgYWdlbnQgZ2V0IHRoZQ0KPiBpbnN0YW5jZS1JRD8NCj4gPg0KPiA+IERvZXMg aXQgY29tZSBmcm9tIEphdmFzY3JpcHQgb3IgYnkgdGhlIGJyb3dzZXI/IFRoYXQgZXZlcnkgdGlt ZSB3aGVuIEpTDQo+IGRvd25sb2FkZWQgaW50byB0aGUgYnJvd3NlciwgaXQgd2lsbCBhc3NpZ24g YSBuZXcgaW5zdGFuY2UtSUQgZm9yIHRoZSB1c2VyLCBvcg0KPiB3aGVyZXZlciB0aGUgdXNlciBy ZWdpc3RlciBmcm9tLCB0aGUgSlMob3IgdGhlIGJyb3dzZXIpIGFsd2F5cyBhc3NpZ24gdGhlDQo+ IHNhbWUgaW5zdGFuY2UtSUQgZm9yIHRoZSBzYW1lIHVzZXIuDQo+IA0KPiBTaW5jZSB0aGUgaW5z dGFuY2UtaWQgbXVzdCBiZSB1bmlxdWUgcGVyIGRldmljZSwgYW5kIGhlcmUgdGhlIGRldmljZQ0K PiBpcyB0aGUgd2ViIGJyb3dzZXIgKG9yIHRoZSBtb2JpbGUgYXBwIG9yIHdoYXRldmVyKSBJTUhP IHRoZSBpbnN0YW5jZQ0KPiAtaWQgbXVzdCBiZSBnZW5lcmF0ZWQgYnkgdGhlIEpTIGFwcGxpY2F0 aW9uIHRoZSBmaXJzdCB0aW1lIGl0IGlzDQo+IGV4ZWN1dGVkLCBzbyBpdCBnZW5lcmF0ZXMgYSBy YW5kb20gaW5zdGFuY2UtaWQgYW5kIHN0b3JlcyBpdCB2aWENCj4gQ29va2llIG9yIHZpYSBsb2Nh bCBzdG9yYWdlIG9mIEhUTUw1IChpbiB0aGUgaGFyZCBkaXNrKS4gSU1ITyB0aGF0DQo+IHdvdWxk IGJlIGEgZ29vZCBhcHByb2FjaC4NCj4gDQo+IFJlZ2FyZHMuDQoNClNvICxpZiBJIG9wZW4gYW5v dGhlciBicm93c2VyIG9uIHRoZSBzYW1lIG1hY2hpbmUgYW5kIHRyeSB0byByZWdpc3RlciB1c2lu ZyB0aGUgc2FtZSBTSVAgVVJJLCBpdCB3aWxsIGdldCB0aGUgc2FtZSBpbnN0YW5jZS1JRCwgYW5k IGFsc28gaGFzIHRvIHN1cHBvcnQgbXVsdGlwbGUgcmVnaXN0cmF0aW9uLg0KSWYgSSBvcGVuIGEg YnJvd3NlciBvbiBhbm90aGVyIG1hY2hpbmUgYW5kIHRyeSB0byByZWdpc3RlciB1c2luZyB0aGUg c2FtZSBTSVAgVVJJLCBpdCB3aWxsIGdldCBhIGRpZmZlcmVudCBpbnN0YW5jZS1JRCwgYW5kIHJl Z2lzdGVyIGFzIGEgZGlmZmVyZW50IHVzZXIuDQpSaWdodD8NClJlZ2FyZHMNCnNoaXRhbyANCj4g DQo+IC0tDQo+IEnDsWFraSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFp bGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From internet-drafts@ietf.org Thu Sep 27 15:33:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0036821F85EA; Thu, 27 Sep 2012 15:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VvbxRCC0c05; Thu, 27 Sep 2012 15:33:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690AB21F85C6; Thu, 27 Sep 2012 15:33:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120927223345.22995.86019.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2012 15:33:45 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 22:33:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-10.txt Pages : 36 Date : 2012-09-27 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Thu Sep 27 15:36:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF221F8613 for ; Thu, 27 Sep 2012 15:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.324 X-Spam-Level: X-Spam-Status: No, score=-103.324 tagged_above=-999 required=5 tests=[AWL=0.274, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPS3T+R+0wyG for ; Thu, 27 Sep 2012 15:36:27 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1586F21F860E for ; Thu, 27 Sep 2012 15:36:26 -0700 (PDT) Received: by lamb11 with SMTP id b11so626897lam.31 for ; Thu, 27 Sep 2012 15:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZK2nPxDUTaiJ7TxfHt+q4JvtX1WFODN9O9Fl0yDLZ2c=; b=fNJeYt6efrjDzvFJ5NuHmqmVAF8E/vP8ELPdgHHJd/roqGan5WS9GvQ14Kn84upzsZ auIoY2B4ubdLPMZhR+vPPczj9HDTKl3rh+ZVrEzWSMqLEMOjCq3bFAVT32n5DFCwnv0S 42YribwCMYdo9/eHAHAY1KoJvQKODsdIGKyi3+UAtINf2vax+0kyD/kQUUkV1gqkP3Y3 PFusJM3RdrK4uXDa//ZVO8iRjBE2sf3LoSSlBXr7i54/pbyYcsvtyEZ1srDMvXvHy/XI lSYBjlJNfWgNc9HHTuOQcKOtwntdQUVYUHCCF0/MA9Wuv8TparyH2dbf2eSQ3umN+Ygs gMiw== MIME-Version: 1.0 Received: by 10.152.48.102 with SMTP id k6mr4393307lan.12.1348785385888; Thu, 27 Sep 2012 15:36:25 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Thu, 27 Sep 2012 15:36:25 -0700 (PDT) In-Reply-To: <20120927223345.22995.86019.idtracker@ietfa.amsl.com> References: <20120927223345.22995.86019.idtracker@ietfa.amsl.com> Date: Thu, 27 Sep 2012 17:36:25 -0500 Message-ID: From: Mary Barnes To: SIPCORE , Robert Sparks Content-Type: multipart/alternative; boundary=bcaec54fb148cdd9a204cab691ec Cc: "Romascanu, Dan \(Dan\)" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-10.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 22:36:28 -0000 --bcaec54fb148cdd9a204cab691ec Content-Type: text/plain; charset=ISO-8859-1 The document has been updated to reflect IETF Last call comments, including those from Dan Romascanu (gen-art review) and IANA. In addition, a few references to the call flows draft have been (re-) added, as well as updating the reference to the WG version of that document. Regards, Mary On Thu, Sep 27, 2012 at 5:33 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core Working > Group of the IETF. > > Title : An Extension to the Session Initiation Protocol > (SIP) for Request History Information > Author(s) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-10.txt > Pages : 36 > Date : 2012-09-27 > > Abstract: > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by providing > the information as to how and why a SIP request arrives at a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. In addition, this > specification defines a value for the Privacy header field that > directs the anonymization of values in the History-Info header field. > This document obsoletes RFC 4244. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --bcaec54fb148cdd9a204cab691ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The document has been updated to reflect IETF Last call comments, including= those from Dan Romascanu (gen-art review) and IANA. =A0In addition, a few = references to the call flows draft have been (re-) added, as well as updati= ng the reference to the WG version of that document.=A0

Regards,
Mary

On= Thu, Sep 27, 2012 at 5:33 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Session Initiation Protocol Core Workin= g Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Ini= tiation Protocol (SIP) for Request History Information
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Francois Audet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shida Schubert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Detecon International G= mbh
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer Holmberg
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-10.= txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 36
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-09-27

Abstract:
=A0 =A0This document defines a standard mechanism for capturing the history=
=A0 =A0information associated with a Session Initiation Protocol (SIP)
=A0 =A0request. =A0This capability enables many enhanced services by provid= ing
=A0 =A0the information as to how and why a SIP request arrives at a specifi= c
=A0 =A0application or user. =A0This document defines an optional SIP header=
=A0 =A0field, History-Info, for capturing the history information in
=A0 =A0requests. =A0The document also defines SIP header field parameters f= or
=A0 =A0the History-Info and Contact header fields to tag the method by whic= h
=A0 =A0the target of a request is determined. =A0In addition, this
=A0 =A0specification defines a value for the Privacy header field that
=A0 =A0directs the anonymization of values in the History-Info header field= .
=A0 =A0This document obsoletes RFC 4244.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc42= 44bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-10<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcor= e-rfc4244bis-10


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

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--bcaec54fb148cdd9a204cab691ec-- From internet-drafts@ietf.org Fri Sep 28 04:05:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22421F85B1; Fri, 28 Sep 2012 04:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-v5Cbd4Ai4d; Fri, 28 Sep 2012 04:05:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6829521F84E7; Fri, 28 Sep 2012 04:05:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120928110552.2494.7851.idtracker@ietfa.amsl.com> Date: Fri, 28 Sep 2012 04:05:52 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-11.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:05:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-11.txt Pages : 22 Date : 2012-09-28 Abstract: This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Fri Sep 28 04:12:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0601621F85C4 for ; Fri, 28 Sep 2012 04:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5vK43o0uNfH for ; Fri, 28 Sep 2012 04:12:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD721F8578 for ; Fri, 28 Sep 2012 04:12:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-de-5065860fb794 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.21.11467.F0685605; Fri, 28 Sep 2012 13:12:15 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 28 Sep 2012 13:12:14 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 28 Sep 2012 13:12:14 +0200 Thread-Topic: Proxy-feature: IANA feedback regarding missing procedures for registering new feature capability indicator trees Thread-Index: Ac2dahzhoaUY+bfLRkSq/2HYrmnwJA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A6FA679@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A0585340A6FA679ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrS5/W2qAQf8na4trcxrZLE69Os1s 8fXHJjYHZo8lS34yecza+YTF48vlz2wBzFFcNimpOZllqUX6dglcGW9OzWUt+ClTsfdcP2MD 427JLkYODgkBE4nvB8S6GDmBTDGJC/fWs3UxcnEICZxilNj+9gkrhLOAUWJzz0M2kAY2AQuJ 7n/aIA0iApoSy79tZQepYRaYzijRPP8EO0iCRUBVYuuF5cwgtrBAtURnzyqwqSICDYwSB/t+ sEN060nse9nBCmLzCoRLTPq9DqyBEeiM76fWMIHYzALiEreezGeCOE9AYsme88wQtqjEy8f/ WCHqRSXutK9nhKjPl5h0o48RYqagxMmZT1gmMArPQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18 zQxjnznwmAlZfAEj+ypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMCIOrjlt+4OxlPnRA4xSnOw KInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaGn1oXhP/Oke1bc3bjvaZ30zsJM2 3uCy4qj1DbOX7+1Pvn182Llxf8veQzHL/gY8yXzwI/v16+NpLXe2Os6ZdSxAOvfMTbMyNVlu Jl615333TBpLN2WfUPvRJzEx/r5k3daoh51LVgfZyGfNPBi0aP9OG0Ou04ozwmz3yHTMWsz1 s9BqgpmDthJLcUaioRZzUXEiAANpUgt2AgAA Cc: "SIPCORE Chairs \(sipcore-chairs@tools.ietf.org\)" Subject: [sipcore] Proxy-feature: IANA feedback regarding missing procedures for registering new feature capability indicator trees X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:12:19 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6FA679ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We got feedback from IANA, that the proxy-feature draft does not contain te= xt about how to create new feature capability indicator trees. The draft on= ly contains text about how to register feature capability indicators to exi= sting trees. We've submitted a new version (-11), where we've defined procedures for reg= istering new trees in section 7.3.1, saying that the "Standards Action" pol= icies in RFC 5226 are used. (The need for new trees is not foreseen at this moment, but we saw no reaso= n to forbid it, should a need occur in the feature). Thanks! Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6FA679ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We got fee= dback from IANA, that the proxy-feature draft does not contain text about h= ow to create new feature capability indicator trees. The draft only contain= s text about how to register feature capability indicators to existing tree= s.

 

We’ve submitted a new version (-11), where we’ve defined p= rocedures for registering new trees in section 7.3.1, saying that the ̶= 0;Standards Action” policies in RFC 5226 are used.

 

(The need for ne= w trees is not foreseen at this moment, but we saw no reason to forbid it, = should a need occur in the feature).

 

Thanks!

 

Regards,

 

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A6FA679ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Fri Sep 28 07:03:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4556C21F8452 for ; Fri, 28 Sep 2012 07:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yabRopMzCUU for ; Fri, 28 Sep 2012 07:03:25 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 847AC21F8491 for ; Fri, 28 Sep 2012 07:03:22 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id 4boU1k0020xGWP854e3SwR; Fri, 28 Sep 2012 14:03:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 4dxY1k00x3ZTu2S3YdxZHB; Fri, 28 Sep 2012 13:57:33 +0000 Message-ID: <5065ACFD.6060704@alum.mit.edu> Date: Fri, 28 Sep 2012 09:58:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A6FA679@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A6FA679@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Proxy-feature: IANA feedback regarding missing procedures for registering new feature capability indicator trees X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 14:03:26 -0000 SIPCORE people: If anyone has issues with this revision please speak up immediately. I'm not anticipating any concerns. Thanks, Paul (as co-chair) On 9/28/12 7:12 AM, Christer Holmberg wrote: > Hi, > > We got feedback from IANA, that the proxy-feature draft does not contain > text about how to create new feature capability indicator trees. The > draft only contains text about how to register feature capability > indicators to existing trees. > > We’ve submitted a new version (-11), where we’ve defined procedures for > registering new trees in section 7.3.1, saying that the “Standards > Action” policies in RFC 5226 are used. > > (The need for new trees is not foreseen at this moment, but we saw no > reason to forbid it, should a need occur in the feature). > > Thanks! > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From richard@shockey.us Fri Sep 28 09:51:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985F221F8592 for ; Fri, 28 Sep 2012 09:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.738 X-Spam-Level: X-Spam-Status: No, score=-98.738 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NRrdFboHass for ; Fri, 28 Sep 2012 09:51:04 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 62B6121F8549 for ; Fri, 28 Sep 2012 09:51:01 -0700 (PDT) Received: (qmail 23073 invoked by uid 0); 28 Sep 2012 16:50:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 28 Sep 2012 16:50:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=v7+2IroOHAE13quhn2VjZBv2KsSUCnSVPmDEMJ63TiM=; b=PHdSYAMHKJ+pISF6535k/NOUYIFoqOphjKHLwMFyIKYhNaGiAw6CWRNsGs5205rxs/dEhESCxM5/qNsbs8tV0Wy68LLw98tBA8ImsKuXFfsuaR24VwA2VFaxqGOXKCbJ; Received: from [71.191.243.130] (port=61644 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THdmC-00015T-ED; Fri, 28 Sep 2012 10:50:56 -0600 From: "Richard Shockey" To: , "'DISPATCH'" , Date: Fri, 28 Sep 2012 12:50:53 -0400 Message-ID: <013101cd9d99$6d154500$473fcf00$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01CD9D77.E603A500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2dmWwesgsKc++hQ8CQ/9f8HS7k5g== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.191.243.130 authed with richard@shockey.us} Subject: [sipcore] FYI .. The SIP Forum is considering developing a Profile for the Video Relay Service. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 16:51:09 -0000 X-List-Received-Date: Fri, 28 Sep 2012 16:51:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0132_01CD9D77.E603A500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit At the request of several organizations the SIP Forum is considering developing a task group to undertake a comprehensive SIP interoperability Profile of the Video Relay Service for hearing impaired citizens. This would be similar in scope to work the Forum has undertaken in the past to define a interoperability SIP Profile for SIP PBX to service provider that resulted in the Forum's SIP Connect specification and RFC 6140. We have seen substantial documentation that the state of VRS interoperability is simply appalling. We will certainly want the input and recommendations of the IETF RAI community as we undertake this project. The implications for SIP based Unified Communications should be obvious. As usual we will NOT define new SIP protocols but should issues arise the proposed task group will be chartered to document and report new requirements to DISPATCH as needed. We are open to suggestions that we publish our charter and other documents as Informational RFC's. A mailing list has been established. You all are welcome to join. vrs@sipforum.org http://en.wikipedia.org/wiki/Video_relay_service http://tap.gallaudet.edu/Conferences/NAD2012/ http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-184A1.pdf Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0132_01CD9D77.E603A500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

At the = request of several organizations the SIP Forum is considering developing = a task group to undertake a comprehensive SIP interoperability Profile = of the Video Relay Service for hearing impaired citizens.  This = would be similar in scope to work the Forum has undertaken in the past = to define a interoperability SIP Profile for SIP PBX to service provider = that resulted in the Forum’s SIP Connect specification and RFC = 6140.

 

We have seen substantial documentation that the state = of VRS interoperability is simply appalling.

 

We will = certainly want the input and recommendations of the IETF RAI community = as we undertake this project.

 

The = implications for SIP based Unified Communications should be obvious. =

 

As usual we will NOT define new SIP protocols but = should issues arise the proposed task group will be chartered to = document and report new requirements to DISPATCH as = needed.

 

We are open to suggestions that we publish our charter = and other documents as Informational RFC’s.

 

A mailing = list has been established. You all are welcome to join. =  

 

vrs@sipforum.org

 

http://en.wikip= edia.org/wiki/Video_relay_service

 

http://tap.gallaud= et.edu/Conferences/NAD2012/

 

http://hraunfoss.fcc.gov/edocs_public/attachmatch= /FCC-11-184A1.pdf

 

 

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: = rshockey101
http//www.sipforum.org

 

------=_NextPart_000_0132_01CD9D77.E603A500-- From pkyzivat@alum.mit.edu Fri Sep 28 12:04:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5BD21F85AC for ; Fri, 28 Sep 2012 12:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzuXO7yEUq-t for ; Fri, 28 Sep 2012 12:04:58 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5121F84DC for ; Fri, 28 Sep 2012 12:04:57 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta12.westchester.pa.mail.comcast.net with comcast id 4iwk1k0030mv7h05Cj51CA; Fri, 28 Sep 2012 19:05:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 4izr1k00Q3ZTu2S3XizrXx; Fri, 28 Sep 2012 18:59:51 +0000 Message-ID: <5065F3AC.5080601@alum.mit.edu> Date: Fri, 28 Sep 2012 14:59:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 19:04:58 -0000 On 9/27/12 2:23 AM, Lishitao wrote: > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of I?aki Baz Castillo >> Sent: Saturday, September 22, 2012 11:09 PM >> To: Lishitao >> Cc: SIPCORE (Session Initiation Protocol Core) WG; JosĂ© Luis Millán >> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt >> >> 2012/9/22 Lishitao : >>> Hi >>> Thanks for your relay. >>> >>> In section 8.1, the example for registration, it mentioned that it support >> outbound and GRUU, my another question is how does the SIP agent get the >> instance-ID? >>> >>> Does it come from Javascript or by the browser? That every time when JS >> downloaded into the browser, it will assign a new instance-ID for the user, or >> wherever the user register from, the JS(or the browser) always assign the >> same instance-ID for the same user. >> >> Since the instance-id must be unique per device, and here the device >> is the web browser (or the mobile app or whatever) IMHO the instance >> -id must be generated by the JS application the first time it is >> executed, so it generates a random instance-id and stores it via >> Cookie or via local storage of HTML5 (in the hard disk). IMHO that >> would be a good approach. >> >> Regards. > > So ,if I open another browser on the same machine and try to register using the same SIP URI, it will get the same instance-ID, and also has to support multiple registration. > If I open a browser on another machine and try to register using the same SIP URI, it will get a different instance-ID, and register as a different user. > Right? > Regards > shitao shitao, I think you bring up interesting issues that an implementer must take into account. If you attempt to concurrently register instances from multiple windows on the same machine, it will be a problem if they use the same instanceID, unless they can coordinate and share a single registration. Assuming they can't share a single registration, some fallback must be used. E.g. the *first* instance could use a persistent instanceID saved locally, while subsequent instances might dynamically assign a temporary instanceID. If you open browsers on multiple machines, using the same AOR, then they *should* be seen as independent instances, but may register as the same user. (That is what using the same AOR means.) Thanks, Paul (as individual) From rjsparks@nostrum.com Fri Sep 28 13:17:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0FA21F860F for ; Fri, 28 Sep 2012 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GorQXX-FxVUu for ; Fri, 28 Sep 2012 13:17:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9AD21F860B for ; Fri, 28 Sep 2012 13:17:38 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8SKHb0M002004 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2012 15:17:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <506605E1.105@nostrum.com> Date: Fri, 28 Sep 2012 15:17:37 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340A6FA679@ESESSCMS0356.eemea.ericsson.se> <5065ACFD.6060704@alum.mit.edu> In-Reply-To: <5065ACFD.6060704@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] draft-ietf-sipcore-proxy-feature updates based on IETF LC ( was Re: Proxy-feature: IANA feedback regarding missing procedures for registering new feature capability indicator trees) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 20:17:38 -0000 Updating the subject to make sure people don't miss it. There were several changes made to this document based on IETF LC feedback. Please make sure you are ok with them. This document is currently on the October 11 IESG Telechat for approval. RjS On 9/28/12 8:58 AM, Paul Kyzivat wrote: > SIPCORE people: > > If anyone has issues with this revision please speak up immediately. > I'm not anticipating any concerns. > > Thanks, > Paul (as co-chair) > > On 9/28/12 7:12 AM, Christer Holmberg wrote: >> Hi, >> >> We got feedback from IANA, that the proxy-feature draft does not contain >> text about how to create new feature capability indicator trees. The >> draft only contains text about how to register feature capability >> indicators to existing trees. >> >> We’ve submitted a new version (-11), where we’ve defined procedures for >> registering new trees in section 7.3.1, saying that the “Standards >> Action” policies in RFC 5226 are used. >> >> (The need for new trees is not foreseen at this moment, but we saw no >> reason to forbid it, should a need occur in the feature). >> >> Thanks! >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Sat Sep 29 11:06:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54E721F8480 for ; Sat, 29 Sep 2012 11:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NseaU5R+C9-c for ; Sat, 29 Sep 2012 11:06:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88A5721F8489 for ; Sat, 29 Sep 2012 11:06:45 -0700 (PDT) Received: by lbok13 with SMTP id k13so3303402lbo.31 for ; Sat, 29 Sep 2012 11:06:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ChXAoV6xqdtL4EiisU9PpWIwi99hy713Du9HsUvPXn8=; b=d2Wvita/nVwuwKvgHY5vB4HU63SA3lvfQJ8G42e6CyD6gqQVNDegVXbxiV/Sbjh3Um 1DP3H2EsTQjoJ+nCOXdTIWYrpTBnwogv0zUGtQFSTuyCZGej2wjarf10aG8sRKlCwu0Q dmus9KFGq2JqMyoEfUGmMIXaXOS4DG3K3W39Liq+Wzhlgo1bjdGgbDfvOZUqDRoFZmve 7rECYDBlwzIeyKwb2ORQVP2pKdf07gCLMfGPRa7BIx4gLxEvBTFiozfp3ffbRsk7IrzW JXGxk2n3dhHHW6IJhl0dko3NBL2rDG8EYs+Q7iQxWH5Q/gQGv1LThgvHQ6lodUG1kNrm SiFw== Received: by 10.152.48.111 with SMTP id k15mr8453169lan.17.1348942004311; Sat, 29 Sep 2012 11:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Sat, 29 Sep 2012 11:06:24 -0700 (PDT) In-Reply-To: <5065F3AC.5080601@alum.mit.edu> References: <20120907124100.25690.20407.idtracker@ietfa.amsl.com> <5065F3AC.5080601@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 29 Sep 2012 20:06:24 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmXYTMqlXXjgZ24JPhGV7+byxjYgV/GLE1NQxiDaks48tpS00oxKX+s51RjAQFXsXSvAVIE Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 18:06:46 -0000 2012/9/28 Paul Kyzivat : > If you attempt to concurrently register instances from multiple windows o= n > the same machine, it will be a problem if they use the same instanceID, > unless they can coordinate and share a single registration. Hi Paul, there is a new draft for WebSocket that allows different "clients" running in the same browser (i.e. using multiple tabs) to share the same WebSocket connection to the same server by using multiplexation: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-06 -------------------------------- Abstract The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. --------------------------------- This WebSocket extension is transparent for the WebSocket sub-protocol on top of the WS connection (i.e. "sip") so when this specification becomes a standard there will be no problem in using it for SIP WebSocket clients (of course the WebSocket server acting as a SIP server/proxy must implement it). Regards. --=20 I=C3=B1aki Baz Castillo