From R.Jesske@telekom.de Sun Jul 1 23:07:23 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 CD27111E8180 for ; Sun, 1 Jul 2012 23:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boDKLKDNgnrD for ; Sun, 1 Jul 2012 23:07:23 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id A16B911E817A for ; Sun, 1 Jul 2012 23:07:22 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jul 2012 08:07:24 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 2 Jul 2012 08:07:24 +0200 From: To: Date: Mon, 2 Jul 2012 08:07:22 +0200 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-08.txt Thread-Index: Ac0nQDhKyvAC10BeS8uAwEWOWwQ43Aw1ioCw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D143522D888@HE111648.emea1.cds.t-internal.com> References: <20120501021456.29980.42006.idtracker@ietfa.amsl.com> In-Reply-To: <20120501021456.29980.42006.idtracker@ietfa.amsl.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: shida@agnada.com Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-08.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: Mon, 02 Jul 2012 06:07:23 -0000 Dear all, Since this draft is now published for about two month and no comments appea= red it looks for me that everybody is now happy with the status of the draf= t. So my question would be what is needed in addition to proceed the draft, si= nce we had already had two WGLC. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von internet-drafts@ietf.org Gesendet: Dienstag, 1. Mai 2012 04:15 An: i-d-announce@ietf.org Cc: sipcore@ietf.org Betreff: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-08.txt 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 Work= ing 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-08.txt Pages : 67 Date : 2012-04-30 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Thu Jul 5 09:58:29 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 4732321F86D7 for ; Thu, 5 Jul 2012 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8J9hxMFGPf7 for ; Thu, 5 Jul 2012 09:58:28 -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 A90DF21F8566 for ; Thu, 5 Jul 2012 09:58:28 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q65GwfTa042402 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 5 Jul 2012 11:58:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4FF5C7C1.2080102@nostrum.com> Date: Thu, 05 Jul 2012 11:58:41 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: SIPCORE Chairs References: <4FE36DDA.3080103@nostrum.com> In-Reply-To: <4FE36DDA.3080103@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 16:58:29 -0000 [as chair] This has been the second call for adoption for this document, with no interest indicated so far. We have about a day and a half left. If anyone is interested in seeing it published, please respond. if you believe that the document is not something SIPCORE should publish, please respond to that effect as well. Without any indication of interest from the working group, all we can do is publish the base specification without any examples of how the mechanism can be used. /a On 6/21/12 1:54 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] > > SIPCORE Working Group: > > As you are probably aware, back in June of 2010, we decided to split > the History-Info callflows out of the (already adopted) document > draft-ietf-sipcore-rfc4244bis. The callflows document was not formally > adopted by the working group, but remains an important informational > companion to the base specification. > > As part of the publication process, then, we would like to see > draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at > the same time as draft-ietf-sipcore-rfc4244bis. To that end, we are > announcing a two-week call for working group adoption at the same time > as a two-week working group last call. We feel this timing overlap is > appropriate due to the maturity of the document combined with the fact > that its text was, at a point in the past, part of an adopted working > group document. > > Interested parties should respond to this message with a clear > indication of whether they support the adoption of > draft-barnes-sipcore-rfc4244bis-callflows as a working group document > under the existing milestone that includes draft-ietf-sipcore-rfc4244bis. > > Additionally, any final comments on the contents of the document > should be provided during this two-week last call period. > > This call for adoption and WGLC ends on Friday, July 6th. > > The document is available here: > http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-03 > > /a From christer.holmberg@ericsson.com Thu Jul 5 10:51:02 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 514D021F861F for ; Thu, 5 Jul 2012 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI2MCnGnR8ZH for ; Thu, 5 Jul 2012 10:51:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8121F85C2 for ; Thu, 5 Jul 2012 10:50:59 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-f8-4ff5d410d324 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 07.41.23986.014D5FF4; Thu, 5 Jul 2012 19:51:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 5 Jul 2012 19:51:12 +0200 From: Christer Holmberg To: Adam Roach , SIPCORE Chairs Date: Thu, 5 Jul 2012 19:50:41 +0200 Thread-Topic: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows Thread-Index: Ac1az3E4ntVGJrDHRlixq8WrxP3fiwAB0CfS Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF418F@ESESSCMS0356.eemea.ericsson.se> References: <4FE36DDA.3080103@nostrum.com>,<4FF5C7C1.2080102@nostrum.com> In-Reply-To: <4FF5C7C1.2080102@nostrum.com> 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+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvra7gla/+BifP8Fjs+buI3eLUq9PM Fl9/bGJzYPZYsuQnk8esnU9YPL5c/swWwBzFZZOSmpNZllqkb5fAlbG4sZ+94IJIxf6dd1ka GL8LdDFyckgImEjc7znCDGGLSVy4t54NxBYSOMUoseseJ4S9gFGiuSOwi5GDg03AQqL7nzZI WEQgWGJl/zl2kDCzgJvEtacqIGEWARWJbUdeMYLYwgJFEl1tq1ghyoslrsx/zQxhG0ncXfKT HcTmFQiXaD0/A2qrp8TG5U/AbE4BbYmWld/BahiBLvt+ag0TiM0sIC5x68l8JoiLBSSW7DkP db2oxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFsIcQNvAKCEidnPmGZwCg2C8nYWUhaZiFp mYWkZQEjyypG4dzEzJz0ciO91KLM5OLi/Dy94tRNjMBIOrjlt+oOxjvnRA4xSnOwKInzWm/d 4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcV1We0F+f1cSIxdzuIFn1iM9Se9tbMtKnL+p /3RM+aB2++TceIH85Mxzf64ddJUVfibIc7ZKzsTvisr5YylOdntnajAlWvs+fp/peGnhqfm7 Chkuc8pfbPRsSJSfVKAXM+eJ5/nPZ2/riF+1NDVecXjpwv7KX28aO7omMk3jy9R6O4HPJ/yc EktxRqKhFnNRcSIA8+Uj7HICAAA= Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 17:51:02 -0000 Hi, As co-author, I am obviously interested. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Thursday, July 05, 2012 7:58 PM To: SIPCORE Chairs Cc: SIPCORE (Session Initiation Protocol Core) WG Subject: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: dra= ft-barnes-sipcore-rfc4244bis-callflows [as chair] This has been the second call for adoption for this document, with no interest indicated so far. We have about a day and a half left. If anyone is interested in seeing it published, please respond. if you believe that the document is not something SIPCORE should publish, please respond to that effect as well. Without any indication of interest from the working group, all we can do is publish the base specification without any examples of how the mechanism can be used. /a On 6/21/12 1:54 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] > > SIPCORE Working Group: > > As you are probably aware, back in June of 2010, we decided to split > the History-Info callflows out of the (already adopted) document > draft-ietf-sipcore-rfc4244bis. The callflows document was not formally > adopted by the working group, but remains an important informational > companion to the base specification. > > As part of the publication process, then, we would like to see > draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at > the same time as draft-ietf-sipcore-rfc4244bis. To that end, we are > announcing a two-week call for working group adoption at the same time > as a two-week working group last call. We feel this timing overlap is > appropriate due to the maturity of the document combined with the fact > that its text was, at a point in the past, part of an adopted working > group document. > > Interested parties should respond to this message with a clear > indication of whether they support the adoption of > draft-barnes-sipcore-rfc4244bis-callflows as a working group document > under the existing milestone that includes draft-ietf-sipcore-rfc4244bis. > > Additionally, any final comments on the contents of the document > should be provided during this two-week last call period. > > This call for adoption and WGLC ends on Friday, July 6th. > > The document is available here: > http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-03 > > /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From oej@edvina.net Thu Jul 5 11:05: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 C036321F8731 for ; Thu, 5 Jul 2012 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NJ5HETfh+vc for ; Thu, 5 Jul 2012 11:05:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8943C21F872A for ; Thu, 5 Jul 2012 11:05:03 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1003] (unknown [IPv6:2001:16d8:cc57:1000::42:1003]) by smtp7.webway.se (Postfix) with ESMTPA id F3CFD754A8AA; Thu, 5 Jul 2012 18:05:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4FF5C7C1.2080102@nostrum.com> Date: Thu, 5 Jul 2012 20:05:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0CFC5323-DCE8-49CE-80BA-723628FF69CA@edvina.net> References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1278) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 18:05:08 -0000 5 jul 2012 kl. 18:58 skrev Adam Roach: > [as chair] >=20 > This has been the second call for adoption for this document, with no = interest indicated so far. We have about a day and a half left. If = anyone is interested in seeing it published, please respond. if you = believe that the document is not something SIPCORE should publish, = please respond to that effect as well. >=20 > Without any indication of interest from the working group, all we can = do is publish the base specification without any examples of how the = mechanism can be used. I support publishing call flows. It really helps implementors. Do itt. /O >=20 > /a >=20 > On 6/21/12 1:54 PM, Adam Roach - SIPCORE Chair wrote: >> [as chair] >>=20 >> SIPCORE Working Group: >>=20 >> As you are probably aware, back in June of 2010, we decided to split = the History-Info callflows out of the (already adopted) document = draft-ietf-sipcore-rfc4244bis. The callflows document was not formally = adopted by the working group, but remains an important informational = companion to the base specification. >>=20 >> As part of the publication process, then, we would like to see = draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at the = same time as draft-ietf-sipcore-rfc4244bis. To that end, we are = announcing a two-week call for working group adoption at the same time = as a two-week working group last call. We feel this timing overlap is = appropriate due to the maturity of the document combined with the fact = that its text was, at a point in the past, part of an adopted working = group document. >>=20 >> Interested parties should respond to this message with a clear = indication of whether they support the adoption of = draft-barnes-sipcore-rfc4244bis-callflows as a working group document = under the existing milestone that includes = draft-ietf-sipcore-rfc4244bis. >>=20 >> Additionally, any final comments on the contents of the document = should be provided during this two-week last call period. >>=20 >> This call for adoption and WGLC ends on Friday, July 6th. >>=20 >> The document is available here: >> = http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-03 >>=20 >> /a >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From dworley@avaya.com Thu Jul 5 13:17: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 28A6C21F86D8 for ; Thu, 5 Jul 2012 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.122 X-Spam-Level: X-Spam-Status: No, score=-103.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv6xHz+9osoX for ; Thu, 5 Jul 2012 13:17:35 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4611521F86B5 for ; Thu, 5 Jul 2012 13:17:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMz09U+HCzI1/2dsb2JhbABFhV+wOIEZgQeCGAEBAQEDEgsGEToLEAIBCA0LAgIQDwcCAgIwFQ8BAQEEDgUIGodpnFWKHpJ5gSCKPoUHMmADmy+KC4IVZg X-IronPort-AV: E=Sophos;i="4.77,533,1336363200"; d="scan'208";a="356194098" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 05 Jul 2012 16:14:36 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Jul 2012 15:58:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 5 Jul 2012 16:17:48 -0400 From: "Worley, Dale R (Dale)" To: "adam@nostrum.com" Date: Thu, 5 Jul 2012 16:17:48 -0400 Thread-Topic: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows Thread-Index: Ac1a6z82B9HsOuuoTWC52+Lfx23dcg== Message-ID: References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> In-Reply-To: <4FF5C7C1.2080102@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 20:17:36 -0000 T24gVGh1LCAyMDEyLTA3LTA1IGF0IDExOjU4IC0wNTAwLCBBZGFtIFJvYWNoIHdyb3RlOgo+IFth cyBjaGFpcl0KPiAKPiBUaGlzIGhhcyBiZWVuIHRoZSBzZWNvbmQgY2FsbCBmb3IgYWRvcHRpb24g Zm9yIHRoaXMgZG9jdW1lbnQsIHdpdGggbm8gCj4gaW50ZXJlc3QgaW5kaWNhdGVkIHNvIGZhci4g V2UgaGF2ZSBhYm91dCBhIGRheSBhbmQgYSBoYWxmIGxlZnQuIElmIAo+IGFueW9uZSBpcyBpbnRl cmVzdGVkIGluIHNlZWluZyBpdCBwdWJsaXNoZWQsIHBsZWFzZSByZXNwb25kLiBpZiB5b3UgCj4g YmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyBub3Qgc29tZXRoaW5nIFNJUENPUkUgc2hvdWxk IHB1Ymxpc2gsIAo+IHBsZWFzZSByZXNwb25kIHRvIHRoYXQgZWZmZWN0IGFzIHdlbGwuCj4gCj4g V2l0aG91dCBhbnkgaW5kaWNhdGlvbiBvZiBpbnRlcmVzdCBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw LCBhbGwgd2UgY2FuIGRvIAo+IGlzIHB1Ymxpc2ggdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiB3aXRo b3V0IGFueSBleGFtcGxlcyBvZiBob3cgdGhlIAo+IG1lY2hhbmlzbSBjYW4gYmUgdXNlZC4KClRo aXMgZG9jdW1lbnQgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgYWRvcHRlZC4KCkJ1dCBpbiByZWdh cmQgdG8gbGFzdC1jYWxsLCBJIG5vdGUgdGhhdCBvZiBhbGwgb2YgdGhlIGV4YW1wbGVzLCBvbmx5 IG9uZQppbnZvbHZlcyBtb3JlIHRoYW4gb25lIFNJUCBkb21haW4gbmFtZSwgYW5kIHRoYXQgZXhh bXBsZSBpcyBhIHRvbGwtZnJlZQpzZXJ2aWNlIGZlZWRpbmcgdG8gYW4gQU9SOiAgVGhhdCBpcywg YWxsIGNhbGwgZmxvd3MgYXJlIHNpdHVhdGlvbnMgaW4Kd2hpY2ggc29tZSBvbmUgYWRtaW5pc3Ry YXRpdmUgZW50aXR5IGhhcyBjb29yZGluYXRlZCBldmVyeXRoaW5nLCBhbmQgYXMKYSBjb25zZXF1 ZW5jZSwgdGhlIFVBUyB0aGF0IHJlY2VpdmVzIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGNhbgoi dW5kZXJzdGFuZCIgYWxsIG9mIHRoZSBVUklzIGluIEhpc3RvcnktSW5mby4KClRoaXMgY2FuIGFs bG93IGEgbWlzdW5kZXJzdGFuZGluZyBvZiBIaXN0b3J5LUluZm8gcHJvY2Vzc2luZyAtLSB3aGlj aCBJCmhhdmUgc2VlbiBvbiB0aGlzIG1haWxpbmcgbGlzdCwgbmFtZWx5IHRoYXQgSGlzdG9yeS1J bmZvIGNhbiBiZQppbnRlcnByZXRlZCAiZnJvbSB0aGUgdG9wIiwgdGhhdCBpcywgc3RhcnRpbmcg YXQgaW5kZXggMS4gIFByb3Blcmx5LApIaXN0b3J5LUluZm8gY2FuIG9ubHkgYmUgc3VjY2Vzc2Z1 bGx5IGludGVycHJldGVkICJmcm9tIHRoZSBib3R0b20iLAp0aGF0IGlzLCB0cmFja2luZyBiYWNr IGZyb20gdGhlIFVSSSBkZXNjcmliaW5nIHRoZSBVQVMsIHRvIHRoZSBVUkkgZnJvbQp3aGljaCBp dCB3YXMgZGVyaXZlZCwgZXRjLiwgYmFjayB0byB0aGUgcG9pbnQgd2hlcmUgdGhlIFVBUyBjYW4g bm8KbG9uZ2VyIGludGVycHJldCB0aGUgVVJJcywgYXQgd2hpY2ggcG9pbnQgaXQgbXVzdCBnaXZl IHVwLiAgSW4gZ2VuZXJhbCwKdGhlIFVBUyBjYW5ub3QgZXhwZWN0IHRvIGJlIGFibGUgdG8gdW5k ZXJzdGFuZCBpbmRleCAxLgoKQXMgYSBzaW1wbGUgZXhhbXBsZSB0aGF0IGRvZXMgbm90IGhhdmUg dGhpcyBsaW1pdGF0aW9uLCBsZXQgbWUgcHJvcG9zZToKQWxpY2UgPHNpcDphbGljZUBhdGxhbnRh LmV4YW1wbGUuY29tPiBmb3J3YXJkcyB0byBCb2IKPHNpcDpib2JAYmlsb3hpLmV4YW1wbGUuY29t PiwgYnV0IEJvYiBoYXMgaGlzIHBob25lIChvciBzd2l0Y2gpIHNldCB0bwpmb3J3YXJkIHRvIENh cm9sIDxzaXA6Y2Fyb2xAY2Fpcm8uZXhhbXBsZS5jb20+LCBhbmQgQ2Fyb2wgaGFzIHNldCBoZXIK cGhvbmUvc3dpdGNoIHRvIGZvcndhcmQgdG8gRGF2aWQgPHNpcDpkYXZpZEBkZWxoaS5leGFtcGxl LmNvbT4uICBEYXZpZCdzClVBIG1heSBiZSBleHBlY3RpbmcgY2FsbHMgZGlyZWN0ZWQgdG8gQ2Fy b2wsIGJ1dCBtYXkgbm90IGtub3cgdG8gZXhwZWN0CmNhbGxzIGRpcmVjdGVkIHRvIEJvYi4KCkRh bGUKCg== From ibc@aliax.net Thu Jul 5 13:40:24 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 AA40121F8585 for ; Thu, 5 Jul 2012 13:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDzbLrj+aKq7 for ; Thu, 5 Jul 2012 13:40:24 -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 8964E21F855F for ; Thu, 5 Jul 2012 13:40:23 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so13485853lbb.31 for ; Thu, 05 Jul 2012 13:40:37 -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=7ZeQrD3B7fpsIUTyUlLJMiuain/4DzZ2xAv9y9/EhwA=; b=btxKELHp2WttbQppOhE0fmLH3XIXaPQjeiIZnUjuyAhmFRy6jq+lRqj6Zam6rn2nty hlTMvLYsT4IMu8+cMq+Ln6+FEH9AvjU0ir9vVV32ySiF0IOjgqfWKE0pZ+F96FG93Va7 xKRr1Qro3MoLyOq/b80MF60kcfjTugOjwQfEqCq2IteLEjKijNqpFiUp8ajDbNfYpC+e W/T63lTrLUfe1cdnMO9ScShhptg2qDPNyiG8ezNSKAifnp+lsz2pNu7iI6n18iIZ/LDA MBHzG8P4yeT4TRfvwVkNb2GaA/osgmgbMhuT4D5npt+gpgA79xPoihP+UOq38u5BcZeT AV3g== Received: by 10.112.27.226 with SMTP id w2mr12683831lbg.57.1341520837011; Thu, 05 Jul 2012 13:40:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Thu, 5 Jul 2012 13:40:16 -0700 (PDT) In-Reply-To: <4FF5C7C1.2080102@nostrum.com> References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Jul 2012 22:40:16 +0200 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmDkeQh3jgYihE5xKkf48teVa32uLNFNHJpEFAu8Cb6DzpKWGzUtEYa5ztx/ycVqRuyR14t Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 20:40:24 -0000 2012/7/5 Adam Roach : > [as chair] > > This has been the second call for adoption for this document, with no > interest indicated so far. We have about a day and a half left. If anyone= is > interested in seeing it published, please respond. if you believe that th= e > document is not something SIPCORE should publish, please respond to that > effect as well. > > Without any indication of interest from the working group, all we can do = is > publish the base specification without any examples of how the mechanism = can > be used. Hi, I have not too much interest in how History-Info works, but a standard document with call-flows will always help and make easier the spec adoption. So IMHO it's a useful draft and therefore I support it. If someday I have to implement History-Info I will be happy if this draft has become a standard :) Regards. --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Thu Jul 5 13:45:23 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 B463521F85C4 for ; Thu, 5 Jul 2012 13:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq7-FYVvYL9J for ; Thu, 5 Jul 2012 13:45:23 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BE21F85C3 for ; Thu, 5 Jul 2012 13:45:22 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E41AF20EF7; Thu, 5 Jul 2012 20:45:34 +0000 (UTC) Message-ID: <4FF5FCEC.2080106@acm.org> Date: Thu, 05 Jul 2012 13:45:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: SIPCORE Chairs , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 20:45:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/05/2012 01:40 PM, Iñaki Baz Castillo wrote: > 2012/7/5 Adam Roach : >> [as chair] >> >> This has been the second call for adoption for this document, with no >> interest indicated so far. We have about a day and a half left. If anyone >> is interested in seeing it published, please respond. if you believe that >> the document is not something SIPCORE should publish, please respond to >> that effect as well. >> >> Without any indication of interest from the working group, all we can do >> is publish the base specification without any examples of how the >> mechanism can be used. > > Hi, I have not too much interest in how History-Info works, but a standard > document with call-flows will always help and make easier the spec > adoption. So IMHO it's a useful draft and therefore I support it. If > someday I have to implement History-Info I will be happy if this draft has > become a standard :) The current intended status is Informational, so it cannot become a standard in its current form. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP9fzqAAoJECnERZXWan7E5/oQAOTV3X4fyXuEMuyimb0LG6KR Z0WW4NSc1o6RvOqnNHfO6z3uRCRGlJzBlPTSGud0ThHZpX+Miap+dgy3lvHyJ+ac 42tt4bv9FtraD2SgPCtISiVeTxBpqgiRdZPOw/v/et/5D7N3zbbaYHAk7gCzqM5N sFSe1ocYCfCYMFNOb0485Xo1PdBhgesFPPTp1CLW2Mzwer2M88dq6ZuYScuGKb/5 XhY4RY/v+ZkxhZ8CoIry+YdxSQ29vbdR0ADlc7gqRKext+C57WWv/b19Xis++Csj xjUDeNFEfycInPU8dWlp3RSggKfEZbCJ44TdgBh8nNnSqVQ2gmFtW2XwJDMXajy8 YH7XkPz6sbTH1g05JbsImPSqnyNVnoY2QhB3xYQu13xmzqo/XlU1vwxk22BNHwvM WFlPN9lfuifoMCUGNSz/3WKckT5f9A2FNx9Zqrcy5WcjGdJ8apPlSDI8p8iiefRH yn2iI/qEGMWXWgvo1b4WfJd6LHLykhjm8ae3ya6xpFtuppN7wclFByo81jk79Pdr e8eByOIHI7SSpZUnoXNzdnSxFOy5VN33Hu4UEAImyhXHvFKuwKoWJSBtxhEA2JUA qnHC/7YDdNUTulm/mHCpKXIoAy8dlLTsGGlIIFLWax7bqlZIeLqgrDU/i4RaWWCi F39eAl9+HxrHfkFlTNfO =LfUF -----END PGP SIGNATURE----- From ibc@aliax.net Thu Jul 5 13:46: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 D4FBB21F85D9 for ; Thu, 5 Jul 2012 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUTSsygWQTBF for ; Thu, 5 Jul 2012 13:46:52 -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 EC22321F85CE for ; Thu, 5 Jul 2012 13:46:51 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so13494227lbb.31 for ; Thu, 05 Jul 2012 13:47:05 -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=7Xk9WpGy2NnMseNOOxqgiUDdCReiPyn1VocB1N3nPN8=; b=Y9Xby7HmgU87pIlCZa1jhz4PD1EkRDdGToqJMDtfdfe6Bg0idzmLK93c+CTNfGjZ1F OZ/XkjufpsryLqmc/7olpuHCEtbi8dWUiySLAEfAr1WZ344F9SUvAQfHyeqaUx4wmJBM CiCcTEY6JT7oVMdNlQ5dG6dBBetwD6r5UkJvePgXMn+L3wxNNDFMKGkTpAfJVRVWvMNn Y9Z0luXWUkNIR6ZADcbLaXsM8HSL1MR62HxHfxhtWDzGUMZlDZOWOYpYEpTRFIJ/fBAO UcBnMEyOqPBnLV4u3Stw5D8PKHIOr/lCsEdVzqEljC/KsfXqgWnWC8lo81Yiyr1mR0VV 9wiQ== Received: by 10.152.112.233 with SMTP id it9mr27257990lab.40.1341521225555; Thu, 05 Jul 2012 13:47:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Thu, 5 Jul 2012 13:46:45 -0700 (PDT) In-Reply-To: <4FF5FCEC.2080106@acm.org> References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> <4FF5FCEC.2080106@acm.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 5 Jul 2012 22:46:45 +0200 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlN3BzgXS3/+HyLcXJzrKKl2Sxv605gPQ+eRoW28ZUlqLKPDenRg2o+9owsgEaHsZxEO68A Cc: SIPCORE Chairs , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 20:46:53 -0000 2012/7/5 Marc Petit-Huguenin : > The current intended status is Informational, so it cannot become a stand= ard > in its current form. Yes sure, I just meant that if the document becomes a RFC it is then a good documentation source for implementors. --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Thu Jul 5 13:58:42 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 51D9421F84F2 for ; Thu, 5 Jul 2012 13:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGaGFDjkYjrj for ; Thu, 5 Jul 2012 13:58:41 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F521F84D2 for ; Thu, 5 Jul 2012 13:58:41 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4538820EF7; Thu, 5 Jul 2012 20:58:55 +0000 (UTC) Message-ID: <4FF6000D.5090002@acm.org> Date: Thu, 05 Jul 2012 13:58:53 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> <4FF5FCEC.2080106@acm.org> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 05 Jul 2012 20:58:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/05/2012 01:46 PM, Iñaki Baz Castillo wrote: > 2012/7/5 Marc Petit-Huguenin : >> The current intended status is Informational, so it cannot become a >> standard in its current form. > > Yes sure, I just meant that if the document becomes a RFC it is then a good > documentation source for implementors. > No, it will be a justification for implementors to not read the standard. But that's better than having the examples inside the standard, I suppose. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP9gALAAoJECnERZXWan7EFcQQANp7jxBZMgUuUvk45/ws4o92 91mshRxETQ9jz/1X/zkZY+qq3dmVJa7lzQ3TK0ehteBWhyxj0QaTtPAo6Xtk/Em/ Kwi648TkvebabG8rNGgxZsLOVvUQ2/q64r9VVes0uUgC/g3yhyhsV440J3axFPYD iM1nI0aiv3Pe0e+usam0X1aEGsgJVZop/1/l+pojdB3lI4xJQwq0p/zAIkI6gANt kNgbIxyUOP5EBz8650qjAAmuD5ZwCt2h62EvlrJw3Q77HFr+U6Xg0NGb0Dom7mf3 XlZSOCXt8IrYgv4SBIxheJSW9wTmivSbeNrsVKGQC8HN/CNJaM/yoz2Q94V74wgC HgE6tiDYgVT6yrsOB+y3gUkIF7scI5poFi0+sUTfNJStTIkGciJaQvt+5kyAB7V6 rtqzKTE+pOHWKZIC442J/VH3nmtCwgShe7VWDBtklC5g4e08TQBmoyTiFBKrM6Sl q3iaoTz152az9YTQKD0ROy562A6HHHrXVvyTlmps/uNhriVMRyrVGsYnk09BaJuQ rIiG23t72j48QEasHJ6iU85nszJgJEpC+R899789B3clbSs9r0+7zf+k7bxEtlNt XU9EF8Ym/TWxLL/C8JH8skfxGc5HsaBwu6miY9e5kZ6jwaa6Q7A/y2HWKNjmdE34 Wrr8jh6R0Dj8kIV7Lmp4 =2ysN -----END PGP SIGNATURE----- From R.Jesske@telekom.de Thu Jul 5 22:22:13 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 ED1CC21F87E1 for ; Thu, 5 Jul 2012 22:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAlGCYP1h0Pk for ; Thu, 5 Jul 2012 22:22:11 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 94DAB21F87E0 for ; Thu, 5 Jul 2012 22:22:11 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 06 Jul 2012 07:22:25 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Jul 2012 07:22:24 +0200 From: To: , , Date: Fri, 6 Jul 2012 07:22:19 +0200 Thread-Topic: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows Thread-Index: Ac1az3E4ntVGJrDHRlixq8WrxP3fiwAB0CfSABgg7JA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14752FB514@HE111648.emea1.cds.t-internal.com> References: <4FE36DDA.3080103@nostrum.com>,<4FF5C7C1.2080102@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05853405AF418F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853405AF418F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 06 Jul 2012 05:22:13 -0000 I'm interested as well Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag = von Christer Holmberg Gesendet: Donnerstag, 5. Juli 2012 19:51 An: Adam Roach; SIPCORE Chairs Cc: SIPCORE (Session Initiation Protocol Core) WG Betreff: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draf= t-barnes-sipcore-rfc4244bis-callflows Hi, As co-author, I am obviously interested. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Thursday, July 05, 2012 7:58 PM To: SIPCORE Chairs Cc: SIPCORE (Session Initiation Protocol Core) WG Subject: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: dra= ft-barnes-sipcore-rfc4244bis-callflows [as chair] This has been the second call for adoption for this document, with no inter= est indicated so far. We have about a day and a half left. If anyone is int= erested in seeing it published, please respond. if you believe that the doc= ument is not something SIPCORE should publish, please respond to that effec= t as well. Without any indication of interest from the working group, all we can do is= publish the base specification without any examples of how the mechanism c= an be used. /a On 6/21/12 1:54 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] > > SIPCORE Working Group: > > As you are probably aware, back in June of 2010, we decided to split > the History-Info callflows out of the (already adopted) document > draft-ietf-sipcore-rfc4244bis. The callflows document was not formally > adopted by the working group, but remains an important informational > companion to the base specification. > > As part of the publication process, then, we would like to see > draft-barnes-sipcore-rfc4244bis-callflows sent to the RFC editor at > the same time as draft-ietf-sipcore-rfc4244bis. To that end, we are > announcing a two-week call for working group adoption at the same time > as a two-week working group last call. We feel this timing overlap is > appropriate due to the maturity of the document combined with the fact > that its text was, at a point in the past, part of an adopted working > group document. > > Interested parties should respond to this message with a clear > indication of whether they support the adoption of > draft-barnes-sipcore-rfc4244bis-callflows as a working group document > under the existing milestone that includes draft-ietf-sipcore-rfc4244bis. > > Additionally, any final comments on the contents of the document > should be provided during this two-week last call period. > > This call for adoption and WGLC ends on Friday, July 6th. > > The document is available here: > http://tools.ietf.org/html/draft-barnes-sipcore-rfc4244bis-callflows-0 > 3 > > /a _______________________________________________ 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 pkyzivat@alum.mit.edu Fri Jul 6 08:51:13 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 EA36021F879C for ; Fri, 6 Jul 2012 08:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBXTL9XaThbb for ; Fri, 6 Jul 2012 08:51:12 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 2621421F879A for ; Fri, 6 Jul 2012 08:51:11 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id X1ZF1j0061ZXKqc5F3raH6; Fri, 06 Jul 2012 15:51:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id X3rh1j00H3ZTu2S3h3rhfV; Fri, 06 Jul 2012 15:51:41 +0000 Message-ID: <4FF7097F.9010203@alum.mit.edu> Date: Fri, 06 Jul 2012 11:51:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 06 Jul 2012 15:51:13 -0000 On 7/5/12 4:40 PM, Iñaki Baz Castillo wrote: > Hi, I have not too much interest in how History-Info works, but a > standard document with call-flows will always help and make easier the > spec adoption. So IMHO it's a useful draft and therefore I support it. > If someday I have to implement History-Info I will be happy if this > draft has become a standard :) And like many, you will implement to the examples, without bothering to look at the spec, right? :-) Thanks, Paul From mary.ietf.barnes@gmail.com Fri Jul 6 09:04:44 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 B1A0421F86D6 for ; Fri, 6 Jul 2012 09:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.794, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUvUGlvWsUA4 for ; Fri, 6 Jul 2012 09:04:44 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id D554F21F86D0 for ; Fri, 6 Jul 2012 09:04:36 -0700 (PDT) Received: by qcsg15 with SMTP id g15so7265484qcs.27 for ; Fri, 06 Jul 2012 09:04:53 -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=yY+igk5cORYcma43B5cJUlwrMtAmHlDFChlRdI5NkdE=; b=wcF0bfOi1zgg9hxV8Qf3z9LMftjFUzubA3EpFiApxlg8hgtHIbcUpUqUd/5JKRIfoI 3UBxrJyud8GISpUgXMswPAGZ8ZZym/t5ZVnv6Cd6C6WwMQJJpqWpRT8S3l69+iR/A6GV PjYAjRkWpCpRMlhKtMA8ownQKUgjnj0zXYt8AWMm0jXBw2jPGQNNn1v9ZDTuMvDC98oO YwuuEIrnrPOwYHSi32IFgqJ1nOEADOAYeY7FmFZAn+mBH1S+4qpaY1aLp8CucomcZpsA ypP0IIvM/qfXOd7uRrIkgT25zKr3v0rqXO+QCVnusXdheMhghRVz1PUOEsVdOPJ2tlFT sFEw== MIME-Version: 1.0 Received: by 10.60.29.38 with SMTP id g6mr9360571oeh.45.1341590692999; Fri, 06 Jul 2012 09:04:52 -0700 (PDT) Received: by 10.182.147.1 with HTTP; Fri, 6 Jul 2012 09:04:52 -0700 (PDT) In-Reply-To: <4FF7097F.9010203@alum.mit.edu> References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> <4FF7097F.9010203@alum.mit.edu> Date: Fri, 6 Jul 2012 11:04:52 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8fb1f8d6b0aff104c42b6cff Cc: sipcore@ietf.org Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 06 Jul 2012 16:04:44 -0000 --e89a8fb1f8d6b0aff104c42b6cff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, many do tend to follow the call flows and not so carefully read the spec, but there's not a thing we can do about stupidity. However, the majority of people are visual learners and thus having a call flow document is an extremely useful aid to understanding the spec. I'm also hoping your comment is made as an individual and not as a chair ;) Mary. On Fri, Jul 6, 2012 at 10:51 AM, Paul Kyzivat wrote= : > On 7/5/12 4:40 PM, I=F1aki Baz Castillo wrote: > > Hi, I have not too much interest in how History-Info works, but a >> standard document with call-flows will always help and make easier the >> spec adoption. So IMHO it's a useful draft and therefore I support it. >> If someday I have to implement History-Info I will be happy if this >> draft has become a standard :) >> > > And like many, you will implement to the examples, without bothering to > look at the spec, right? :-) > > Thanks, > Paul > > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --e89a8fb1f8d6b0aff104c42b6cff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, many do tend to follow the call flows and not so carefully read the sp= ec, but there's not a thing we can do about stupidity. =A0However, the = majority of people are visual learners and thus having a call flow document= is an extremely useful aid to understanding the spec. =A0=A0

I'm also hoping your comment is made as an individual an= d not as a chair ;)=A0

Mary.=A0

On Fri, Jul 6, 2012 at 10:51 AM, Paul Kyzivat <pkyziv= at@alum.mit.edu> wrote:
On 7/5/12 4:40 PM, I=F1aki= Baz Castillo wrote:

Hi, I have not too much interest in how History-Info works, but a
standard document with call-flows will always help and make easier the
spec adoption. So IMHO it's a useful draft and therefore I support it.<= br> If someday I have to implement History-Info I will be happy if this
draft has become a standard :)

And like many, you will implement to the examples, without bothering to loo= k at the spec, right? :-)

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

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

--e89a8fb1f8d6b0aff104c42b6cff-- From pkyzivat@alum.mit.edu Fri Jul 6 09:12:08 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 F254721F87B4 for ; Fri, 6 Jul 2012 09:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYo13fFybuLR for ; Fri, 6 Jul 2012 09:12:07 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 30C5021F87A9 for ; Fri, 6 Jul 2012 09:12:07 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta15.westchester.pa.mail.comcast.net with comcast id X3Fq1j00917dt5G5F4CVjY; Fri, 06 Jul 2012 16:12:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id X4CX1j00h3ZTu2S3Z4CXmM; Fri, 06 Jul 2012 16:12:32 +0000 Message-ID: <4FF70E67.40706@alum.mit.edu> Date: Fri, 06 Jul 2012 12:12:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mary Barnes References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> <4FF7097F.9010203@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 06 Jul 2012 16:12:08 -0000 On 7/6/12 12:04 PM, Mary Barnes wrote: > Yes, many do tend to follow the call flows and not so carefully read the > spec, but there's not a thing we can do about stupidity. However, the > majority of people are visual learners and thus having a call flow > document is an extremely useful aid to understanding the spec. > > I'm also hoping your comment is made as an individual and not as a chair ;) Sorry - yes my comment was as individual. And it was a JOKE. (Note the smiley.) But it was an intentionally disparaging comment on those who implement to examples. In spite of people doing so I do think use cases and examples are a good thing. Thanks, Paul > Mary. > > On Fri, Jul 6, 2012 at 10:51 AM, Paul Kyzivat > wrote: > > On 7/5/12 4:40 PM, Iñaki Baz Castillo wrote: > > Hi, I have not too much interest in how History-Info works, but a > standard document with call-flows will always help and make > easier the > spec adoption. So IMHO it's a useful draft and therefore I > support it. > If someday I have to implement History-Info I will be happy if this > draft has become a standard :) > > > And like many, you will implement to the examples, without bothering > to look at the spec, right? :-) > > Thanks, > Paul > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From dworley@avaya.com Fri Jul 6 10:48:05 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 C907B21F8570 for ; Fri, 6 Jul 2012 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSuR4cr-wNwL for ; Fri, 6 Jul 2012 10:48:05 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F421F856F for ; Fri, 6 Jul 2012 10:48:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPMj90+HCzI1/2dsb2JhbABFhWSwTYEbgQeCGAEBAQEDEgsGEUUQAgEIDQsCAh8HAgICMBUQAQEEDg0ah2mdUYoekw2BII8tMmADmy+KC4J7 X-IronPort-AV: E=Sophos;i="4.77,540,1336363200"; d="scan'208";a="17227710" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Jul 2012 13:44:32 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jul 2012 13:29:29 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Fri, 6 Jul 2012 13:48:20 -0400 From: "Worley, Dale R (Dale)" To: "mary.ietf.barnes@gmail.com" Date: Fri, 6 Jul 2012 13:48:19 -0400 Thread-Topic: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows Thread-Index: Ac1bn4etAkRS7E5QSD21ZzSqeONFrQ== Message-ID: References: <4FE36DDA.3080103@nostrum.com> <4FF5C7C1.2080102@nostrum.com> <4FF7097F.9010203@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] PLEASE RESPOND -- Re: Call for adoption & WGLC: draft-barnes-sipcore-rfc4244bis-callflows 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, 06 Jul 2012 17:48:05 -0000 T24gRnJpLCAyMDEyLTA3LTA2IGF0IDExOjA0IC0wNTAwLCBNYXJ5IEJhcm5lcyB3cm90ZToKPiBZ ZXMsIG1hbnkgZG8gdGVuZCB0byBmb2xsb3cgdGhlIGNhbGwgZmxvd3MgYW5kIG5vdCBzbyBjYXJl ZnVsbHkgcmVhZAo+IHRoZSBzcGVjLCBidXQgdGhlcmUncyBub3QgYSB0aGluZyB3ZSBjYW4gZG8g YWJvdXQgc3R1cGlkaXR5LiAgSG93ZXZlciwKPiB0aGUgbWFqb3JpdHkgb2YgcGVvcGxlIGFyZSB2 aXN1YWwgbGVhcm5lcnMgYW5kIHRodXMgaGF2aW5nIGEgY2FsbCBmbG93Cj4gZG9jdW1lbnQgaXMg YW4gZXh0cmVtZWx5IHVzZWZ1bCBhaWQgdG8gdW5kZXJzdGFuZGluZyB0aGUgc3BlYy4gICAKCkFu ZCBpdCdzIGEgZ3JlYXQgZXJyb3ItZGV0ZWN0aW9uIHRvb2wgLS0gQXJlIHRoZSBleGFtcGxlcyBj b3JyZWN0IGJhc2VkCm9uIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHNwZWNpZmljYXRpb24/CgpE YWxlCgo= From richard@shockey.us Fri Jul 6 16:44: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 9FF0411E80CC for ; Fri, 6 Jul 2012 16:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.635 X-Spam-Level: X-Spam-Status: No, score=-98.635 tagged_above=-999 required=5 tests=[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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmCCXScqJl+T for ; Fri, 6 Jul 2012 16:44:47 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 901A411E8093 for ; Fri, 6 Jul 2012 16:44:47 -0700 (PDT) Received: (qmail 3997 invoked by uid 0); 6 Jul 2012 23:45:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 6 Jul 2012 23:45:05 -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:Cc:To:From; bh=8dWfaBL1H9ltWXNxQaLlEAUWL23h1vzDglT9OAyDfmI=; b=ApVv8Sydd+p+p49FBgd5PEUT5Cp9mMv4EHl6gdkk2PAHtyWjQRGuS1ItyxqEulHxFaa8Xj4/98MHTX0+9+kRGhoTt7ZjKPM1u/T/ZqT9U4P1kj5VqVCE+q3FuxrobIOh; Received: from [71.191.243.130] (port=64977 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1SnICu-0002JG-2P; Fri, 06 Jul 2012 17:45:04 -0600 From: "Richard Shockey" To: "'IETF-Discussion list'" Date: Fri, 6 Jul 2012 19:45:02 -0400 Message-ID: <00ec01cd5bd1$5d94fcb0$18bef610$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00ED_01CD5BAF.D6835CB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1b0VxYtKZbVnbWTyq8slFdajhb+w== 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} Cc: dispatch@ietf.org, sipcore@ietf.org Subject: [sipcore] The US Federal Communications Commission Technical Advisory Committee is discussing the end of POTS. 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, 06 Jul 2012 23:44:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00ED_01CD5BAF.D6835CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Aka the PSTN transition . http://www.fcc.gov/encyclopedia/technological-advisory-council http://transition.fcc.gov/bureaus/oet/tac/tacdocs/TAC-WG-Ques-5-9-12.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_00ED_01CD5BAF.D6835CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Aka the PSTN = transition …

 

h= ttp://www.fcc.gov/encyclopedia/technological-advisory-council

 

http://transition.fcc.gov/bureaus/oet/tac/tacdocs/TAC-WG-Ques-5-= 9-12.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_00ED_01CD5BAF.D6835CB0-- From wwwrun@rfc-editor.org Mon Jul 9 17:07: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 9710611E8157; Mon, 9 Jul 2012 17:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c6vp5+wK1Ow; Mon, 9 Jul 2012 17:07:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1186B11E8155; Mon, 9 Jul 2012 17:07:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B8EFBB1E00C; Mon, 9 Jul 2012 17:08:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120710000805.B8EFBB1E00C@rfc-editor.org> Date: Mon, 9 Jul 2012 17:08:05 -0700 (PDT) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6665 on SIP-Specific Event Notification 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, 10 Jul 2012 00:07:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6665 Title: SIP-Specific Event Notification Author: A.B. Roach Status: Standards Track Stream: IETF Date: July 2012 Mailbox: adam@nostrum.com Pages: 53 Characters: 125556 Obsoletes: RFC3265 Updates: RFC3261, RFC4660 I-D Tag: draft-ietf-sipcore-rfc3265bis-09.txt URL: http://www.rfc-editor.org/rfc/rfc6665.txt This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From victor.pascual.avila@gmail.com Fri Jul 13 01:47:10 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 B169221F86B9 for ; Fri, 13 Jul 2012 01:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulrJWuekjOEW for ; Fri, 13 Jul 2012 01:47:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB1B21F858D for ; Fri, 13 Jul 2012 01:47:09 -0700 (PDT) Received: by yenq13 with SMTP id q13so3617517yen.31 for ; Fri, 13 Jul 2012 01:47: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 :content-type:content-transfer-encoding; bh=IuwBwhnaVjprk3fz22vBzvOJEE4I5YUeF6fyAqxFMAY=; b=BmXiMSMAwu5USSRf3VrGYVFVGTMv0RbrEqNTi0Kx2BPUjLKQ8bRKPTtcHsH7UOQ72+ XfKzUmxWmE88G9lVH1Xo2An5j6L6J6Q9o5lKCZKdv3nqfO2dEih1u50ptO8gyonqWxto /KvzJM7fyReGqqT1kl8kls4mv/GN4PQuFyd+ZCZGbVxZTQPnUZutLm4BUcgY4+qgfuQT AUGZv35o/eETdECrcHXqDiA1lteb5iFvBOy7yofkewfEPCtQ6Xz8stn7WiFynPIzdj+Y lBRPLHh+EhsZ5/YnwniylhAT19n93OJfejpDFWYQMXBWQTydIWvHYO8aNG8K/7AeLm7J WQGw== MIME-Version: 1.0 Received: by 10.50.236.97 with SMTP id ut1mr166458igc.50.1342169265199; Fri, 13 Jul 2012 01:47:45 -0700 (PDT) Received: by 10.42.246.5 with HTTP; Fri, 13 Jul 2012 01:47:45 -0700 (PDT) In-Reply-To: References: <20120627094143.22737.85127.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 10:47:45 +0200 Message-ID: From: Victor Pascual Avila To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-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: Fri, 13 Jul 2012 08:47:10 -0000 Any feedback/advice would be greatly appreciated! Thanks, -Victor On Wed, Jun 27, 2012 at 11:48 AM, I=C3=B1aki Baz Castillo w= rote: > 2012/6/27 : >> >> 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. >> >> 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-01 > > > Hi, the changelog from the previous version > draft-ietf-sipcore-sip-websocket-00 is the following: > > > - Section 5.2.3. "Sending Responses" (within section 5.2. "Updates to > RFC 3261") has been removed. As Salvatore Loreto pointed out, the > existing text "is tautological saying that a WebSocket Client can act > only as a client, however in theory a UA (outside a Browser sandbox) > could act as both a WebSocket client and WebSocket server". > http://www.ietf.org/mail-archive/web/sipcore/current/msg04940.html > > - Example 1 includes the WebSocket handshake flow and some typos have > been fixed (thanks to Nataraju A. B.). > http://www.ietf.org/mail-archive/web/sipcore/current/msg04768.html > > > As always your comments are welcome. > Thanks a lot. > > -- > I=C3=B1aki Baz Castillo > From pkyzivat@alum.mit.edu Fri Jul 13 07:36: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 F169521F85B6 for ; Fri, 13 Jul 2012 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK4LMG+XPDaI for ; Fri, 13 Jul 2012 07:36:33 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5528321F85AD for ; Fri, 13 Jul 2012 07:36:25 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZqWb1j0060bG4ec5Dqd4Uv; Fri, 13 Jul 2012 14:37:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Zqd31j01a3ZTu2S3Pqd3SA; Fri, 13 Jul 2012 14:37:03 +0000 Message-ID: <5000328D.1060101@alum.mit.edu> Date: Fri, 13 Jul 2012 10:37:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <20120627094143.22737.85127.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-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: Fri, 13 Jul 2012 14:36:34 -0000 [as co-chair] The wg agreed to adopt this draft back in May, and expressed considerable interest in it. Iñaki provided a wg version of it on June 27. There has been no discussion of this since May. Is there still interest? Have people simply been busy on holiday since the wg version came out? Or do people simply think its *done* and ready for WGLC. Please let us know what you think. Thanks, Paul On 7/13/12 4:47 AM, Victor Pascual Avila wrote: > Any feedback/advice would be greatly appreciated! > > Thanks, > -Victor > > On Wed, Jun 27, 2012 at 11:48 AM, Iñaki Baz Castillo wrote: >> 2012/6/27: >>> >>> 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. >>> >>> 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-01 >> >> >> Hi, the changelog from the previous version >> draft-ietf-sipcore-sip-websocket-00 is the following: >> >> >> - Section 5.2.3. "Sending Responses" (within section 5.2. "Updates to >> RFC 3261") has been removed. As Salvatore Loreto pointed out, the >> existing text "is tautological saying that a WebSocket Client can act >> only as a client, however in theory a UA (outside a Browser sandbox) >> could act as both a WebSocket client and WebSocket server". >> http://www.ietf.org/mail-archive/web/sipcore/current/msg04940.html >> >> - Example 1 includes the WebSocket handshake flow and some typos have >> been fixed (thanks to Nataraju A. B.). >> http://www.ietf.org/mail-archive/web/sipcore/current/msg04768.html >> >> >> As always your comments are welcome. >> Thanks a lot. >> >> -- >> Iñaki Baz Castillo >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From oej@edvina.net Fri Jul 13 07:41:15 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 D683D21F87D6 for ; Fri, 13 Jul 2012 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fghSs5K+9hTc for ; Fri, 13 Jul 2012 07:41:15 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C74A221F87B2 for ; Fri, 13 Jul 2012 07:41:14 -0700 (PDT) Received: from [192.168.40.27] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CF900754A8AC; Fri, 13 Jul 2012 14:41:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <5000328D.1060101@alum.mit.edu> Date: Fri, 13 Jul 2012 16:41:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C57A449-4416-41ED-A66B-4E6C3C2539AE@edvina.net> References: <20120627094143.22737.85127.idtracker@ietfa.amsl.com> <5000328D.1060101@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-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: Fri, 13 Jul 2012 14:41:16 -0000 13 jul 2012 kl. 16:37 skrev Paul Kyzivat: > [as co-chair] >=20 > The wg agreed to adopt this draft back in May, and expressed = considerable interest in it. I=F1aki provided a wg version of it on June = 27. There has been no discussion of this since May. >=20 > Is there still interest? Have people simply been busy on holiday since = the wg version came out? Or do people simply think its *done* and ready = for WGLC. >=20 > Please let us know what you think. Paul, There has been a lot of work on implementations. Apart from I=F1aki's = first implementation, Asterisk.org Open Source PBX and Kamailio SIP = server both has implemented web socket support. =46rom following the = mailing lists of both I haven't seen anyone badmouthing the draft, but I = think the tests are still happening and we can see what will come out of = them soon. http://www.kamailio.org/w/2012/07/websockets/ https://reviewboard.asterisk.org/r/2008/ /O >=20 > Thanks, > Paul >=20 >=20 > On 7/13/12 4:47 AM, Victor Pascual Avila wrote: >> Any feedback/advice would be greatly appreciated! >>=20 >> Thanks, >> -Victor >>=20 >> On Wed, Jun 27, 2012 at 11:48 AM, I=F1aki Baz Castillo = wrote: >>> 2012/6/27: >>>>=20 >>>> 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. >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-01 >>>=20 >>>=20 >>> Hi, the changelog from the previous version >>> draft-ietf-sipcore-sip-websocket-00 is the following: >>>=20 >>>=20 >>> - Section 5.2.3. "Sending Responses" (within section 5.2. "Updates = to >>> RFC 3261") has been removed. As Salvatore Loreto pointed out, the >>> existing text "is tautological saying that a WebSocket Client can = act >>> only as a client, however in theory a UA (outside a Browser sandbox) >>> could act as both a WebSocket client and WebSocket server". >>> http://www.ietf.org/mail-archive/web/sipcore/current/msg04940.html >>>=20 >>> - Example 1 includes the WebSocket handshake flow and some typos = have >>> been fixed (thanks to Nataraju A. B.). >>> http://www.ietf.org/mail-archive/web/sipcore/current/msg04768.html >>>=20 >>>=20 >>> As always your comments are welcome. >>> Thanks a lot. >>>=20 >>> -- >>> I=F1aki Baz Castillo >>> >> _______________________________________________ >> 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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From christer.holmberg@ericsson.com Fri Jul 13 13:43: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 3476E21F85A8 for ; Fri, 13 Jul 2012 13:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.07 X-Spam-Level: X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJIxeZ-sVIsT for ; Fri, 13 Jul 2012 13:43:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62DFC21F85A7 for ; Fri, 13 Jul 2012 13:43:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-9f-5000889e43c7 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.43.07365.E9880005; Fri, 13 Jul 2012 22:44:14 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 13 Jul 2012 22:44:13 +0200 From: Christer Holmberg To: "'DRAGE, Keith (Keith)'" , "sipcore@ietf.org" Date: Fri, 13 Jul 2012 22:44:12 +0200 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments Thread-Index: Ac1KGJGLQT3zSVQSQKSlisOumDNZiAFnKsVAAAOw1dAEXQy8IA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534071B9925@ESESSCMS0356.eemea.ericsson.se> References: <20120614102909.28244.52115.idtracker@ietfa.amsl.com> In-Reply-To: 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+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre68DoYAg+42SYunjWcZLb7+2MTm wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJ+vNnGXnDDumL7YcMGxn79LkZODgkBE4lT v3czQdhiEhfurWfrYuTiEBI4xSix/c1RRpCEkMBCRol7G126GDk42AQsJLr/aYOERQTSJH40 7QLrZRFQlTg14RIziC0sEC9x6tksVpByEYEEiTNtxhDlThKf5x8HK+cVCJd4NeUOI8SqaYwS LQsXs4PUcwrESZxs4QapYQQ65/upNWD1zALiEreezIc6U0BiyZ7zzBC2qMTLx/9YIepFJe60 r2eEqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc 9HJDvdSizOTi4vw8veLUTYzA6Di45bfuDsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwKg7rzDp+BmGuUrT1GbG3Nhytn9S7SJplYfhE6YszcpWlzS+xDWxqj4u +oXcnNhMU1Zu96M7zbgCzcXVzbYwHzI56sx5/sCjsw/yLHsZvaNsDb+2LX+UPO2z05sjjJ92 hcSfvffzudhV+9/FEVe2rtr9K2Xhl6nZt8ULn1+WbPr0/NLV0NXpE4uVWIozEg21mIuKEwF7 6y0wXAIAAA== Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments 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, 13 Jul 2012 20:43:40 -0000 =20 Hi Keith, >1) Both the abstract and introduction give the viewpoint that the prime fu= nction of this document is to create a registry. The protocol creation part= is just an afterthought. To me both the abstract=20 >and introduction should reflect the SIP extension that is defined in the d= ocument, i.e. that a new header field is defined to indicate support of cap= abilities. I would certainly omit the IANA registry=20 >part from the abstract, and only put it right at the end of the introducti= on.=20 As your comments were given very late (after the WGLC deadline), I would no= t like to remove anything from the abstract at this point. Having said that, I am ok to "switch" the order in which the header field a= nd IANA registry are introduced: OLD This specification creates a new IANA registry, "Proxy-Feature Feature Caps Trees", for registering "feature caps", 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 a new SIP header field, Feature-Caps, to convey feature caps in SIP messages. NEW This specification defines a new SIP header field, Feature-Caps, to convey "feature caps" in SIP messages. This is 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 creates a new IANA registry, "Proxy-Feature Feature Caps Trees", for registering feature caps. --------------------- >2) In the respect of the above comment, I would also put section 5 before = section 4. I can do that. But, as I think section 6 shall follow section 5, I would pu= t section 5 AND section 6 before section 4. -------------------- >3) Can we use "feature capabilities" rather than "feature caps" except whe= n we are referring to the header field or tag coding.=20 We've been talking about "feature caps" since they day we decided not to us= e feature tags, so I would not like to change it at this point. In addition, we do talk about "using feature caps to indicate support of fe= atures and capabilities". -------------------- >4) I would propose pulling section 4.3 and 4.4 out to become a main sectio= n. It's scope is different from the remainder of=20 >the document, i.e. this is what specifiers of a new feature capability hav= e to document, rather than the protocol which they=20 >need to implement. Maybe we could keep section 4.4 where it is, and move section 4.3 to sectio= n 7? -------------------- >5) Section 5.1, 3rd paragraph.=20 > > The feature cap specification MUST specify for which SIP methods and > message types, and the associated semantics, the feature cap is > applicable. See Section 4 for more information. No semantics is > defined for feature caps present in SIP methods and message types not > covered by the associated feature cap specification. > >As written, this belongs in section 4.4 rather than section 5.=20 > >It also needs a reference to section 5.3.2 (1st paragraph), to section 5.3= .3 (1st paragraph) and to section 5.3.4 (1st paragraph) which provides the = general constraints. I suggest to remove the paragraph from section 5.1. Them I could add the following paragraph to section 4.4.1: NEW A feature cap specification MUST NOT modify the Feature-Caps header field = rules and semantics defined in section 5. -------------------- >6) Section 5.1, last paragraph: > > Within a given Feature-Caps header field, feature caps are listed in > a non-priority order, and for a given header field any order of > listed SIP feature caps have the same meaning. For example, > "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP > entity that inserted the feature caps supports the features and > capabilities associated with the "foo" and "bar" feature caps. > > What is the meaning of the words "for a given header field". Surely they = all appear in the same header field? Is this some hangover text from a prev= ious solution? The syntax allows multiple Feature-Caps header fields. But, maybe it would be clearer to say "For a given fc-value, as defined in = Section 6.3.1, feature caps are listed..." instead. NEW For a given fc-value, as defined in section 6.3.1, feature caps=20 are listed in a non-priority order, and any order of the listed SIP=20 feature caps have the same meaning. For example, "foo;bar" and=20 "bar;foo" have the same meaning (i.e. that the SIP entity that=20 inserted the feature caps supports the features and capabilities=20 associated with the "foo" and "bar" feature caps. -------------------- >7) Section 5.2.1, 2nd paragraph: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature caps in the > header field inform the entity about the features and capabilities > supported by the entities that inserted the header fields. > Procedures how features and capabilities are invoked are outside the > scope of this specification, and MUST be described by individual > feature cap specifications. There is a note in section 5.1, saying that F-C header fields as such do no= t contain any address information. I could move that note to section 5.2.1. -------------------- >I find this paragraph a little misleading, as it implies that the receiver= of the header field understands from the contents which entities in the me= ssage path inserted the particular feature capability. >This is untrue, all= the receiver knows is the order they were included, which may give some fo= rm of indication of nearness, but nothing beyond that. > >8) Section 5.2.3. This section covers registrar behaviour for a REGISTER m= ethod, but is the registrar not also the endpoint for SUBSCRIBE/NOTIFY when= the reg event package is used. In case of SUB/NOT the registrar is "represented" by the Contact URI in the= request/response sent by the registrar. In addition, it isn't necessarily the registrar that handles the reg event = package. -------------------- >9) Section 5.3.1, 1st paragraph: > > This Section describes the general usage and semantics of the > Feature-Caps header field for different SIP message types and > response codes. The usage and semantics of a specific feature cap > MUST be described in the associated feature cap specification. > > As a normative requirement this belongs in section 4.4. I guess your issue is the last sentence? It is already covered in section 4= .4.1, and 4.4.2, so I suggest to simply remove the last sentence. -------------------- >10) Is " feature-cap" in the ABNF formally a header field parameter in the= manner it is defined? As such should it have some representation in the he= ader field parameters table?=20 > >I agree this is presumably covered in full detail by the other IANA regist= rations, but surely there should be at least a pointer in the header field = parameters table. If we wanted to do that, we would need something saying "anything beginning= with "+". But, we did not do that for RFC 3840 either, so my suggestion wo= uld be not to do it for feature caps either. ------------------- Regards, Christer= From adam@nostrum.com Mon Jul 16 15:33: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 1CD6E11E8329 for ; Mon, 16 Jul 2012 15:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrFsd-TIbI+2 for ; Mon, 16 Jul 2012 15:33:38 -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 7FE0011E8328 for ; Mon, 16 Jul 2012 15:33:38 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6GMYNBA057690 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 17:34:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <500496EF.1040706@nostrum.com> Date: Mon, 16 Jul 2012 17:34:23 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" , "draft-barnes-sipcore-rfc4244bis-callflows@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] draft-barnes-sipcore-rfc4244bis-callflows adopted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:33:39 -0000 [as chair] Based on the positive feedback during the call for adoption, I am declaring consensus for adopting draft-barnes-sipcore-rfc4244bis-callflows as a working group item. When the document blackout is over, I would request that the authors re-submit the document as draft-ietf-sipcore-rfc4244bis-callflows. I will note that this document has also completed WGLC with no comments, which is unsurprising given its maturity. Nonetheless, any WG participants who have not yet carefully examined the document are encouraged to do so, so as to allow any issues to be caught during IETF last call. /a From adam@nostrum.com Mon Jul 16 15:34: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 6A17111E8332 for ; Mon, 16 Jul 2012 15:34:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9GalYnIrmKV for ; Mon, 16 Jul 2012 15:34:05 -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 1555211E8331 for ; Mon, 16 Jul 2012 15:34:04 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6GMYns3057759 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Jul 2012 17:34:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <50049709.7040505@nostrum.com> Date: Mon, 16 Jul 2012 17:34:49 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" , draft-ietf-sipcore-proxy-feature@tools.ietf.org, draft-ietf-sipcore-sip-websocket@tools.ietf.org Content-Type: multipart/alternative; boundary="------------060209080504070503020900" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] Call for Vancouver agenda requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:34:06 -0000 This is a multi-part message in MIME format. --------------060209080504070503020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] Today marks the -01 draft deadline, and a preliminary agenda for the upcoming meeting is due on Wednesday. If you wish for time to discuss a topic in Vancouver, please send an email to the chairs. To date, we have received one request to discuss an uncharted item (draft-holmberg-sipcore-rkeep). Given the lack of discussion on the topic, this request will be honored if time remains after all other SIPCORE business has been discussed. At the moment, the other relevant SIPCORE documents are: * draft-ietf-sipcore-proxy-feature -- post-WGLC, but with substantial outstanding comments * draft-ietf-sipcore-rfc4244bis -- post-WGLC, awaiting shepherd write-up * draft-ietf-sipcore-sip-websocket -- Seems stable, has been implemented. Ready for WGLC? * draft-barnes-sipcore-rfc4244bis-callflows -- adopted, post-WGLC, awaiting shepherd write-up. I would think, based on this list of items, that we should have discussions on the outstanding comments on proxy-feature, along with a discussion of any open issues WG participants feel we may have on SIP websockets (e.g., April/May discussion of transport versus URI). /a --------------060209080504070503020900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

Today marks the -01 draft deadline, and a preliminary agenda for the upcoming meeting is due on Wednesday. If you wish for time to discuss a topic in Vancouver, please send an email to the chairs.

To date, we have received one request to discuss an uncharted item (draft-holmberg-sipcore-rkeep). Given the lack of discussion on the topic, this request will be honored if time remains after all other SIPCORE business has been discussed.

At the moment, the other relevant SIPCORE documents are:
  • draft-ietf-sipcore-proxy-feature -- post-WGLC, but with substantial outstanding comments
  • draft-ietf-sipcore-rfc4244bis -- post-WGLC, awaiting shepherd write-up
  • draft-ietf-sipcore-sip-websocket -- Seems stable, has been implemented. Ready for WGLC?
  • draft-barnes-sipcore-rfc4244bis-callflows -- adopted, post-WGLC, awaiting shepherd write-up.


I would think, based on this list of items, that we should have discussions on the outstanding comments on proxy-feature, along with a discussion of any open issues WG participants feel we may have on SIP websockets (e.g., April/May discussion of transport versus URI).

/a


--------------060209080504070503020900-- From pkyzivat@alum.mit.edu Wed Jul 25 07:48: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 CD0A821F8609 for ; Wed, 25 Jul 2012 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMcqkd2vgYpc for ; Wed, 25 Jul 2012 07:48:31 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id C4E2021F8596 for ; Wed, 25 Jul 2012 07:48:30 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta13.westchester.pa.mail.comcast.net with comcast id ebCR1j0091uE5Es5DeoZkb; Wed, 25 Jul 2012 14:48:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id eeof1j00X3ZTu2S3ceofaZ; Wed, 25 Jul 2012 14:48:40 +0000 Message-ID: <5010073D.5020605@alum.mit.edu> Date: Wed, 25 Jul 2012 10:48:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Keith Drage References: <20120614102909.28244.52115.idtracker@ietfa.amsl.com> <7F2072F1E0DE894DA4B517B93C6A058534071B9925@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534071B9925@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments 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, 25 Jul 2012 14:48:32 -0000 Keith, Can you please indicate whether you think Christer's proposed changes will meet your concerns? Thanks, Paul On 7/13/12 4:44 PM, Christer Holmberg wrote: > > Hi Keith, > >> 1) Both the abstract and introduction give the viewpoint that the prime function of this document is to create a registry. The protocol creation part is just an afterthought. To me both the abstract >> and introduction should reflect the SIP extension that is defined in the document, i.e. that a new header field is defined to indicate support of capabilities. I would certainly omit the IANA registry >> part from the abstract, and only put it right at the end of the introduction. > > As your comments were given very late (after the WGLC deadline), I would not like to remove anything from the abstract at this point. > > Having said that, I am ok to "switch" the order in which the header field and IANA registry are introduced: > > OLD > > This specification creates a new IANA registry, "Proxy-Feature > Feature Caps Trees", for registering "feature caps", 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 a new SIP header field, Feature-Caps, > to convey feature caps in SIP messages. > > NEW > > This specification defines a new SIP header field, Feature-Caps, > to convey "feature caps" in SIP messages. This is 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 creates a new IANA registry, "Proxy-Feature > Feature Caps Trees", for registering feature caps. > > > --------------------- > >> 2) In the respect of the above comment, I would also put section 5 before section 4. > > I can do that. But, as I think section 6 shall follow section 5, I would put section 5 AND section 6 before section 4. > > > -------------------- > > >> 3) Can we use "feature capabilities" rather than "feature caps" except when we are referring to the header field or tag coding. > > We've been talking about "feature caps" since they day we decided not to use feature tags, so I would not like to change it at this point. > > In addition, we do talk about "using feature caps to indicate support of features and capabilities". > > > -------------------- > > >> 4) I would propose pulling section 4.3 and 4.4 out to become a main section. It's scope is different from the remainder of >> the document, i.e. this is what specifiers of a new feature capability have to document, rather than the protocol which they >> need to implement. > > Maybe we could keep section 4.4 where it is, and move section 4.3 to section 7? > > > -------------------- > >> 5) Section 5.1, 3rd paragraph. >> >> The feature cap specification MUST specify for which SIP methods and >> message types, and the associated semantics, the feature cap is >> applicable. See Section 4 for more information. No semantics is >> defined for feature caps present in SIP methods and message types not >> covered by the associated feature cap specification. >> >> As written, this belongs in section 4.4 rather than section 5. >> >> It also needs a reference to section 5.3.2 (1st paragraph), to section 5.3.3 (1st paragraph) and to section 5.3.4 (1st paragraph) which provides the general constraints. > > I suggest to remove the paragraph from section 5.1. > > Them I could add the following paragraph to section 4.4.1: > > NEW > > A feature cap specification MUST NOT modify the Feature-Caps header field rules and semantics defined in section 5. > > > -------------------- > > >> 6) Section 5.1, last paragraph: >> >> Within a given Feature-Caps header field, feature caps are listed in >> a non-priority order, and for a given header field any order of >> listed SIP feature caps have the same meaning. For example, >> "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP >> entity that inserted the feature caps supports the features and >> capabilities associated with the "foo" and "bar" feature caps. >> >> What is the meaning of the words "for a given header field". Surely they all appear in the same header field? Is this some hangover text from a previous solution? > > The syntax allows multiple Feature-Caps header fields. > > But, maybe it would be clearer to say "For a given fc-value, as defined in Section 6.3.1, feature caps are listed..." instead. > > NEW > > For a given fc-value, as defined in section 6.3.1, feature caps > are listed in a non-priority order, and any order of the listed SIP > feature caps have the same meaning. For example, "foo;bar" and > "bar;foo" have the same meaning (i.e. that the SIP entity that > inserted the feature caps supports the features and capabilities > associated with the "foo" and "bar" feature caps. > > -------------------- > > >> 7) Section 5.2.1, 2nd paragraph: >> >> When a SIP entity receives a SIP request, or response, that contains >> one or more Feature-Caps header fields, the feature caps in the >> header field inform the entity about the features and capabilities >> supported by the entities that inserted the header fields. >> Procedures how features and capabilities are invoked are outside the >> scope of this specification, and MUST be described by individual >> feature cap specifications. > > There is a note in section 5.1, saying that F-C header fields as such do not contain any address information. I could move that note to section 5.2.1. > > > -------------------- > >> I find this paragraph a little misleading, as it implies that the receiver of the header field understands from the contents which entities in the message path inserted the particular feature capability.>This is untrue, all the receiver knows is the order they were included, which may give some form of indication of nearness, but nothing beyond that. >> >> 8) Section 5.2.3. This section covers registrar behaviour for a REGISTER method, but is the registrar not also the endpoint for SUBSCRIBE/NOTIFY when the reg event package is used. > > In case of SUB/NOT the registrar is "represented" by the Contact URI in the request/response sent by the registrar. > > In addition, it isn't necessarily the registrar that handles the reg event package. > > > -------------------- > > >> 9) Section 5.3.1, 1st paragraph: >> >> This Section describes the general usage and semantics of the >> Feature-Caps header field for different SIP message types and >> response codes. The usage and semantics of a specific feature cap >> MUST be described in the associated feature cap specification. >> >> As a normative requirement this belongs in section 4.4. > > I guess your issue is the last sentence? It is already covered in section 4.4.1, and 4.4.2, so I suggest to simply remove the last sentence. > > > -------------------- > > >> 10) Is " feature-cap" in the ABNF formally a header field parameter in the manner it is defined? As such should it have some representation in the header field parameters table? >> >> I agree this is presumably covered in full detail by the other IANA registrations, but surely there should be at least a pointer in the header field parameters table. > > If we wanted to do that, we would need something saying "anything beginning with "+". But, we did not do that for RFC 3840 either, so my suggestion would be not to do it for feature caps either. > > > ------------------- > > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Jul 25 08:08:42 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 5CDEF21F860B for ; Wed, 25 Jul 2012 08:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-RHJS8jNHj8 for ; Wed, 25 Jul 2012 08:08:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 88CC021F84FB for ; Wed, 25 Jul 2012 08:08:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-43-50100bf6016b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8E.38.03067.6FB00105; Wed, 25 Jul 2012 17:08:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 Jul 2012 17:08:38 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , Keith Drage Date: Wed, 25 Jul 2012 17:08:37 +0200 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments Thread-Index: Ac1qdJGiGom5ZbkgQeSmh+Z2qkIM3wAAnIbg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086D4DCC@ESESSCMS0356.eemea.ericsson.se> References: <20120614102909.28244.52115.idtracker@ietfa.amsl.com> <7F2072F1E0DE894DA4B517B93C6A058534071B9925@ESESSCMS0356.eemea.ericsson.se> <5010073D.5020605@alum.mit.edu> In-Reply-To: <5010073D.5020605@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvre43boEAg8455hZnnnxjtlix4QCr xdcfm9gcmD3+vv/A5LFkyU8mj66Ds9kCmKO4bFJSczLLUov07RK4Mg6fMi+47Vpx+thZpgbG H2ZdjJwcEgImEv87f7JB2GISF+6tB7K5OIQETjFKdPw+wgiSEBJYwCixdqNUFyMHB5uAhUT3 P22QsIiAl0TzqZVgvcwCmhKPdu5lArFZBFQlXh66wQJiCwvES5x6NosVpFVEIEHiTJsxhGkk ceRvIEgFr0C4xK1X3SwQW1uZJN6e/cAOUsMpoCNx6HQlSA0j0GXfT61hgtgkLnHryXwmiIsF JJbsOc8MYYtKvHz8jxWiXlTiTvt6Roh6PYkbU6dAXaktsWzha2aIvYISJ2c+YZnAKDYLydhZ SFpmIWmZhaRlASPLKkbh3MTMnPRyc73Uoszk4uL8PL3i1E2MwDg6uOW3wQ7GTffFDjFKc7Ao ifPqqe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4W2aFYaSIMNfxOxtFNt69NVHjVIf5 T7UdL17qs1y1v8pzzqxK/mPNcnfxE9wZ9ef+zqj9LvRR/rt8/8r59kW3qnxEO355yEbVP9mt ZHDX6ci3g04rooqPVV+9cd6QLW7ukw+OjUwi06qDN8Sf95RaqCfO+jAxQWBuXEKOxIn+ROFz lYrVm8yUWIozEg21mIuKEwG4I/QWcQIAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments 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, 25 Jul 2012 15:08:42 -0000 Hi Keith, Just to clarify, that I do intend to discuss issue #10 during SIPCORE in Va= ncouver. But, for the other issues, which are mainly editorial, I would app= retiate if you could indicate whether you are ok with the suggestd changes. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 25. hein=E4kuuta 2012 17:48 To: Keith Drage Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt = - Keith's comments Keith, Can you please indicate whether you think Christer's proposed changes will = meet your concerns? Thanks, Paul On 7/13/12 4:44 PM, Christer Holmberg wrote: > > Hi Keith, > >> 1) Both the abstract and introduction give the viewpoint that the=20 >> prime function of this document is to create a registry. The protocol=20 >> creation part is just an afterthought. To me both the abstract and intro= duction should reflect the SIP extension that is defined in the document, i= .e. that a new header field is defined to indicate support of capabilities.= I would certainly omit the IANA registry part from the abstract, and only = put it right at the end of the introduction. > > As your comments were given very late (after the WGLC deadline), I would = not like to remove anything from the abstract at this point. > > Having said that, I am ok to "switch" the order in which the header field= and IANA registry are introduced: > > OLD > > This specification creates a new IANA registry, "Proxy-Feature > Feature Caps Trees", for registering "feature caps", 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 a new SIP header field, Feature-Caps= , > to convey feature caps in SIP messages. > > NEW > > This specification defines a new SIP header field, Feature-Caps, > to convey "feature caps" in SIP messages. This is 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 creates a new IANA registry, "Proxy-Feature > Feature Caps Trees", for registering feature caps. > > > --------------------- > >> 2) In the respect of the above comment, I would also put section 5 befor= e section 4. > > I can do that. But, as I think section 6 shall follow section 5, I would = put section 5 AND section 6 before section 4. > > > -------------------- > > >> 3) Can we use "feature capabilities" rather than "feature caps" except w= hen we are referring to the header field or tag coding. > > We've been talking about "feature caps" since they day we decided not to = use feature tags, so I would not like to change it at this point. > > In addition, we do talk about "using feature caps to indicate support of = features and capabilities". > > > -------------------- > > >> 4) I would propose pulling section 4.3 and 4.4 out to become a main=20 >> section. It's scope is different from the remainder of the document,=20 >> i.e. this is what specifiers of a new feature capability have to documen= t, rather than the protocol which they need to implement. > > Maybe we could keep section 4.4 where it is, and move section 4.3 to sect= ion 7? > > > -------------------- > >> 5) Section 5.1, 3rd paragraph. >> >> The feature cap specification MUST specify for which SIP methods and >> message types, and the associated semantics, the feature cap is >> applicable. See Section 4 for more information. No semantics is >> defined for feature caps present in SIP methods and message types not >> covered by the associated feature cap specification. >> >> As written, this belongs in section 4.4 rather than section 5. >> >> It also needs a reference to section 5.3.2 (1st paragraph), to section 5= .3.3 (1st paragraph) and to section 5.3.4 (1st paragraph) which provides th= e general constraints. > > I suggest to remove the paragraph from section 5.1. > > Them I could add the following paragraph to section 4.4.1: > > NEW > > A feature cap specification MUST NOT modify the Feature-Caps header fie= ld rules and semantics defined in section 5. > > > -------------------- > > >> 6) Section 5.1, last paragraph: >> >> Within a given Feature-Caps header field, feature caps are listed in >> a non-priority order, and for a given header field any order of >> listed SIP feature caps have the same meaning. For example, >> "foo;bar" and "bar;foo" have the same meaning (i.e. that the SIP >> entity that inserted the feature caps supports the features and >> capabilities associated with the "foo" and "bar" feature caps. >> >> What is the meaning of the words "for a given header field". Surely they= all appear in the same header field? Is this some hangover text from a pre= vious solution? > > The syntax allows multiple Feature-Caps header fields. > > But, maybe it would be clearer to say "For a given fc-value, as defined i= n Section 6.3.1, feature caps are listed..." instead. > > NEW > > For a given fc-value, as defined in section 6.3.1, feature caps > are listed in a non-priority order, and any order of the listed SIP > feature caps have the same meaning. For example, "foo;bar" and > "bar;foo" have the same meaning (i.e. that the SIP entity that > inserted the feature caps supports the features and capabilities > associated with the "foo" and "bar" feature caps. > > -------------------- > > >> 7) Section 5.2.1, 2nd paragraph: >> >> When a SIP entity receives a SIP request, or response, that contains >> one or more Feature-Caps header fields, the feature caps in the >> header field inform the entity about the features and capabilities >> supported by the entities that inserted the header fields. >> Procedures how features and capabilities are invoked are outside the >> scope of this specification, and MUST be described by individual >> feature cap specifications. > > There is a note in section 5.1, saying that F-C header fields as such do = not contain any address information. I could move that note to section 5.2.= 1. > > > -------------------- > >> I find this paragraph a little misleading, as it implies that the receiv= er of the header field understands from the contents which entities in the = message path inserted the particular feature capability.>This is untrue, al= l the receiver knows is the order they were included, which may give some f= orm of indication of nearness, but nothing beyond that. >> >> 8) Section 5.2.3. This section covers registrar behaviour for a REGISTER= method, but is the registrar not also the endpoint for SUBSCRIBE/NOTIFY wh= en the reg event package is used. > > In case of SUB/NOT the registrar is "represented" by the Contact URI in t= he request/response sent by the registrar. > > In addition, it isn't necessarily the registrar that handles the reg even= t package. > > > -------------------- > > >> 9) Section 5.3.1, 1st paragraph: >> >> This Section describes the general usage and semantics of the >> Feature-Caps header field for different SIP message types and >> response codes. The usage and semantics of a specific feature cap >> MUST be described in the associated feature cap specification. >> >> As a normative requirement this belongs in section 4.4. > > I guess your issue is the last sentence? It is already covered in section= 4.4.1, and 4.4.2, so I suggest to simply remove the last sentence. > > > -------------------- > > >> 10) Is " feature-cap" in the ABNF formally a header field parameter in t= he manner it is defined? As such should it have some representation in the = header field parameters table? >> >> I agree this is presumably covered in full detail by the other IANA regi= strations, but surely there should be at least a pointer in the header fiel= d parameters table. > > If we wanted to do that, we would need something saying "anything beginni= ng with "+". But, we did not do that for RFC 3840 either, so my suggestion = would be not to do it for feature caps either. > > > ------------------- > > > 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 pkyzivat@alum.mit.edu Thu Jul 26 15:05:17 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 AD35511E80BD for ; Thu, 26 Jul 2012 15:05:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTkotTHwgXUL for ; Thu, 26 Jul 2012 15:05:16 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3726F11E80BF for ; Thu, 26 Jul 2012 15:05:16 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id f9u81j00A0QuhwU51A5JSL; Thu, 26 Jul 2012 22:05:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:cd47:6191:4d81:e8d5]) by omta02.westchester.pa.mail.comcast.net with comcast id fA551j00J2jxNrA3NA55GU; Thu, 26 Jul 2012 22:05:06 +0000 Message-ID: <5011BF18.3050706@alum.mit.edu> Date: Thu, 26 Jul 2012 18:05:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Christer.Holmberg@ericsson.com" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 26 Jul 2012 22:05:18 -0000 Some comments on this, as an individual, not chair: Section 5.3: The parameter value, if present and with a value other than zero, represents a recommended keep-alive frequency, given in seconds. We've been through this before with event-rate-control (RFC 6446) - seconds are a unit for measuring intervals, not frequency. Frequency is the reciprocal of interval. I suggest you replace "frequency" with "interval" everywhere. Next: Once a SIP entity has negotiated receiving of keep-alives associated with a dialog towards an adjacent SIP entity, it MUST NOT insert a "rkeep" parameter in any subsequent SIP requests, associated with the dialog, towards that adjacent SIP entity. Such "rkeep" parameter MUST be ignored, if received. Why must it not be inserted, and why must it be ignored? Wouldn't it be useful to allow the interval to be renegotiated? Yet another thing in this section: If an INVITE request is used to indicate willingness to receive keep- alives, as long as at least one response (provisional or final) to the INVITE request contains a "rkeep" parameter with a parameter value which is different from the value in the request (counting a "rkeep" parameter without a value) it is seen as an indication that the adjacent downstream SIP entity is willing to send keep-alives associated with the dialog on which the response is received. What happens in the presence of forking? If the request is forked downstream from the node requesting keepalives, including if the neighbor does the forking, there can be responses in different early dialogs. But all of them will traverse the same neighbor who will be doing the keepalives. So, does this rule apply across all the different dialogs? Or must the response indication be separate for each? Section 5.4: The addition or removal of the value in the response to indicate acceptance seems weird. IMO it would be better to arrange it so that the presence of a value in the response means keepalives can be expected with that interval. I presume your concern is that a neighbor that doesn't support this will leave the parameter unchanged, so you need a way to force a change even if the requested interval is to be used. Maybe we can find another way to accomplish that. Perhaps something extra in the request, in addition to the interval, that can be removed in the response. E.g.: Request Positive Response Negative Response rkeep=5:desired rkeep=5, rkeep=5:desired or rkeep=10 or rkeep If that's too verbose, how about "rkeep=5?" Section 7: Its empty! Thanks, Paul From christer.holmberg@ericsson.com Thu Jul 26 15:33:23 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 46F8A21F851B for ; Thu, 26 Jul 2012 15:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XeT3UnXvlKK for ; Thu, 26 Jul 2012 15:33:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF7E221F8517 for ; Thu, 26 Jul 2012 15:33:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-93-5011c5b03d06 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AA.6E.07365.0B5C1105; Fri, 27 Jul 2012 00:33:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 27 Jul 2012 00:33:20 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Fri, 27 Jul 2012 00:33:18 +0200 Thread-Topic: Comments on draft-holmberg-sipcore-rkeep-00 Thread-Index: Ac1rer0Gwbo6ETY6Te2zIbDjHR26GAAATguw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> References: <5011BF18.3050706@alum.mit.edu> In-Reply-To: <5011BF18.3050706@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+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre6Go4IBBhvPiFus2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGieeX2As2KFbMeT+DtYGxU6qLkYNDQsBE 4sPMtC5GTiBTTOLCvfVsXYxcHEICpxglHvw/DOUsYJT4u/YQK0gDm4CFRPc/bZAGEQEtiQNX LrOA2MwCchLXP2xkA7FZBFQljk3oYAKxhYHKn244wgJRbynR1LOIDcI2kri8pQXM5hUIl1h4 eS0jiC0koC1xom0DM4jNKaAjMWn7FrBeRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rRL2oxJ329YwQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExjFZiEZOwtJyywkLbOQtCxg ZFnFKJybmJmTXm6ol1qUmVxcnJ+nV5y6iREYOQe3/NbdwXjqnMghRmkOFiVxXq6k/f5CAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGGs9ntzom6v16+Hao7LcEr+upPnPyq0N1X2TNpUh+NDX aeuvu5vd/rUhOlSDrcf+G5f11vNHpNPfdrv2LJvaoDtb60l2I+/kJ1c6z3E8jF+Yf/Rm2Pze qcfnabLefPJPyMDTUtL51Y2CooPXi2X8Hsw4dE6uZsLtnwmtnRHHC38Gt1+v5Pi930GJpTgj 0VCLuag4EQA796EKagIAAA== Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 26 Jul 2012 22:33:23 -0000 Hi Paul, Thanks for your comments! See inline. In general, the procedures are based on RFC 6223, so any restrictions and l= imitations that apply there also apply in the rkeep draft (unless they are = affected by the semantical difference between the Via header field paramete= rs in the both specs). --------------------------- =20 >Section 5.3: > > The parameter value, if present and with a value other > than zero, represents a recommended keep-alive frequency, given in > seconds. > > We've been through this before with event-rate-control (RFC 6446) - secon= ds are a unit for measuring intervals,=20 > not frequency. Frequency is the reciprocal of interval. I suggest you rep= lace "frequency" with "interval" everywhere. I guess we've been through that after RFC 6223, or we didn't spot it there,= because it also talks about "frequency" :) Having said that, eventhough I think common terminology would be useful, I = see no major issue in using "interval" for rkeep. --------------------------- >Next: > > Once a SIP entity has negotiated receiving of keep-alives associated > with a dialog towards an adjacent SIP entity, it MUST NOT insert a > "rkeep" parameter in any subsequent SIP requests, associated with the > dialog, towards that adjacent SIP entity. Such "rkeep" parameter > MUST be ignored, if received. > >Why must it not be inserted, and why must it be ignored? >Wouldn't it be useful to allow the interval to be renegotiated? Again, this restriction comes from RFC 6223. I would have to dig through the archieves to remind myself why we made that= restriction, but I ASSUME it could be related to the fact that it was a li= ttle unclear in which SIP request types (target refresh, etc) we would allo= w it. --------------------------- >Yet another thing in this section: > > If an INVITE request is used to indicate willingness to receive keep- > alives, as long as at least one response (provisional or final) to > the INVITE request contains a "rkeep" parameter with a parameter > value which is different from the value in the request (counting a > "rkeep" parameter without a value) it is seen as an indication that > the adjacent downstream SIP entity is willing to send keep-alives > associated with the dialog on which the response is received. > >What happens in the presence of forking? > >If the request is forked downstream from the node requesting keepalives, i= ncluding if the neighbor does the forking, there can be responses in differ= ent early dialogs. But all of them will traverse the same neighbor who will= be doing >the keepalives. So, does this rule apply across all the differen= t dialogs? Or must the response indication be separate for each? I guess it would be good to indicate the willingess to send keep-alives for= each dialog, as dialogs have different lifetime. However, I see no need to= start sending keep-alive instances for each dialog, as they are sent to th= e same entity. --------------------------- >Section 5.4: > >The addition or removal of the value in the response to indicate acceptanc= e seems weird. > >IMO it would be better to arrange it so that the presence of a value in th= e response means keepalives can be expected with that interval. > >I presume your concern is that a neighbor that doesn't support this will l= eave the parameter unchanged, so you need a way to force a change even if t= he requested interval is to be used. Correct. >Maybe we can find another way to accomplish that. Perhaps something extra = in the request, in addition to the interval, that can be removed in the res= ponse. E.g.: > > Request Positive Response Negative Response > rkeep=3D5:desired rkeep=3D5, rkeep=3D5:desired > or rkeep=3D10 or rkeep > >If that's too verbose, how about "rkeep=3D5?" I guess there are many ways how it could be done. I just thought the curren= tly suggested one was a simple one, without the need for additional paramet= ers etc. --------------------------- >Section 7: > >Its empty! Will be fixed in the next version. Regards, Christer From pkyzivat@alum.mit.edu Thu Jul 26 17:38:27 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 EDB8C21F8491 for ; Thu, 26 Jul 2012 17:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4WSryD+kJfC for ; Thu, 26 Jul 2012 17:38:27 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 216FF21F848F for ; Thu, 26 Jul 2012 17:38:26 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id fBam1j0011YDfWL5DCeV7Q; Fri, 27 Jul 2012 00:38:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id fCeF1j00Z3ZTu2S3gCeFz1; Fri, 27 Jul 2012 00:38:16 +0000 Message-ID: <5011E301.5020604@alum.mit.edu> Date: Thu, 26 Jul 2012 20:38:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <5011BF18.3050706@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 27 Jul 2012 00:38:28 -0000 On 7/26/12 6:33 PM, Christer Holmberg wrote: > > Hi Paul, > > Thanks for your comments! See inline. > > In general, the procedures are based on RFC 6223, so any restrictions and limitations that apply there also apply in the rkeep draft (unless they are affected by the semantical difference between the Via header field parameters in the both specs). > > > --------------------------- > > >> Section 5.3: >> >> The parameter value, if present and with a value other >> than zero, represents a recommended keep-alive frequency, given in >> seconds. >> >> We've been through this before with event-rate-control (RFC 6446) - seconds are a unit for measuring intervals, >> not frequency. Frequency is the reciprocal of interval. I suggest you replace "frequency" with "interval" everywhere. > > I guess we've been through that after RFC 6223, or we didn't spot it there, because it also talks about "frequency" :) > > Having said that, eventhough I think common terminology would be useful, I see no major issue in using "interval" for rkeep. Feel free to use frequency rather than interval. But then the units can't be seconds. They then need to be keepalives-per-second. > --------------------------- > > >> Next: >> >> Once a SIP entity has negotiated receiving of keep-alives associated >> with a dialog towards an adjacent SIP entity, it MUST NOT insert a >> "rkeep" parameter in any subsequent SIP requests, associated with the >> dialog, towards that adjacent SIP entity. Such "rkeep" parameter >> MUST be ignored, if received. >> >> Why must it not be inserted, and why must it be ignored? >> Wouldn't it be useful to allow the interval to be renegotiated? > > Again, this restriction comes from RFC 6223. > > I would have to dig through the archieves to remind myself why we made that restriction, but I ASSUME it could be related to the fact that it was a little unclear in which SIP request types (target refresh, etc) we would allow it. If you've got good reason then I won't object. It's not a big deal. > --------------------------- > > >> Yet another thing in this section: >> >> If an INVITE request is used to indicate willingness to receive keep- >> alives, as long as at least one response (provisional or final) to >> the INVITE request contains a "rkeep" parameter with a parameter >> value which is different from the value in the request (counting a >> "rkeep" parameter without a value) it is seen as an indication that >> the adjacent downstream SIP entity is willing to send keep-alives >> associated with the dialog on which the response is received. >> >> What happens in the presence of forking? >> >> If the request is forked downstream from the node requesting keepalives, including if the neighbor does the forking, there can be responses in different early dialogs. But all of them will traverse the same neighbor who will be doing>the keepalives. So, does this rule apply across all the different dialogs? Or must the response indication be separate for each? > > I guess it would be good to indicate the willingess to send keep-alives for each dialog, as dialogs have different lifetime. However, I see no need to start sending keep-alive instances for each dialog, as they are sent to the same entity. I just think you need to discuss it. Once you have something down about it there may be a number of people with opinions about it. > --------------------------- > > >> Section 5.4: >> >> The addition or removal of the value in the response to indicate acceptance seems weird. >> >> IMO it would be better to arrange it so that the presence of a value in the response means keepalives can be expected with that interval. >> >> I presume your concern is that a neighbor that doesn't support this will leave the parameter unchanged, so you need a way to force a change even if the requested interval is to be used. > > Correct. > >> Maybe we can find another way to accomplish that. Perhaps something extra in the request, in addition to the interval, that can be removed in the response. E.g.: >> >> Request Positive Response Negative Response >> rkeep=5:desired rkeep=5, rkeep=5:desired >> or rkeep=10 or rkeep >> >> If that's too verbose, how about "rkeep=5?" > > I guess there are many ways how it could be done. I just thought the currently suggested one was a simple one, without the need for additional parameters etc. I'd like to have some other opinions on this. It's really a matter of taste. It can work as it is. As I say, to me it just seems weird and possibly something that people will misunderstand and implement wrong. > --------------------------- > >> Section 7: >> >> Its empty! > > Will be fixed in the next version. OK. Thanks, Paul From dworley@avaya.com Fri Jul 27 10:32:03 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 942B921F8731 for ; Fri, 27 Jul 2012 10:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vk6se1VvCad for ; Fri, 27 Jul 2012 10:32:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B2A0D21F861F for ; Fri, 27 Jul 2012 10:32:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABnQElDGmAcF/2dsb2JhbABFDoVjsl9/gQeCIAEBAQECARIREUUQAgEIDQsCAiYCAgIwFRABAQQODRqHZQadN4oekz+BIZARMmADm0WKEIImVYE6BQI X-IronPort-AV: E=Sophos;i="4.77,668,1336363200"; d="scan'208";a="359260704" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jul 2012 13:28:12 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jul 2012 13:27:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 27 Jul 2012 13:32:00 -0400 From: "Worley, Dale R (Dale)" To: "pkyzivat@alum.mit.edu" Date: Fri, 27 Jul 2012 13:32:00 -0400 Thread-Topic: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 Thread-Index: Ac1sHbrH4PjI/GQzTqetOpmcWHEZbg== Message-ID: References: <5011BF18.3050706@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> <5011E301.5020604@alum.mit.edu> In-Reply-To: <5011E301.5020604@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 27 Jul 2012 17:32:03 -0000 T24gVGh1LCAyMDEyLTA3LTI2IGF0IDIwOjM4IC0wNDAwLCBQYXVsIEt5eml2YXQgd3JvdGU6Cj4g RmVlbCBmcmVlIHRvIHVzZSBmcmVxdWVuY3kgcmF0aGVyIHRoYW4gaW50ZXJ2YWwuIEJ1dCB0aGVu IHRoZSB1bml0cyAKPiBjYW4ndCBiZSBzZWNvbmRzLiBUaGV5IHRoZW4gbmVlZCB0byBiZSBrZWVw YWxpdmVzLXBlci1zZWNvbmQuCgorMQoKR2VuZXJhbGx5IHBlb3BsZSB1c2UgaW50ZXJ2YWxzIHJh dGhlciB0aGFuIGZyZXF1ZW5jaWVzIGluCnByb3RvY29sLXJlbGF0ZWQgcXVhbnRpdGllcy4KCj4g Pj4gICAgIE9uY2UgYSBTSVAgZW50aXR5IGhhcyBuZWdvdGlhdGVkIHJlY2VpdmluZyBvZiBrZWVw LWFsaXZlcyBhc3NvY2lhdGVkCj4gPj4gICAgIHdpdGggYSBkaWFsb2cgdG93YXJkcyBhbiBhZGph Y2VudCBTSVAgZW50aXR5LCBpdCBNVVNUIE5PVCBpbnNlcnQgYQo+ID4+ICAgICAicmtlZXAiIHBh cmFtZXRlciBpbiBhbnkgc3Vic2VxdWVudCBTSVAgcmVxdWVzdHMsIGFzc29jaWF0ZWQgd2l0aCB0 aGUKPiA+PiAgICAgZGlhbG9nLCB0b3dhcmRzIHRoYXQgYWRqYWNlbnQgU0lQIGVudGl0eS4gIFN1 Y2ggInJrZWVwIiBwYXJhbWV0ZXIKPiA+PiAgICAgTVVTVCBiZSBpZ25vcmVkLCBpZiByZWNlaXZl ZC4KPiA+Pgo+ID4+IFdoeSBtdXN0IGl0IG5vdCBiZSBpbnNlcnRlZCwgYW5kIHdoeSBtdXN0IGl0 IGJlIGlnbm9yZWQ/Cj4gPj4gV291bGRuJ3QgaXQgYmUgdXNlZnVsIHRvIGFsbG93IHRoZSBpbnRl cnZhbCB0byBiZSByZW5lZ290aWF0ZWQ/Cj4gPgo+ID4gQWdhaW4sIHRoaXMgcmVzdHJpY3Rpb24g Y29tZXMgZnJvbSBSRkMgNjIyMy4KPiA+Cj4gPiBJIHdvdWxkIGhhdmUgdG8gZGlnIHRocm91Z2gg dGhlIGFyY2hpZXZlcyB0byByZW1pbmQgbXlzZWxmIHdoeSB3ZQo+IG1hZGUgdGhhdCByZXN0cmlj dGlvbiwgYnV0IEkgQVNTVU1FIGl0IGNvdWxkIGJlIHJlbGF0ZWQgdG8gdGhlIGZhY3QKPiB0aGF0 IGl0IHdhcyBhIGxpdHRsZSB1bmNsZWFyIGluIHdoaWNoIFNJUCByZXF1ZXN0IHR5cGVzICh0YXJn ZXQKPiByZWZyZXNoLCBldGMpIHdlIHdvdWxkIGFsbG93IGl0Lgo+IAo+IElmIHlvdSd2ZSBnb3Qg Z29vZCByZWFzb24gdGhlbiBJIHdvbid0IG9iamVjdC4gSXQncyBub3QgYSBiaWcgZGVhbC4KCk9m ZiB0aGUgdG9wIG9mIG15IGhlYWQsIEkgZ3Vlc3MgdGhlIHByb2JsZW0gcmVnYXJkcyBvcmRlcmlu ZzogIFNpbmNlIChpbgpnZW5lcmFsKSB0aGUgdHdvIGVudGl0aWVzIGFyZSBwcm94aWVzLCB0aGV5 IGRvIG5vdCBuZWNlc3NhcmlseSBzZWUgdGhlCnJlcXVlc3RzIG9mIGEgZGlhbG9nIGluIHRoZSBz YW1lIG9yZGVyLgoKPiA+PiAgICAgSWYgYW4gSU5WSVRFIHJlcXVlc3QgaXMgdXNlZCB0byBpbmRp Y2F0ZSB3aWxsaW5nbmVzcyB0byByZWNlaXZlIGtlZXAtCj4gPj4gICAgIGFsaXZlcywgYXMgbG9u ZyBhcyBhdCBsZWFzdCBvbmUgcmVzcG9uc2UgKHByb3Zpc2lvbmFsIG9yIGZpbmFsKSB0bwo+ID4+ ICAgICB0aGUgSU5WSVRFIHJlcXVlc3QgY29udGFpbnMgYSAicmtlZXAiIHBhcmFtZXRlciB3aXRo IGEgcGFyYW1ldGVyCj4gPj4gICAgIHZhbHVlIHdoaWNoIGlzIGRpZmZlcmVudCBmcm9tIHRoZSB2 YWx1ZSBpbiB0aGUgcmVxdWVzdCAoY291bnRpbmcgYQo+ID4+ICAgICAicmtlZXAiIHBhcmFtZXRl ciB3aXRob3V0IGEgdmFsdWUpIGl0IGlzIHNlZW4gYXMgYW4gaW5kaWNhdGlvbiB0aGF0Cj4gPj4g ICAgIHRoZSBhZGphY2VudCBkb3duc3RyZWFtIFNJUCBlbnRpdHkgaXMgd2lsbGluZyB0byBzZW5k IGtlZXAtYWxpdmVzCj4gPj4gICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgZGlhbG9nIG9uIHdoaWNo IHRoZSByZXNwb25zZSBpcyByZWNlaXZlZC4KPiA+Pgo+ID4+IFdoYXQgaGFwcGVucyBpbiB0aGUg cHJlc2VuY2Ugb2YgZm9ya2luZz8KPiA+Pgo+ID4+IElmIHRoZSByZXF1ZXN0IGlzIGZvcmtlZCBk b3duc3RyZWFtIGZyb20gdGhlIG5vZGUgcmVxdWVzdGluZwo+IGtlZXBhbGl2ZXMsIGluY2x1ZGlu ZyBpZiB0aGUgbmVpZ2hib3IgZG9lcyB0aGUgZm9ya2luZywgdGhlcmUgY2FuIGJlCj4gcmVzcG9u c2VzIGluIGRpZmZlcmVudCBlYXJseSBkaWFsb2dzLiBCdXQgYWxsIG9mIHRoZW0gd2lsbCB0cmF2 ZXJzZQo+IHRoZSBzYW1lIG5laWdoYm9yIHdobyB3aWxsIGJlIGRvaW5nPnRoZSBrZWVwYWxpdmVz LiBTbywgZG9lcyB0aGlzIHJ1bGUKPiBhcHBseSBhY3Jvc3MgYWxsIHRoZSBkaWZmZXJlbnQgZGlh bG9ncz8gT3IgbXVzdCB0aGUgcmVzcG9uc2UKPiBpbmRpY2F0aW9uIGJlIHNlcGFyYXRlIGZvciBl YWNoPwo+ID4KPiA+IEkgZ3Vlc3MgaXQgd291bGQgYmUgZ29vZCB0byBpbmRpY2F0ZSB0aGUgd2ls bGluZ2VzcyB0byBzZW5kCj4ga2VlcC1hbGl2ZXMgZm9yIGVhY2ggZGlhbG9nLCBhcyBkaWFsb2dz IGhhdmUgZGlmZmVyZW50IGxpZmV0aW1lLgo+IEhvd2V2ZXIsIEkgc2VlIG5vIG5lZWQgdG8gc3Rh cnQgc2VuZGluZyBrZWVwLWFsaXZlIGluc3RhbmNlcyBmb3IgZWFjaAo+IGRpYWxvZywgYXMgdGhl eSBhcmUgc2VudCB0byB0aGUgc2FtZSBlbnRpdHkuCj4gCj4gSSBqdXN0IHRoaW5rIHlvdSBuZWVk IHRvIGRpc2N1c3MgaXQuCj4gT25jZSB5b3UgaGF2ZSBzb21ldGhpbmcgZG93biBhYm91dCBpdCB0 aGVyZSBtYXkgYmUgYSBudW1iZXIgb2YgcGVvcGxlIAo+IHdpdGggb3BpbmlvbnMgYWJvdXQgaXQu CgpJIHNlZSB0aGlzIHRleHQ6CgogICBBIFNJUCBlbnRpdHkgTVVTVCBOT1QgaW5kaWNhdGVzIHdp bGxpbmduZXNzIHRvIHNlbmQvcmVjZWl2ZSBrZWVwLWFsaXZlcwogICBhc3NvY2lhdGVkIHdpdGgg YSBkaWFsb2csIHVubGVzcyBpdCBoYXMgYWxzbyBpbnNlcnRlZCBpdHNlbGYgaW4gdGhlCiAgIGRp YWxvZyByb3V0ZSBzZXQgW1JGQzMyNjFdLgoKU28gdGhlIHNlbmRpbmcvcmVjZWl2aW5nIG9mIGtl ZXBhbGl2ZXMgaXMgYm91bmQgdG8gYSBkaWFsb2cuICBUaGF0IG1ha2VzCnNlbnNlLCBhcyB0aGUg ZW5kIG9mIHRoZSBkaWFsb2cgZGV0ZXJtaW5lcyB3aGVuIHRoZSBrZWVwYWxpdmVzIHN0b3AuCihC VFcsIGRvZXMgdGhlIGRyYWZ0IHN0YXRlIHRoYXQgZXhwbGljaXRseT8pCgpJZiBhIHJlcXVlc3Qg Zm9ya3MgZnVydGhlciBkb3duc3RyZWFtLCB0aGUgZW50aXR5IGlzIFJlY29yZC1Sb3V0ZWQgaW50 bwphbGwgb2YgdGhlIGZvcmtzLCBidXQgb2YgY291cnNlLCBlYWNoIGZvcmsgaGFzIGEgZGlmZmVy ZW50IGxpZmV0aW1lLgoKSXQgc291bmRzIGxpa2UgeW91IHdhbnQgdG8gc2F5IHRoYXQgYWxsIG9m IHRoZSBkaWFsb2dzIGZvcm0gYSBncm91cCwgYW5kCnRoZSBncm91cCBjYW4gYmUgImtlcHQgYWxp dmUiIGJ5IG9ubHkgb25lIHNlcXVlbmNlIG9mIGtlZXBhbGl2ZXMsIGJ1dAp0aGUgc2VxdWVuY2Ug b2Yga2VlcGFsaXZlcyBtdXN0IGJlIG1haW50YWluZWQgYXMgbG9uZyBhcyBhbnkgZGlhbG9nIGlu CnRoZSBncm91cCBleGlzdHMuCgpCVFcsIGRvZXMgdGhlIG1lY2hhbmlzbSBlbnN1cmUgdGhhdCB0 aGUgbmVnb3RpYXRlZCBrZWVwYWxpdmUgaW50ZXJ2YWwgaXMKdGhlIHNhbWUgZm9yIGFsbCBmb3Jr cz8KCj4gPj4gTWF5YmUgd2UgY2FuIGZpbmQgYW5vdGhlciB3YXkgdG8gYWNjb21wbGlzaCB0aGF0 LiBQZXJoYXBzIHNvbWV0aGluZwo+IGV4dHJhIGluIHRoZSByZXF1ZXN0LCBpbiBhZGRpdGlvbiB0 byB0aGUgaW50ZXJ2YWwsIHRoYXQgY2FuIGJlIHJlbW92ZWQKPiBpbiB0aGUgcmVzcG9uc2UuIEUu Zy46Cj4gPj4KPiA+PiAJUmVxdWVzdAkgICAgIFBvc2l0aXZlIFJlc3BvbnNlICBOZWdhdGl2ZSBS ZXNwb25zZQo+ID4+IAlya2VlcD01OmRlc2lyZWQgIHJrZWVwPTUsICAgICAgICAgICBya2VlcD01 OmRlc2lyZWQKPiA+PiAJICAgICAgICAgICAgICAgICBvciBya2VlcD0xMCAgICAgICAgb3Igcmtl ZXAKPiA+Pgo+ID4+IElmIHRoYXQncyB0b28gdmVyYm9zZSwgaG93IGFib3V0ICJya2VlcD01PyIK PiA+Cj4gPiBJIGd1ZXNzIHRoZXJlIGFyZSBtYW55IHdheXMgaG93IGl0IGNvdWxkIGJlIGRvbmUu IEkganVzdCB0aG91Z2h0IHRoZQo+IGN1cnJlbnRseSBzdWdnZXN0ZWQgb25lIHdhcyBhIHNpbXBs ZSBvbmUsIHdpdGhvdXQgdGhlIG5lZWQgZm9yCj4gYWRkaXRpb25hbCBwYXJhbWV0ZXJzIGV0Yy4K PiAKPiBJJ2QgbGlrZSB0byBoYXZlIHNvbWUgb3RoZXIgb3BpbmlvbnMgb24gdGhpcy4KPiBJdCdz IHJlYWxseSBhIG1hdHRlciBvZiB0YXN0ZS4gSXQgY2FuIHdvcmsgYXMgaXQgaXMuCj4gQXMgSSBz YXksIHRvIG1lIGl0IGp1c3Qgc2VlbXMgd2VpcmQgYW5kIHBvc3NpYmx5IHNvbWV0aGluZyB0aGF0 IHBlb3BsZSAKPiB3aWxsIG1pc3VuZGVyc3RhbmQgYW5kIGltcGxlbWVudCB3cm9uZy4KCkF0IHRo ZSBsZWFzdCwgaXQgbXVzdCBiZSBwb3NzaWJsZSB0byBleGFtaW5lIGEgU0lQIG1lc3NhZ2UgaW4g aXNvbGF0aW9uCmFuZCBkZXRlcm1pbmUgdGhlIG1lYW5pbmcgb2YgdGhlIHJrZWVwIHBhcmFtZXRl ciB3aXRob3V0IGFueSBmdXJ0aGVyCmNvbnRleHQuICBGcm9tIHRoZSBjaGFydCBhYm92ZSwgaXQg YXBwZWFycyB0aGF0IHRoZSBjdXJyZW50IGRlZmluaXRpb24KaGFzIHRoYXQgcHJvcGVydHkuCgpI b3dldmVyIHRoZSBzaXR1YXRpb24gZG9lcyBzZWVtIHRvIGJlIGNvbmZ1c2luZy4gIFlvdSBzaG91 bGQgaGF2ZSBhCnN1bW1hcnkgaW4gdGhlIGRyYWZ0IG11Y2ggbGlrZSB0aGUgYWJvdmUgY2hhcnQu ICBCZXR0ZXIsIG9uY2UgeW91IGhhdmUKd3JpdHRlbiB0aGUgY2hhcnQsIHBlb3BsZSBjYW4gZGlz Y3VzcyB3aGV0aGVyIHRoZXkgd291bGQgbGlrZSB0byBhZGp1c3QKdGhlIHN5bnRheC4KCkRhbGUK Cg== From pkyzivat@alum.mit.edu Fri Jul 27 11:16: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 89A0F21F8543 for ; Fri, 27 Jul 2012 11:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_53=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACAuTel+cIeT for ; Fri, 27 Jul 2012 11:16:18 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 985A421F84D6 for ; Fri, 27 Jul 2012 11:16:18 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id fTP51j0090ldTLk51WGMmi; Fri, 27 Jul 2012 18:16:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id fWGE1j00i3ZTu2S3QWGEWF; Fri, 27 Jul 2012 18:16:15 +0000 Message-ID: <5012DAF1.2050909@alum.mit.edu> Date: Fri, 27 Jul 2012 14:16:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <5011BF18.3050706@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> <5011E301.5020604@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 27 Jul 2012 18:16:19 -0000 On 7/27/12 1:32 PM, Worley, Dale R (Dale) wrote: > On Thu, 2012-07-26 at 20:38 -0400, Paul Kyzivat wrote: >> Feel free to use frequency rather than interval. But then the units >> can't be seconds. They then need to be keepalives-per-second. > > +1 > > Generally people use intervals rather than frequencies in > protocol-related quantities. > >>>> Once a SIP entity has negotiated receiving of keep-alives associated >>>> with a dialog towards an adjacent SIP entity, it MUST NOT insert a >>>> "rkeep" parameter in any subsequent SIP requests, associated with the >>>> dialog, towards that adjacent SIP entity. Such "rkeep" parameter >>>> MUST be ignored, if received. >>>> >>>> Why must it not be inserted, and why must it be ignored? >>>> Wouldn't it be useful to allow the interval to be renegotiated? >>> >>> Again, this restriction comes from RFC 6223. >>> >>> I would have to dig through the archieves to remind myself why we >> made that restriction, but I ASSUME it could be related to the fact >> that it was a little unclear in which SIP request types (target >> refresh, etc) we would allow it. >> >> If you've got good reason then I won't object. It's not a big deal. > > Off the top of my head, I guess the problem regards ordering: Since (in > general) the two entities are proxies, they do not necessarily see the > requests of a dialog in the same order. > >>>> If an INVITE request is used to indicate willingness to receive keep- >>>> alives, as long as at least one response (provisional or final) to >>>> the INVITE request contains a "rkeep" parameter with a parameter >>>> value which is different from the value in the request (counting a >>>> "rkeep" parameter without a value) it is seen as an indication that >>>> the adjacent downstream SIP entity is willing to send keep-alives >>>> associated with the dialog on which the response is received. >>>> >>>> What happens in the presence of forking? >>>> >>>> If the request is forked downstream from the node requesting >> keepalives, including if the neighbor does the forking, there can be >> responses in different early dialogs. But all of them will traverse >> the same neighbor who will be doing>the keepalives. So, does this rule >> apply across all the different dialogs? Or must the response >> indication be separate for each? >>> >>> I guess it would be good to indicate the willingess to send >> keep-alives for each dialog, as dialogs have different lifetime. >> However, I see no need to start sending keep-alive instances for each >> dialog, as they are sent to the same entity. >> >> I just think you need to discuss it. >> Once you have something down about it there may be a number of people >> with opinions about it. > > I see this text: > > A SIP entity MUST NOT indicates willingness to send/receive keep-alives > associated with a dialog, unless it has also inserted itself in the > dialog route set [RFC3261]. > > So the sending/receiving of keepalives is bound to a dialog. That makes > sense, as the end of the dialog determines when the keepalives stop. > (BTW, does the draft state that explicitly?) > > If a request forks further downstream, the entity is Record-Routed into > all of the forks, but of course, each fork has a different lifetime. > > It sounds like you want to say that all of the dialogs form a group, and > the group can be "kept alive" by only one sequence of keepalives, but > the sequence of keepalives must be maintained as long as any dialog in > the group exists. > > BTW, does the mechanism ensure that the negotiated keepalive interval is > the same for all forks? Good question. For an INVITE, the downstream neighbor forbidden from giving different answers to different responses to the INVITE. I guess that is intended to apply to responses from multiple early dialogs. So I guess it does mean it is the same for all dialogs. >>>> Maybe we can find another way to accomplish that. Perhaps something >> extra in the request, in addition to the interval, that can be removed >> in the response. E.g.: >>>> >>>> Request Positive Response Negative Response >>>> rkeep=5:desired rkeep=5, rkeep=5:desired >>>> or rkeep=10 or rkeep >>>> >>>> If that's too verbose, how about "rkeep=5?" >>> >>> I guess there are many ways how it could be done. I just thought the >> currently suggested one was a simple one, without the need for >> additional parameters etc. >> >> I'd like to have some other opinions on this. >> It's really a matter of taste. It can work as it is. >> As I say, to me it just seems weird and possibly something that people >> will misunderstand and implement wrong. > > At the least, it must be possible to examine a SIP message in isolation > and determine the meaning of the rkeep parameter without any further > context. From the chart above, it appears that the current definition > has that property. The chart above is mine, and is for a postulated change to the draft. As the draft is currently written the corresponding chart would be: Request Positive Response Negative Response rkeep=5 rkeep rkeep=5 or rkeep=10 rkeep rkeep=5 rkeep or rkeep=10 So, you can examine a request/response *pair* and determine the meaning of the parameter. But you can't examine a *response* in isolation and determine the meaning. Of course, even with the change you can't do that, because the value doesn't need to be in all responses. Thanks, Paul > However the situation does seem to be confusing. You should have a > summary in the draft much like the above chart. Better, once you have > written the chart, people can discuss whether they would like to adjust > the syntax. > > Dale > From adam@nostrum.com Fri Jul 27 11:23:47 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 D176311E8096 for ; Fri, 27 Jul 2012 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDGcxTtCohE8 for ; Fri, 27 Jul 2012 11:23:47 -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 AE48411E808C for ; Fri, 27 Jul 2012 11:23:43 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6RINWag047434 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 27 Jul 2012 13:23:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5012DCA3.8000502@nostrum.com> Date: Fri, 27 Jul 2012 13:23:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Paul Kyzivat References: <5011BF18.3050706@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> <5011E301.5020604@alum.mit.edu> In-Reply-To: <5011E301.5020604@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 27 Jul 2012 18:23:47 -0000 On 7/26/12 19:38, Jul 26, Paul Kyzivat wrote: > Feel free to use frequency rather than interval. But then the units > can't be seconds. They then need to be keepalives-per-second. Or "Hertz." ;-) /a From dworley@avaya.com Fri Jul 27 11:41:08 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 8B64821F8658 for ; Fri, 27 Jul 2012 11:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK9TqL6LTAoe for ; Fri, 27 Jul 2012 11:41:08 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 42BB521F8655 for ; Fri, 27 Jul 2012 11:41:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJffElDGmAcF/2dsb2JhbABFDoVjsmB/gQeCIAEBAQEDEhERRRACAQgNCwICJgICAjAVEAEBBA4NGodrnUCKHpNBgSGQETJgA5tFihCCJlU X-IronPort-AV: E=Sophos;i="4.77,668,1336363200"; d="scan'208";a="19969051" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Jul 2012 14:35:53 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jul 2012 14:36:52 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 27 Jul 2012 14:41:03 -0400 From: "Worley, Dale R (Dale)" To: "pkyzivat@alum.mit.edu" Date: Fri, 27 Jul 2012 14:41:03 -0400 Thread-Topic: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 Thread-Index: Ac1sJ2BH8UtqDXQ7Q7i4VA6sbMpSGQ== Message-ID: References: <5011BF18.3050706@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DD2@ESESSCMS0356.eemea.ericsson.se> <5011E301.5020604@alum.mit.edu> <5012DAF1.2050909@alum.mit.edu> In-Reply-To: <5012DAF1.2050909@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-holmberg-sipcore-rkeep-00 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, 27 Jul 2012 18:41:08 -0000 T24gRnJpLCAyMDEyLTA3LTI3IGF0IDE0OjE2IC0wNDAwLCBQYXVsIEt5eml2YXQgd3JvdGU6Cj4g QXMgdGhlIGRyYWZ0IGlzIGN1cnJlbnRseSB3cml0dGVuIHRoZSBjb3JyZXNwb25kaW5nIGNoYXJ0 IHdvdWxkIGJlOgo+IAo+IAlSZXF1ZXN0CSAgICAgICAgIFBvc2l0aXZlIFJlc3BvbnNlICBOZWdh dGl2ZSBSZXNwb25zZQo+IAlya2VlcD01ICAgICAgICAgIHJrZWVwICAgICAgICAgICAgICBya2Vl cD01Cj4gCSAgICAgICAgICAgICAgICAgb3IgcmtlZXA9MTAKPiAKPiAJcmtlZXAgICAgICAgICAg ICBya2VlcD01ICAgICAgICAgICAgcmtlZXAKPiAJCQkgb3IgcmtlZXA9MTAKPiAKPiBTbywgeW91 IGNhbiBleGFtaW5lIGEgcmVxdWVzdC9yZXNwb25zZSAqcGFpciogYW5kIGRldGVybWluZSB0aGUg bWVhbmluZyAKPiBvZiB0aGUgcGFyYW1ldGVyLiBCdXQgeW91IGNhbid0IGV4YW1pbmUgYSAqcmVz cG9uc2UqIGluIGlzb2xhdGlvbiBhbmQgCj4gZGV0ZXJtaW5lIHRoZSBtZWFuaW5nLgoKQXMgc29t ZW9uZSB3aG8gaGFzIHNwZW50IGEgbG90IG9mIHRpbWUgbG9va2luZyBhdCBTSVAgdHJhY2VzLCBJ IGFkdmlzZQp0aGF0IHdlIGRvIG5vdCBkZWZpbmUgYSBtZWNoYW5pc20gaW4gd2hpY2ggInJrZWVw IiBpcyBlaXRoZXIgYSBwb3NpdGl2ZQpvciBhIG5lZ2F0aXZlIHJlc3BvbnNlLCBkZXBlbmRpbmcg b24gd2hhdCB0aGUgbWF0Y2hpbmcgcmVxdWVzdCBpcy4KSW5kZWVkLCB0aGVyZSBhcmUgY2FzZXMg d2hlcmUgb25lIGNhbiBzZWUgdGhlIHJlc3BvbnNlIGJ1dCBub3QgdGhlCnJlcXVlc3QuLi4KCkRh bGUKCg== From christer.holmberg@ericsson.com Fri Jul 27 12:56:51 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 55C5021F86B6 for ; Fri, 27 Jul 2012 12:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf15Nqr2wZfG for ; Fri, 27 Jul 2012 12:56:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEEA21F86B3 for ; Fri, 27 Jul 2012 12:56:50 -0700 (PDT) X-AuditID: c1b4fb25-b7fb66d000003bb6-1e-5012f28060ef Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1B.67.15286.082F2105; Fri, 27 Jul 2012 21:56:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 27 Jul 2012 21:56:48 +0200 From: Christer Holmberg To: SIPCORE Date: Fri, 27 Jul 2012 21:56:48 +0200 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments Thread-Index: Ac1qdJGiGom5ZbkgQeSmh+Z2qkIM3wAAnIbgAG6A8uA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086D4DD8@ESESSCMS0356.eemea.ericsson.se> References: <20120614102909.28244.52115.idtracker@ietfa.amsl.com> <7F2072F1E0DE894DA4B517B93C6A058534071B9925@ESESSCMS0356.eemea.ericsson.se> <5010073D.5020605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534086D4DCC@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534086D4DCC@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrW7DJ6EAg+/HrC2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFu7PrAXLOesuHNkNWMD40T2LkZODgkBE4lzfYegbDGJC/fW s3UxcnEICZxilHjbu5cZwlnAKHGk/xOQw8HBJmAh0f1PG8QUEZCTmH0jBqSXRUBV4tvp18wg trBAvMSpZ7NYIUoSJM60GYOERQSsJI5OnQ0W5hUIl5jUrAgx/DKTRMeUGewgcU6BCIkLU6pB yhmBrvl+ag0TiM0sIC5x68l8JogrBSSW7DnPDGGLSrx8/I8Vol5U4k77ekaIeh2JBbs/sUHY 2hLLFkJcxisgKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/T K07dxAiMhINbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GM1u7vv8cXEBd8tSy21sL7+2ln47tVr+7KWEOVmvzn76dmWbxFtu/vg5y7sesO8/vuN6smVb Z5mZ5KWrG66mHO8085LgNSwN9Wb20Tvjo/5n5XaT5tYaXvlLE+Uf1Taq9v8tv7qhvlB2cqX5 N7MHP44q10WEZ4UlvZlw9V3Qr/1MZmXh+TM3HFZiKc5INNRiLipOBAD3YlwSUgIAAA== Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-04.txt - Keith's comments 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, 27 Jul 2012 19:56:51 -0000 =20 Hi, I am suggesting to address Keith's issue #10, regarding the IANA SIP header= field parameter table (see below), by adding the Feature-Caps header field= to the table in the following way: Header Field Parameter Name Predefined Values Reference ---------------------------------------------------------------- Feature-Caps * No [xxx] * denotes parameter names conforming to the syntax defined in [xxx]. Valid feature-cap are registered in [reference to the new feature-cap registries]. Keith has indicated off-line that he is ok with this addition, but if anyon= e has an issue with this proposal, please let me know asap. Thanks! Regards, Christer Keith's original comment: "10) Is " feature-cap" in the ABNF formally a header field parameter in = the manner it is defined? As such should it have some representation in the= header field parameters table? I agree this is presumably covered in full detail by the other IANA regi= strations, but surely there should be at least a pointer in the header fiel= d parameters table." From internet-drafts@ietf.org Mon Jul 30 04:16:45 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 5C8EA21F8738; Mon, 30 Jul 2012 04:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY-ND-VOuMuW; Mon, 30 Jul 2012 04:16:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D896321F86A1; Mon, 30 Jul 2012 04:16:44 -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.32 Message-ID: <20120730111644.24136.80067.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 04:16:44 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-02.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: Mon, 30 Jul 2012 11:16:45 -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-02.txt Pages : 20 Date : 2012-07-30 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Mon Jul 30 04:24:59 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 433EA21F8443 for ; Mon, 30 Jul 2012 04:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOHRUdWd88dE for ; Mon, 30 Jul 2012 04:24:58 -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 6F21621F874C for ; Mon, 30 Jul 2012 04:24:57 -0700 (PDT) Received: by lagv3 with SMTP id v3so3466251lag.31 for ; Mon, 30 Jul 2012 04:24:56 -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 :content-type:content-transfer-encoding:x-gm-message-state; bh=Qc5q1pGLHAQ0APtGtXboDmqWlmS3Vxfk8Z6YqNAadP4=; b=a19PFS3X6ye4LFMW8StEO5+3NhfXhCFxlVYoalganMYh3NRj5uiyCN2IsA2xpY6VFf VvHMy1KlaNCixn/GpPlUFzQDJ4AP6C7aeyt+qG9hB7ZBw2/kmGmx3B0l2LAM3QLUz5fe nrkyYlKesaOp1WovM5sGT4wV3zlmXlVc34pZcUeiW2o/qy4H5xmSQmEKHxHFYcqfxjjN ZnOyQQRD6tv9nnXAQZzOfEpwC9Ls+GEX67kVb24gHB3GjGLZ9+yeD4DeFqAKT/lEgowT ZhI9vq1pezkNYBfwomPu/qcBkbTFQ6i77gchF/GCsgaZJ7cYwPld4rr0Sb8kAUaxOMmj BWFA== Received: by 10.112.42.228 with SMTP id r4mr5027596lbl.4.1343647496779; Mon, 30 Jul 2012 04:24:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Mon, 30 Jul 2012 04:24:36 -0700 (PDT) In-Reply-To: <20120730111644.24136.80067.idtracker@ietfa.amsl.com> References: <20120730111644.24136.80067.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 30 Jul 2012 13:24:36 +0200 Message-ID: To: sipcore@ietf.org, SIPCORE Chairs Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm+dDDNKpWy3l9FR+3/0xuxu5bnkUmd48yCwrvqzB2ssZIaOFaBBTSoFQ94gxmqZdaWFwUP Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-02.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: Mon, 30 Jul 2012 11:24:59 -0000 2012/7/30 : > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core Workin= g Group of the IETF. > > Title : The WebSocket Protocol as a Transport for the S= ession Initiation Protocol (SIP) > Author(s) : Inaki Baz Castillo > Jose Luis Millan Villegas > Victor Pascual > Filename : draft-ietf-sipcore-sip-websocket-02.txt > Pages : 20 > Date : 2012-07-30 Hi all, this new version of the draft contains the folowing changes: - Registration of new Via and SIP URI transports (within "IANA Considerations" section) has been removed since IANA does not manage a registry for those values (thanks to Kevin P. Fleming for pointing it out). - Full grammatical review by Kevin P. Fleming. The authors of the draft consider that there are no open issues at this time. As always, comments are welcome. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Jul 31 11:13: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 1ADEB21F8888 for ; Tue, 31 Jul 2012 11:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+F+spRqqKv9 for ; Tue, 31 Jul 2012 11:13:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7B321F8883 for ; Tue, 31 Jul 2012 11:13:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-34-50182051ed4b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 88.93.07365.15028105; Tue, 31 Jul 2012 20:13:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 31 Jul 2012 20:13:37 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Tue, 31 Jul 2012 20:13:36 +0200 Thread-Topic: Proxy-Feature: Keith's issue (#3) on name of capability indicator Thread-Index: Ac1KGJGLQT3zSVQSQKSlisOumDNZiAFnKsVAB+SDUeA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086D4DDF@ESESSCMS0356.eemea.ericsson.se> References: <20120614102909.28244.52115.idtracker@ietfa.amsl.com> In-Reply-To: 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+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrW6ggkSAQeNZeYunjWcZLb7+2MTm wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDI+z2lgLrjLUrHs1GS2BsYbzF2MnBwSAiYS Sw50MkHYYhIX7q1n62Lk4hASOMUo0fX8FAuEs4BR4umvJ0AOBwebgIVE9z9tkAYRAU2J5d+2 soOEmQVsJc6eEAEJswioSuzZco8FxBYW8JJo3jSHBaI8UKJh6TU2CNtKYuvpY4wgNq9AuMSd zm3MEKumMkrsO7+eFSTBKRAnseTda7DjGIGO+35qDZjNLCAucevJfKijBSSW7DkP9YyoxMvH /1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMDYObjlt+4OxlPnRA4xSnOwKInzciXt9xcSSE8s Sc1OTS1ILYovKs1JLT7EyMTBKdXAKH22/6THxDy++7xLl/Up61ss3nv+5zbeNztjvC7yq2k0 87wJM/njv2Vm31/Z8A4mu+9Nc9b/XWmo11GhE2wmrJ5yYqrR58o0a+P/6tUVZQXhKlm1S7r+ +J6xqng78T2rVvkKedE5SRtjgtfO1WV5zd7HztLE9flX0Oq0ZeGfpELO7otk2cisxFKckWio xVxUnAgAWK5hUGsCAAA= Subject: [sipcore] Proxy-Feature: Keith's issue (#3) on name of capability indicator 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, 31 Jul 2012 18:13:39 -0000 Hi, Based on discussions with Keith, I suggest to change the naming of the capa= bility indcators in the draft, so that we use full naming and talk about "f= eature capabilities" instead of "feature caps". The header field name will still remain the same, amd the change will not c= hange the ABNF, or what is sent "on the wire". If anyone has an issue with this proposal, please let me know asap. Regards, Christer Keith's original comment: "3) Can we use "feature capabilities" rather than "feature caps" except wh= en we are referring to the header field or tag coding."