From christer.holmberg@ericsson.com Thu Oct 1 01:33:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5C73A6AA6 for ; Thu, 1 Oct 2009 01:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJhdMFpsXe8P for ; Thu, 1 Oct 2009 01:33:15 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 73C583A6A9D for ; Thu, 1 Oct 2009 01:33:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7b63ae0000049dc-92-4ac4699d3002 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 38.F2.18908.D9964CA4; Thu, 1 Oct 2009 10:34:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 10:34:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Oct 2009 10:33:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) Thread-Index: AcpAuDWJ93hau7FURsS5/sZSUfvQOABubPqH References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> From: "Christer Holmberg" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 01 Oct 2009 08:34:23.0431 (UTC) FILETIME=[FA76D570:01CA4271] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 08:33:16 -0000 When would this RUPDATE be sent? =20 Could you provide an example call flow, please. =20 Regards, =20 Christer ________________________________ From: sipcore-bounces@ietf.org on behalf of Dean Willis Sent: Tue 9/29/2009 5:50 AM To: Paul Kyzivat Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is = anAoR?) On Sep 28, 2009, at 7:41 PM, Paul Kyzivat wrote: > Dean, > > IIUC you have just reinvented Jonathan's loose routing registration=20 > proposal. > > =20 Well, I'm trying to take a slightly different approach to it,=20 primarily by applying it to the wildcard registration problem. I think=20 I've also eliminated all the guesswork on subcases, making proxy=20 behavior arguably more deterministic than it might have been in=20 Jonathan's original proposal. And the questionable usage of Supported=20 and Requires for negotiation is right out. There's also no need for=20 confusing discussion of GRUU minting in the UA. The cleanest approach, in my current humble opinion (IMCHO), is to add=20 a new SIP method that registers a route (or maybe multiple routes)"=20 instead of registering a contact. We might think of this as analogous=20 to BGP UPDATE route advertisements. I propose the RUPDATE method name=20 for SIP. So, IIUC, I'd say "reprised" rather than "reinvented". But yeah, it=20 owes a lot to JDR's work on ua-loose-route. Any benefit we get in terms of parameter delivery, retention of URI's=20 etc. is actually just side-effect from cleaning up the semantic model=20 of message routing. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Thu Oct 1 04:35:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D6A28C10D for ; Thu, 1 Oct 2009 04:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfXLtKOw19ZS for ; Thu, 1 Oct 2009 04:35:34 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.62.20]) by core3.amsl.com (Postfix) with SMTP id A85B03A6A19 for ; Thu, 1 Oct 2009 04:35:34 -0700 (PDT) Received: (qmail 4520 invoked from network); 1 Oct 2009 11:46:39 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway02.websitewelcome.com with SMTP; 1 Oct 2009 11:46:39 -0000 Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:53514 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1MtJxx-000184-N6; Thu, 01 Oct 2009 06:36:58 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Shida Schubert In-Reply-To: Date: Thu, 1 Oct 2009 20:36:55 +0900 Content-Transfer-Encoding: 7bit Message-Id: <4DC1FBFD-2D4D-44C2-9A4A-BB4B42FE34D6@ntt-at.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> To: Christer Holmberg X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 11:35:35 -0000 I am really not sure why we are even discussing this. I believe it was because toll-free number or any other service invocation uri(sos/directory assistance) is hard to determine at the UAS because they can be buried in the number of h-i entries with 'mp' tag and is not distinguishable from any other retargets.. But in reality at least the way things are deployed as of now and probably for some time in the future, whether it's freedial, emergency call or directory assistance, the translation entity clearly knows the semantics of the translation (that it's a route and not a contact) thus would be able to label them as toll-free, emergency call, directory assistance and such if there was a way to label a URI with such semantics in RFC4244.. Regards Shida On Oct 1, 2009, at 5:33 PM, Christer Holmberg wrote: > When would this RUPDATE be sent? > > Could you provide an example call flow, please. > > Regards, > > Christer > > ________________________________ > > From: sipcore-bounces@ietf.org on behalf of Dean Willis > Sent: Tue 9/29/2009 5:50 AM > To: Paul Kyzivat > Cc: SIPCORE > Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what > is anAoR?) > > > > > On Sep 28, 2009, at 7:41 PM, Paul Kyzivat wrote: > >> Dean, >> >> IIUC you have just reinvented Jonathan's loose routing registration >> proposal. >> >> > > Well, I'm trying to take a slightly different approach to it, > primarily by applying it to the wildcard registration problem. I think > I've also eliminated all the guesswork on subcases, making proxy > behavior arguably more deterministic than it might have been in > Jonathan's original proposal. And the questionable usage of Supported > and Requires for negotiation is right out. There's also no need for > confusing discussion of GRUU minting in the UA. > > The cleanest approach, in my current humble opinion (IMCHO), is to add > a new SIP method that registers a route (or maybe multiple routes)" > instead of registering a contact. We might think of this as analogous > to BGP UPDATE route advertisements. I propose the RUPDATE method name > for SIP. > > So, IIUC, I'd say "reprised" rather than "reinvented". But yeah, it > owes a lot to JDR's work on ua-loose-route. > > Any benefit we get in terms of parameter delivery, retention of URI's > etc. is actually just side-effect from cleaning up the semantic model > of message routing. > > > -- > Dean > _______________________________________________ > 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 richard@shockey.us Thu Oct 1 08:47:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E263A6AA4 for ; Thu, 1 Oct 2009 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULqI-57i3n3R for ; Thu, 1 Oct 2009 08:47:25 -0700 (PDT) Received: from outbound-mail-107.bluehost.com (outbound-mail-107.bluehost.com [69.89.22.7]) by core3.amsl.com (Postfix) with SMTP id 200FE3A6AA0 for ; Thu, 1 Oct 2009 08:47:25 -0700 (PDT) Received: (qmail 21990 invoked by uid 0); 1 Oct 2009 15:48:50 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 1 Oct 2009 15:48:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=BJNHKQ/mrgri8x0OCPQEBFQVs28Bz/7GNYeHH67+K8wO5x2pr+5Shh+oJXw2/YA2fmIHIYEDzNIDuIMus52+/oKNIQsU08fTfDUifsTcFPn85jCclp0CkRUE1g1EnS6X; Received: from pool-96-255-226-99.washdc.fios.verizon.net ([96.255.226.99] helo=rshockeyPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MtNti-0000Et-4k; Thu, 01 Oct 2009 09:48:50 -0600 From: "Richard Shockey" To: "'DOLLY, MARTIN C, ATTLABS'" , , References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AAD@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4AAD@gaalpa1msgusr7e.ugd.att.com> Date: Thu, 1 Oct 2009 11:48:44 -0400 Message-ID: <00cd01ca42ae$a8e875f0$fab961d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpAdCIytTVxLGoWQDuPf2S7KFa2DQABemzXAIz3n0A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.99 authed with richard+shockey.us} Cc: sipcore@ietf.org Subject: Re: [sipcore] (Info event) Questions aboutWillingnessandCapabilitynegotiation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:47:26 -0000 ??? Why Marty? The device layer is one thing but, there is a desperate need for a configuration model between edge SIP-PBX's and SSP networks. This is a major inhibitor to plug and play services in the marketplace and it needs to get fixed and Dean's suggestion about a straight forward HTTP/XML model is spot on. There will be more on this topic once Hadriel can publish is draft on Domain Registration. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of DOLLY, MARTIN C, ATTLABS > Sent: Monday, September 28, 2009 4:27 PM > To: dean.willis@softarmor.com; tianlinyi@huawei.com > Cc: sipcore@ietf.org > Subject: Re: [sipcore] (Info event) Questions > aboutWillingnessandCapabilitynegotiation > > Neither will be deployed > > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Linyi TIAN > Cc: 'SIPCORE' > Sent: Mon Sep 28 15:44:06 2009 > Subject: Re: [sipcore] (Info event) Questions > aboutWillingnessandCapabilitynegotiation > > > On Sep 28, 2009, at 3:11 AM, Linyi TIAN wrote: > > >> > >> You CAN NOT use the I-P mechanism to negotiate what you are going > >> to send > > in a 200 > >> OK response. > > > > [Linyi TIAN] I never said I will use I-P to do this. > > > > I mean for this administration feature we may not use this I-D at > > all if > > Recv-Info is mandated. So please read my question again: > > > >> [Linyi TIAN] Hard coded is one way. For this configuration feature, > >> is SIP > >> INFO framework the best mechanism to be used? Is there any other > >> alternatives? > > > > > > I'm guessing from my weak understanding of the proposal that either > the SIP configuration framework or session policy framework might be > closer to meeting your goals than an INFO package would be. > > See: > > http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15 > > http://tools.ietf.org/html/draft-ietf-sip-session-policy-framework-06 > > > Specifically, if you are talking about a timer that is valid only for > the current INVITE-initiated session, then the session-associated > policy part of the session-policy draft would be most likely to be > fruitful. > > If the timer is persistent across multiple sessions, then INFO would > be completely wrong, and either the session-independent policy model > of the session-policy draft might work, or the configuration > framework. > > Or you could do what IETF and 3GPP probably should have done all > along, which is to develop a straightforward HTTP/XML configuration > model for SIP devices. > > -- > Dean > > _______________________________________________ > 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 dean.willis@softarmor.com Thu Oct 1 22:50:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978773A69EB for ; Thu, 1 Oct 2009 22:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Gt0NXLvcTZ for ; Thu, 1 Oct 2009 22:50:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 66BA93A6973 for ; Thu, 1 Oct 2009 22:50:28 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n925pNAQ013492; Fri, 2 Oct 2009 00:51:23 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 2 Oct 2009 05:51:24 -0000 (UTC) Message-ID: <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> In-Reply-To: References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> Date: Fri, 2 Oct 2009 05:51:24 -0000 (UTC) From: "Dean Willis" To: "Christer Holmberg" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:50:29 -0000 On Thu, October 1, 2009 3:33 am, Christer Holmberg wrote: > When would this RUPDATE be sent? > > Could you provide an example call flow, please. > The PBX pbx1.example.org uses a service provider proxy spp.example.com. So does pbx2.example.org. pbx1 handles the engineering.example.org and science.example.org domains, as well as phone number 888-555-0000 through 888-555-6999. pbx2 explicitly handles the marketing.example.org subdomain and 888-555-7000 through 888-555-7999. Further, it acts as a backup route for anything in example.org and 888-555-0000 through 888-555-9999. So on bootup, and periodically thereafter, pbx1.example,org would send to spp.example.com a RUPDATE (or set of RUPDATES, depending on how we define the message) adverting that pbx1.example.org handles: *.engineering.example.org at priority X, *.science.example.org at priority X, 8885550* at priority X, 8885551??? at priority X, 8885552??? at priority X, 8885553??? at priority X, 8885554??? at priority X, 8885555??? at priority X, 8885556??? at priority X Likewise, pbx2 would send rupdates for *.marketing.example.org at priority X *8885557??? at priority X *.example.org at priority Y (where Y has lower precedence than X) 888555???? at priority Y (where Y has lower precedence than X) Clearly we also need some sort of policy language that allows spp.example.org to decide what things each of these PBXes is authorized to update. Our existing authentication techniques should suffice for authentication. -- Dean From dean.willis@softarmor.com Thu Oct 1 22:52:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA3B3A69F6 for ; Thu, 1 Oct 2009 22:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xwebZx1YNFx for ; Thu, 1 Oct 2009 22:52:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 628733A6973 for ; Thu, 1 Oct 2009 22:52:18 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n925rcBC013548; Fri, 2 Oct 2009 00:53:38 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 2 Oct 2009 05:53:39 -0000 (UTC) Message-ID: In-Reply-To: <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> References: <4A5FAF4E.4030901@cisco.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> Date: Fri, 2 Oct 2009 05:53:39 -0000 (UTC) From: "Dean Willis" To: "Dean Willis" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:52:20 -0000 On Fri, October 2, 2009 5:51 am, Dean Willis wrote: > On Thu, October 1, 2009 3:33 am, Christer Holmberg wrote: >> When would this RUPDATE be sent? >> >> Could you provide an example call flow, please. >> > > The PBX pbx1.example.org uses a service provider proxy spp.example.com. So > does pbx2.example.org. > > pbx1 handles the engineering.example.org and science.example.org domains, > as well as phone number 888-555-0000 through 888-555-6999. > > pbx2 explicitly handles the marketing.example.org subdomain and > 888-555-7000 through 888-555-7999. Further, it acts as a backup route for > anything in example.org and 888-555-0000 through 888-555-9999. > > So on bootup, and periodically thereafter, pbx1.example,org would send to > spp.example.com a RUPDATE (or set of RUPDATES, depending on how we define > the message) adverting that pbx1.example.org handles: > *.engineering.example.org at priority X, > *.science.example.org at priority X, > 8885550* at priority X, Ok, that should have been 8885550??? above . . . > 8885551??? at priority X, > 8885552??? at priority X, > 8885553??? at priority X, > 8885554??? at priority X, > 8885555??? at priority X, > 8885556??? at priority X > > Likewise, pbx2 would send rupdates for > *.marketing.example.org at priority X > *8885557??? at priority X > *.example.org at priority Y (where Y has lower precedence than X) > 888555???? at priority Y (where Y has lower precedence than X) > > > Clearly we also need some sort of policy language that allows > spp.example.org to decide what things each of these PBXes is authorized to > update. Our existing authentication techniques should suffice for > authentication. > > -- > Dean > > > From pkyzivat@cisco.com Fri Oct 2 06:11:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D0D28B797 for ; Fri, 2 Oct 2009 06:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-4j4i4wO1F3 for ; Fri, 2 Oct 2009 06:11:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AC04928C103 for ; Fri, 2 Oct 2009 06:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2068; q=dns/txt; s=sjiport06001; t=1254489203; x=1255698803; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20Route=20registration=20(was=20Re:=20 rfc4244bis:=20what=20is=20=20=20=0D=0A=20=20=20anAoR?) |Date:=20Fri,=2002=20Oct=202009=2009:13:29=20-0400 |Message-ID:=20<4AC5FC79.4080301@cisco.com>|To:=20Dean=20 Willis=20|CC:=20Christer=20Hol mberg=20,=0D=0A=20=20=20 =20=20=20=20=20SIPCORE=20|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< 30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.c om>|References:=20<4A5FAF4E.4030901@cisco.com>=20=20=20 =20<1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.cor p.nortel.com>=20=20=20=20<7402509E63C5A145A6095D46C179A5B 705C6D11D@DEMCHP99E35MSX.ww902.siemens.net>=20=20=20=20<1 ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nor tel.com>=20=20=20=20<7402509E63C5A145A6095D46C179A5B705C6 D1E0@DEMCHP99E35MSX.ww902.siemens.net>=20=20=20=20<1ECE0E B50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.c om>=20=20=20=20<9ae56b1e0909241127k6ec043a7vcdec27bf81bfa 9c@mail.gmail.com>=20=20=20=20<1ECE0EB50388174790F9694F77 522CCF203EF111@zrc2hxm0.corp.nortel.com>=20=20=20=20<9ae5 6b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> =20=20=20=20<7402509E63C5A145A6095D46C179A5B705C6D3BC@DEM CHP99E35MSX.ww902.siemens.net>=20=20=20=20<0BC1DC5A-1613- 4B06-AFF9-8BDD3CDE57C3@greycouncil.com>=20=20=20=20<4AC15 79E.3090307@cisco.com>=20=20=20=20=20=20=20=20 =20<30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarm or.com>; bh=RZ2ZDb4EgjT/jAuN5cZkKTDt7UToMmWEkpW0eRPFNyE=; b=LnjtG8cwCcr2Cc45tOOXz4en7dr75mww9xT7e04C8wCoL0i/KfueMToE +rZKYy7ZJCAAE70HOAuJf6d/mPr3m8dKVYmQh86E60JZ/Q6UlsWXbnIA7 0rCWmpCkgD5UXjLbJLlBsUDHOTDSugHscbtd5goCvwTjjFGhhwETd2Zgq 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (signature verified [TEST]) header.i=pkyzivat@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALOZxUqrR7PD/2dsb2JhbAC/VYhbATIJjm0GgkuBYYFW X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="400772355" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2009 13:13:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n92DDNie028990; Fri, 2 Oct 2009 06:13:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n92DDMH1006894; Fri, 2 Oct 2009 13:13:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 09:13:22 -0400 Received: from [161.44.182.204] ([161.44.182.204]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 09:13:21 -0400 Message-ID: <4AC5FC79.4080301@cisco.com> Date: Fri, 02 Oct 2009 09:13:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> In-Reply-To: <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2009 13:13:21.0840 (UTC) FILETIME=[1DBF1B00:01CA4362] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2068; t=1254489203; x=1255353203; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Route=20registration=20(was =20Re=3A=20rfc4244bis=3A=20what=20is=20=20=20=0A=20=20=20anA oR?) |Sender:=20; bh=RZ2ZDb4EgjT/jAuN5cZkKTDt7UToMmWEkpW0eRPFNyE=; b=qPAmEfyMoe5AqiAL/KIxvYyehWKnV4Sa12ykxl0gU2QC7rujklZf0oIkcz 4e4JO/CjV16atdWafIGPn0H5FS03TCMHkNhqZBIGgQK+oDMY5m+CeJbhSkA5 pYPaOyZlax; Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 13:11:57 -0000 Dean, So, RUPDATE is really just what REGISTER should have been: providing a route for reaching something responsible for a given AOR. In principle it could *replace* REGISTER for any devices that were clued in to its use. You give examples with phone numbers, but those provide unmentioned issues. Most notably, how you choose where to send the RUPDATE for the number. Thanks, Paul Dean Willis wrote: > On Thu, October 1, 2009 3:33 am, Christer Holmberg wrote: >> When would this RUPDATE be sent? >> >> Could you provide an example call flow, please. >> > > The PBX pbx1.example.org uses a service provider proxy spp.example.com. So > does pbx2.example.org. > > pbx1 handles the engineering.example.org and science.example.org domains, > as well as phone number 888-555-0000 through 888-555-6999. > > pbx2 explicitly handles the marketing.example.org subdomain and > 888-555-7000 through 888-555-7999. Further, it acts as a backup route for > anything in example.org and 888-555-0000 through 888-555-9999. > > So on bootup, and periodically thereafter, pbx1.example,org would send to > spp.example.com a RUPDATE (or set of RUPDATES, depending on how we define > the message) adverting that pbx1.example.org handles: > *.engineering.example.org at priority X, > *.science.example.org at priority X, > 8885550* at priority X, > 8885551??? at priority X, > 8885552??? at priority X, > 8885553??? at priority X, > 8885554??? at priority X, > 8885555??? at priority X, > 8885556??? at priority X > > Likewise, pbx2 would send rupdates for > *.marketing.example.org at priority X > *8885557??? at priority X > *.example.org at priority Y (where Y has lower precedence than X) > 888555???? at priority Y (where Y has lower precedence than X) > > > Clearly we also need some sort of policy language that allows > spp.example.org to decide what things each of these PBXes is authorized to > update. Our existing authentication techniques should suffice for > authentication. > > -- > Dean > > > From dworley@nortel.com Fri Oct 2 14:43:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A9E3A69E5 for ; Fri, 2 Oct 2009 14:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D53ChRLqbrJN for ; Fri, 2 Oct 2009 14:43:47 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 685BC3A68BE for ; Fri, 2 Oct 2009 14:43:47 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n92LigJ21727; Fri, 2 Oct 2009 21:44:42 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 17:44:41 -0400 From: "Dale Worley" To: "DRAGE, Keith (Keith)" In-Reply-To: References: <4A85C195.4060903@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 02 Oct 2009 17:44:40 -0400 Message-Id: <1254519880.3767.33.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2009 21:44:41.0722 (UTC) FILETIME=[8C6195A0:01CA43A9] Cc: Ian Elz , "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 21:43:48 -0000 In regard to the fact that a proxy (that wishes to remain in the signaling path) must Record-Route all SUBSCRIBEs without to-tags, and all NOTIFYs: On Tue, 2009-08-18 at 15:24 +0200, DRAGE, Keith (Keith) wrote: > Christer wrote > > > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, > > but that doesn't mean it will Record-Route the NOTIFY. It may > > simply be configured to Record-Route all dialog initiation requests. > > > > It can only do this if it understands that SUBSCRIBE is a dialog > initiation request, and it can only do this if it implements either > RFC 3265 or 3265bis. > > As I understood it, the behaviour described by Adam is already in RFC > 3265, and therefore it is a non-conformant implementation of RFC 3265 > if it does something difference. Some years ago, I was in a long discussion about how SUBSCRIBE/NOTIFY need to be record-routed, especially in the context of non-dialog-stateful proxies. Unfortunately, nobody in the conversation recalled section 3.1.5 of RFC 3265, but we came to the conclusion that in order for subscriptions to work *in practice*, a non-dialog-stateful proxy must record-route SUBSCRIBEs without to-tags and all NOTIFYs, or record-route none of them. So practical demands require that any proxy in an environment that uses SUB/NOT would satisfy 3.1.5 (in almost all cases), that is *be* RFC 3265-compliant, even if it didn't *intend* to be RFC 3265-compliant. In that context, 3265bis doesn't demand any behavior from proxies that they don't (in practice) have to have already. So I think we can safely depend on them having the proper behavior. Dale From dean.willis@softarmor.com Sat Oct 3 21:00:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4991B3A67EF for ; Sat, 3 Oct 2009 21:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w24F3VZZgMww for ; Sat, 3 Oct 2009 21:00:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 767F93A67A7 for ; Sat, 3 Oct 2009 21:00:20 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9441KqJ001564; Sat, 3 Oct 2009 23:01:20 -0500 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Sat, 3 Oct 2009 23:01:20 -0500 (CDT) Message-ID: <7d59bab32201db1fae23b71336ac4a7a.squirrel@www.softarmor.com> In-Reply-To: <4AC5FC79.4080301@cisco.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <7402509E63C5A145A6095D46C179A5B705C6D3BC@DEMCHP99E35MSX.ww902.siemens.net> <0BC1DC5A-1613-4B06-AFF9-8BDD3CDE57C3@greycouncil.com> <4AC1579E.3090307@cisco.com> <30d2616f0a72b12606b786fa7a9f274f.squirrel@www.softarmor.com> <4AC5FC79.4080301@cisco.com> Date: Sat, 3 Oct 2009 23:01:20 -0500 (CDT) From: "Dean Willis" To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] Route registration (was Re: rfc4244bis: what is anAoR?) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 04:00:21 -0000 On Fri, October 2, 2009 8:13 am, Paul Kyzivat wrote: > Dean, > > So, RUPDATE is really just what REGISTER should have been: > providing a route for reaching something responsible for a given AOR. > In principle it could *replace* REGISTER for any devices that were clued > in to its use. Yes! You have it exactly. It's not "backward compatible" in that you have to understand RUPDATE to use it. But nodes that use RUPDATE instead of REGISTER can still be reached by old-style devices, so it's operationally backward compatible. > You give examples with phone numbers, but those provide unmentioned > issues. Most notably, how you choose where to send the RUPDATE for the > number. That, like who you would send a REGISTER to (or where your mail client sends SMTP submission to) is a thing that must be configured. We could always define some sort of NAPTR configuration resolution method, but that's a different working group. -- dean From jdrosen@cisco.com Sun Oct 4 12:29:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B95728C0DC for ; Sun, 4 Oct 2009 12:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxtgnCRw0JD for ; Sun, 4 Oct 2009 12:29:19 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 44BD13A6985 for ; Sun, 4 Oct 2009 12:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jdrosen@cisco.com; l=1510; q=dns/txt; s=rtpiport01001; t=1254684652; x=1255894252; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Fixes=20in=20GRUU=20spec=20for=20alignment=20 with=20outbound|Date:=20Sun,=2004=20Oct=202009=2015:30:51 =20-0400|Message-ID:=20<4AC8F7EB.2090904@cisco.com>|To: =20sipcore@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit; bh=ZkxEqF4zdFJe9Pecq8GQCwK2XvyftD7EFAHPBUOKqBc=; b=GZp3WGXGNZjK86Q54Z154MfYQQgZp9GksfCLnkAxPijZbvBs2LVO8+MQ o64Iw5GKXetZu1WxCVY0Lr7gpHm2I7gP93uAxB4YypPOdOiq1VRnRmeU5 FgdNg7hpYkwHq+FqsvGXvWlJWIzALq8pP7IiTQpy/Wb76gfw6t1K3JdgX U=; Authentication-Results: rtp-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jdrosen@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB+UyEpAZnmf/2dsb2JhbAC4JohhATIJjRcGAoJIgWA X-IronPort-AV: E=Sophos;i="4.44,503,1249257600"; d="scan'208";a="61393569" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 04 Oct 2009 19:30:51 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n94JUpHa017584 for ; Sun, 4 Oct 2009 15:30:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n94JUpWq013654 for ; Sun, 4 Oct 2009 19:30:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 15:30:51 -0400 Received: from [10.86.253.129] ([10.86.253.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 15:30:51 -0400 Message-ID: <4AC8F7EB.2090904@cisco.com> Date: Sun, 04 Oct 2009 15:30:51 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2009 19:30:51.0627 (UTC) FILETIME=[2EE5D3B0:01CA4529] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1510; t=1254684651; x=1255548651; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Fixes=20in=20GRUU=20spec=20for=20alignment=20wi th=20outbound |Sender:=20 |To:=20sipcore@ietf.org; bh=ZkxEqF4zdFJe9Pecq8GQCwK2XvyftD7EFAHPBUOKqBc=; b=UmOUEdOV2XLQE1ow/aJTwBpzsaufHTAuz8NggKo9SM1wBFKNzOEqkFlv+Z 2/AbnbQmrqXuHPfxtzBBH5zWhAKtaqyFHp5WAbMxBR21fYD8nxFmO50S+o+w 7X0/S5gAe+; Subject: [sipcore] Fixes in GRUU spec for alignment with outbound X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 19:29:21 -0000 GRUU and outbound are about to emerge from RFC editor with their final RFC numbers. As part of this process, we (the authors) do a final round of changes to fix editorial issues or bugs found in the spec since it was last revised. I made a few such changes to GRUU and wanted to call them out: * there was a misalignment between GRUU and sip-outbound around changes in call-ID in registrations. In particular, GRUU assumed that a change in the call-ID in a registration for the same instance ID, signals a reset in the temp-gruu. However, outbound requires a different call-ID on registrations for different reg-id for the same instance-ID. Following outbound would therefore cause the registrar to invalidate all temp-gruu as registrations come from one reg-id and then the other. I fixed this in gruu by clarifying that, its a change in registration for the same instance ID, and if outbound is in use, same reg-id, that cause reset. This required touching several places in the document. * there was a bug in the BNF reported on the list some time back, which I corrected * I needed to change references from ua-loose-route to the newer target-URI document Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From dworley@nortel.com Mon Oct 5 14:07:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A1E28C24C for ; Mon, 5 Oct 2009 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m65YJ-Jnq+Q6 for ; Mon, 5 Oct 2009 14:07:46 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6616028C0F7 for ; Mon, 5 Oct 2009 14:07:46 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n95L9IB25914 for ; Mon, 5 Oct 2009 21:09:18 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 17:09:02 -0400 From: "Dale Worley" To: SIPCORE In-Reply-To: <4C1AFD39-F076-43C8-A73E-1867389C0FF8@nostrum.com> References: <72A0E3C5-322B-4FEE-B565-9659581BBFC4@nostrum.com> <4C1AFD39-F076-43C8-A73E-1867389C0FF8@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 05 Oct 2009 17:09:01 -0400 Message-Id: <1254776941.3875.59.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2009 21:09:02.0462 (UTC) FILETIME=[1085A9E0:01CA4600] Subject: Re: [sipcore] Fwd: Several questions/suggestions from my review of draft-ietf-pmol-sip-perf-metrics-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 21:07:48 -0000 On Tue, 2009-09-29 at 13:37 -0500, Robert Sparks wrote: > For those of you here who haven't been following PMOL, the group is > finishing the definition of a set > of end-to-end performance metrics for SIP. To amplify what Robert said: If you are interested in performance metrics for SIP systems, and especially if you have experience in performance metrics for SIP systems, your input in PMOL (pmol@ietf.org) would be useful. (Since I was assigned to be the RAI-ART reviewer of this draft, I've attached a copy of my review below. It lays out more questions that need further discussion.) Dale ---------------------------------------------------------------------- RAI-ART review of draft-ietf-pmol-sip-perf-metrics-04 Dale R. Worley I am the assigned RAI-ART reviewer for draft-ietf-pmol-sip-perf-metrics-04.txt. For background on RAI-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. This draft is on the right track but has open issues, described in the review. My comments are divided into groups of varying significance: - Situations where the draft appears to have omitted measurements that would be of value, and which appear to be of the same category as measurements that are included in the draft. However, this omission may have been deliberate due to the intended scope of the draft, in which case the intended limitation should be described (and perhaps justified) in the "Scope" section. - Deficiencies in the exposition of how various timing measurements are to be taken. These may also mask technical issues about how the measurements are intended to be taken. - Editorial issues, mostly involving aligning terminology with the common usage in SIP discussions. The items in these groups are numbered with discontinuous sets of numbers. Situations where the draft appears to have omitted measurements that would be of value, and which appear to be of the same category as measurements that are included in the draft. However, this omission may have been deliberate due to the intended scope of the draft, in which case the intended limitation should be described (and perhaps justified) in the "Scope" section. 100. Is the intention to restrict attention to signaling (SIP) alone? In our experience, performance problems first come to users' attention in media (RTP), and any environment with tolerable media performance has more than adequate signaling performance. 101. The measurements appear to be designed to closely parallel performance metrics of TDM telephone systems. This may be intentional, but this draft omits a number of measurements that do not closely parallel TDM performance metrics, but are nonetheless important for the performance of SIP systems, even when limiting attention to "traditional telephone" usage. (See later items for specifics.) 102. Many of the metrics appear to form natural triples: - Average delay when the operation (of a particular class) was successful. - Average delay when the operation was unsuccessful. - Percentage of operations of the class which were successful. The metrics scheme would be clarified and made more systematic if this grouping was defined as an overall property of the metric scheme and then applied as such to the various classes of operations: registration request, session request, session establishment, session disconnect, etc. E.g., although "Failed session completion delay" (average BYE-with-failure response delay) is defined, the *percentage* of failed session completions is not defined, despite that that metric should be very low in any well-functioning network, and thus can provide a valuable performance indicator. 103. Some metrics distinguish between "failure in the network" and "failure at the destination user agent"; e.g., "Session Defects Ratio". Beware that distinguishing between these two cases is very difficult and cannot easily be done by listing response codes for the two cases. (I've been developing an I-D for a couple of years on how to deal with this problem -- I have yet to devise a good solution.) It may also be desirable to apply this distinction to other operations other than initial INVITEs -- this would effectively add further metrics to the "natural triple" described in item 102, as it divides the class of failures into two sub-classes. 104. In regard to "telephone calls" (INVITE-initiated sessions), there are three metrics described (each of which gives rise to a triple of metrics): - Session request (INVITE to 180) - Session setup (INVITE to final response) - Session disconnect (BYE to final response) In addition, there is a metric for REGISTER requests. But there are a number of additional operations whose performance is important to the performance of SIP signaling, and which may differ greatly from the performance of the above operations (and for which the users' expectations may be very different from the above operations): - re-INVITEs (These are particularly important as re-INVITE is used to implement on-hold and off-hold operations, and users expect those operations to complete much quicker than initial INVITEs.) - UPDATE (if it is used in practice) - initial SUBSCRIBE (for dialog events) - re-SUBSCRIBE - NOTIFY Several metrics might be defined regarding REFER requests, which are used to implement blind and consultative transfers. In addition, MESSAGE requests can be sent either out-of-dialog or within-dialog, and one expects the performance of the two cases to be quite different, so there should be separate metrics for the two cases. 105. Similar to the problem with detecting "failure in the network", determining when session request is finished (that is, ringing starts) is difficult to specify. A 180 response is clear indication that a user has been notified, but other 18x responses may be considered as successful setup in some situations. E.g., a 182 Queued message may be considered "end of session request" if one is concerned about the performance of the network, although it does not indicate the start of useful communication from the user's point of view. 106. In regard to issues 105 and 103, it may be necessary to allow that metrics may be "parametrized" by attaching a specification of which response codes are treated as having which meaning. In any case, allowance needs to be made that experience with the metrics may show that the various specified sets of response codes need to be modified to maximize the usefulness of the metrics. Deficiencies in the exposition of how various timing measurements are to be taken. However, these may mask technical issues about how the measurements are intended to be taken. 200. Section 3 of the draft gives a nice standard for how the time from sending a request to receiving a response is to be measured ("T1 to T4"), including within it a standard for how to measure the time of sending and receiving ("first bit sent" vs. "last bit received"). However, in many places (e.g., section 4.1) these standards are not referenced, but rather they are restated. This leads the reader to have to check each metric definition to see if it is defined in the same way as described in section 3, and to wonder if all of the metrics are defined in the same way. Better would be to have section 3 note explicitly that all metrics use this definition of time delay. 201. Metrics involving INVITE should explicitly note that ACK is not considered as part of the time delay; all time delays are measured from sending the INVITE to receiving its response. Or rather, there should be an overall declaration of this standard in section 3. 202. The discussion of "Successful session duration SDT" shows some examples but does not clearly indicate how all four cases are to be handled. (The cases are the combinations of: measurement at the originating end vs. measurement at the terminating end, sending BYE vs. receiving BYE.) There is also some confusion regarding T1 and T4, which are specified in multiple different ways in this section. 203. Consideration should be made in the various definitions of calls that are timed-out by the session-timer mechanism or other session-keepalive mechanisms. (Unless it is known that the intended networks will not use session-keepalives, or that session-keepalive failures will not cause UAs to see differing signaling flows.) 204. As Robert notes, the "Hops per Request" measurement is unlikely to be useful for out-of-dialog requests, because it does not capture redirections handled by proxies and failed forks, and so is poorly correlated with the amount of work needed to deliver a request to its destination. However, this metric may be useful for in-dialog requests, as there is usually no redirection and (AFAIK) B2BUAs maintain the Max-Forwards value. Editorial issues, mostly involving aligning terminology with the common usage in SIP discussions. 300. Many of the metrics appear to be intended to report the average of a quantity that is measured for many executions of an operation. But most of these metrics do not state that averaging is to be done, they describe in detail how a delay quantity is to be measured, but do not mention that averaging is to be done. (E.g., the word "average" appears only twice in the draft.) 301. The term "session" seems to always be used to describe what is called a "dialog" in the SIP world, seeing has how the media (RTP) session is never discussed. Is this a telecom usage, or should it be replaced with "dialog"? 302. As Robert notes, T1 and T4 are used in ways that conflict with the use of those symbols in RFC 3261. They also lead one to wonder what happened to T2 and T3. But perhaps these symbols are a reference to a terminology used in TDM performance measurement and should be retained due to that standardization. 303. In measurements regarding a single request and its response(s), the roles UAC and UAS are well-defined. But in session-duration measurements, the roles of UAC and UAS are defined only within individual request-response transactions. In that case, a different terminology should be used. (E.g., "originator" vs. "terminator"? -- Surely the telecom world has words for this.) From adam@nostrum.com Mon Oct 12 07:56:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F863A69C9 for ; Mon, 12 Oct 2009 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdFmAehsie8h for ; Mon, 12 Oct 2009 07:56:40 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1914C3A68F4 for ; Mon, 12 Oct 2009 07:56:39 -0700 (PDT) Received: from [172.16.3.81] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9CEuXDs032251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Oct 2009 09:56:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AD343A1.4000508@nostrum.com> Date: Mon, 12 Oct 2009 09:56:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Hiroshima Agenda Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 14:56:41 -0000 [as chair] The 76th IETF meeting is coming up in less than a month. As before, we intend to focus on specific draft issues that the working group has had difficulty resolving on the list. If you would like to request agenda time, please send an email to me and Gonzalo indicating: 1. The name of the draft or drafts under discussion 2. A list of open issues to be addressed 3. A pointer to mailing list discussion of the draft (the subject line of associated threads is sufficient) Please send any requests as soon as possible, but no later than Friday, October 23rd. Thank you. /a From gonzalo.camarillo@ericsson.com Mon Oct 12 08:53:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79B928C23A for ; Mon, 12 Oct 2009 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWEtO9MKS-B7 for ; Mon, 12 Oct 2009 08:53:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8C7D228C1EC for ; Mon, 12 Oct 2009 08:53:46 -0700 (PDT) X-AuditID: c1b4fb3c-b7baeae000005f8e-10-4ad35109f74a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 70.F4.24462.90153DA4; Mon, 12 Oct 2009 17:53:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:53:45 +0200 Received: from [131.160.126.196] ([131.160.126.196]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:53:44 +0200 Message-ID: <4AD35107.6090705@ericsson.com> Date: Mon, 12 Oct 2009 18:53:43 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2009 15:53:45.0014 (UTC) FILETIME=[2DBC6D60:01CA4B54] X-Brightmail-Tracker: AAAAAA== Cc: Hadriel Kaplan Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 15:53:48 -0000 Folks, the authors have submitted a new revision of this draft, which addresses the WGLC comments they received. Please, have a look at it since we intend to request its publication shortly. Thanks, Gonzalo SIPCORE co-chair Christer Holmberg wrote: > > INFO lovers, INFO haters, and those who couldn't care less, > > Based on the earlier comments, WGLC comments, and the recent > discussions, we've put together a new version of the info events draft. > > The comments we have got indicated confusion and inconsistancy about the > terminology used (UAC/UAC, negotiation etc etc etc). We've really worked > hard trying to fix that in the new version. However, that has meant > quite big editorial changes in some places, so I really request people > that have provided comments on earlier versions (and maybe even got > their comments implemented later) to take a look and make sure they are > ok with the text. > > You can also get the draft from: > > _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01.txt_ > > > Regards, > > Christer > From gonzalo.camarillo@ericsson.com Tue Oct 13 06:18:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F2E3A67D1 for ; Tue, 13 Oct 2009 06:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-x8ZFC-Z0JE for ; Tue, 13 Oct 2009 06:18:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4AD423A67BE for ; Tue, 13 Oct 2009 06:18:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-46-4ad47e1db280 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3C.E5.04191.D1E74DA4; Tue, 13 Oct 2009 15:18:21 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:18:20 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:18:20 +0200 Message-ID: <4AD47E1C.7010302@ericsson.com> Date: Tue, 13 Oct 2009 16:18:20 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4AD35107.6090705@ericsson.com> In-Reply-To: <4AD35107.6090705@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Oct 2009 13:18:20.0492 (UTC) FILETIME=[A24D08C0:01CA4C07] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:18:24 -0000 Folks, given that the changes from 00 to 01 have been quite extensive, we have decided to issue a new WGLC on this draft. This WGLC will end on October 27th. Please, send your comments to this list. Thanks, Gonzalo SIPCORE co-chair Gonzalo Camarillo wrote: > Folks, > > the authors have submitted a new revision of this draft, which addresses > the WGLC comments they received. Please, have a look at it since we > intend to request its publication shortly. > > Thanks, > > Gonzalo > SIPCORE co-chair > > Christer Holmberg wrote: >> >> INFO lovers, INFO haters, and those who couldn't care less, >> >> Based on the earlier comments, WGLC comments, and the recent >> discussions, we've put together a new version of the info events draft. >> >> The comments we have got indicated confusion and inconsistancy about >> the terminology used (UAC/UAC, negotiation etc etc etc). We've really >> worked hard trying to fix that in the new version. However, that has >> meant quite big editorial changes in some places, so I really request >> people that have provided comments on earlier versions (and maybe even >> got their comments implemented later) to take a look and make sure >> they are ok with the text. >> >> You can also get the draft from: >> >> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01.txt_ >> >> >> Regards, >> >> Christer >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rjsparks@nostrum.com Wed Oct 14 07:24:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C869428C183 for ; Wed, 14 Oct 2009 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCIpuXfHSKsm for ; Wed, 14 Oct 2009 07:24:43 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 94D953A67B8 for ; Wed, 14 Oct 2009 07:24:42 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EEOgT0095796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 09:24:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: Robert Sparks To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 09:24:41 -0500 X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 14:24:43 -0000 In preparing this document for IETF last call, I found a few points we should discuss before moving forward. Major Comments I don't understand the sentence in section 4.1 that talks about RFC5009. There is not enough here to inform an implementor and don't think 5009 is required reading to understand or implement this document (hence, I don't agree that 5009 should be a normative reference). The sentence has been there for a long time, but I think other things have pulled reviewer's eyes away from it. In Sections 5 and 9, the document says to include SDP in a 199 if RFC3263 requires it. I would like to see some additional discussion around whether this is the right way to deal with this edge case. If it is, then this document needs to explain how a UA should handle receiving an offer in a 199. A different path out is to say that such a 199 MUST NOT be sent reliably. (More explanation of why we allow 199 to be sent reliably at all (why this is SHOULD not MUST) would also help). Last sentence on page 8: This paragraph is talking about the proxy generating a 199 itself. It would be terribly misleading from a diagnostics point of view for the proxy to put the Record-Route and contact from some UA (it would then look like the 199 came from the remote endpoint - is that what you are trying to accomplish?). Why is having these bits in the message useful at all? I don't think the document currently provides a solid answer to this question (maybe I'm missing it): If a proxy has multiple branches outstanding and receives a 200 OK on one of them, it forwards it immediately. As the other branches complete, should the proxy send 199s for them (assuming they didn't complete with additional 200s)? The security consideration section is not yet sufficient. If there is an The sentence in section 4.1 talks effective attack here, we need text that explores it. If there isn't, we need text that argues it isn't. Minor Comments Bottom of page 3, next to last paragraph, last sentence: This assumes the response can't be recovered from, precluding responding to authentication challenges, extension negotiation, etc. Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP? Section 8 is completely redundant. It adds no value to the draft. I suggest deleting it. Nits The 2119 language (two instances of MAY unless I missed more) appearing in the introduction are inappropriate in an introduction. Page 5, second paragraph : is "shall not" meant to be normative? Page 8 Section 6 first paragraph: Suggest dropping "on an early dialog" from the first sentence. Does it add anything? This would help avoid the problem the current text has about assuming proxies know about dialogs. From christer.holmberg@ericsson.com Wed Oct 14 11:20:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257EA3A6921 for ; Wed, 14 Oct 2009 11:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df0tQMOJh1Dt for ; Wed, 14 Oct 2009 11:20:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B60133A6901 for ; Wed, 14 Oct 2009 11:20:52 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-33-4ad61685858e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 77.55.04191.58616DA4; Wed, 14 Oct 2009 20:20:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 20:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 20:20:52 +0200 Message-ID: In-Reply-To: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM2hfIvARsTcQqR2mdOZi5hjZFqQAEfGVw References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , X-OriginalArrivalTime: 14 Oct 2009 18:20:53.0278 (UTC) FILETIME=[109E1BE0:01CA4CFB] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:20:54 -0000 Hi Robert, Comments inline.=20 ------------------- >In preparing this document for IETF last call, I found a few points we should discuss before moving forward. > >Major Comments > >I don't understand the sentence in section 4.1 that talks about RFC5009. There is not enough here to inform an=20 >implementor and don't think 5009 is required reading to understand or implement this document (hence, I don't agree that=20 >5009 should be a normative reference). The sentence has been there for a long time, but I think other things have pulled=20 >reviewer's eyes away from it. I can change 5009 into an informative reference. ------------------- >In Sections 5 and 9, the document says to include SDP in a 199 if >RFC3263 requires it. I would like to see some additional discussion around whether this is the right way to deal with=20 >this edge case. If it is, then this document needs to explain how a UA should handle receiving an offer in a 199. A=20 >different path out is to say that such a 199 MUST NOT be sent reliably. (More explanation of why we allow 199 to be sent=20 >reliably at all (why this is SHOULD not MUST) would also help). I wouldn't like to generally disallow to send 199 reliably, in case there is some future use-case which would need it. That's the reason for the SHOULD: don't send it reliably unless you have a good reason to do so. Regarding the specific must-include-SDP-offer case (which will be very rare, in my opinion) I see two alternatives: 1. We disallow reliable 199 in such cases 2. We say that the UAS must include e.g. an SDP offer without any m- lines. My proposal is to describe both alternatives, and say that the UAS MUST use of them. ------------------- >Last sentence on page 8: This paragraph is talking about the proxy generating a 199 itself. It would be terribly=20 >misleading from a diagnostics point of view for the proxy to put the Record-Route and contact from some UA (it would then=20 >look like the 199 came from the remote endpoint - is that what you are trying to accomplish?). Why is having these bits=20 >in the message useful at all? The intention is NOT to make the 199 look like it came from the endpoint, but someone commented that the UA could be confused if the bits aren't included. Personally I would bo ok to remove the text, since the proxy is not allowed to send a 199 reliably (there will be no PRACK etc, for which the bits would b needed) >I don't think the document currently provides a solid answer to this question (maybe I'm missing it): If a proxy has=20 >multiple branches outstanding and receives a 200 OK on one of them, it forwards it immediately. As the other branches=20 >complete, should the proxy send 199s for them (assuming they didn't complete with additional 200s)? The intention is that NO 199s are sent after 200 OK has been forwarded on a branch, and the proxy sends CANCEL on the other branches.=20 I DO agree that it is not clear in the spec, and that we can add some text about that. Now, IF we would want the proxy to send 199 for the other branches the proxy would have to wait for the final INVIE responses on the cancelled branches, because even if the proxy sends CANCEL the terminating UE may already have sent a 200 OK. ------------------- >The security consideration section is not yet sufficient. If there is an The sentence in section 4.1 talks effective=20 >attack here, we need text that explores it. If there isn't, we need text that argues it isn't. I am not sure I understand the comment. Could you please clarify? ------------------- >Minor Comments > >Bottom of page 3, next to last paragraph, last sentence: This assumes the response can't be recovered from, precluding=20 >responding to authentication challenges, extension negotiation, etc. Again, I am not sure I understand the comment. ------------------- >Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP? I can add it. How would you like to change to look like? ------------------- >Section 8 is completely redundant. It adds no value to the draft. I suggest deleting it. I based this on other drafts, but I can remove it. ------------------- >Nits > >The 2119 language (two instances of MAY unless I missed more) appearing in the introduction are inappropriate in an=20 >introduction. I propose to change "MAY" to "can" (in the introduction). ------------------- >Page 5, second paragraph : is "shall not" meant to be normative? Yes. I'll change it to uppercase. ------------------- >Page 8 Section 6 first paragraph: Suggest dropping "on an early dialog" from the first sentence. Does it add anything?=20 >This would help avoid the problem the current text has about assuming proxies know about dialogs. I can drop it from the first sentence. ------------------- Thanks for your comments! Regards, Christer From rjsparks@nostrum.com Wed Oct 14 11:29:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D63328C1DD for ; Wed, 14 Oct 2009 11:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctWppVeIq5o0 for ; Wed, 14 Oct 2009 11:29:40 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2873C3A692E for ; Wed, 14 Oct 2009 11:29:39 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EITZc6019781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 13:29:38 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com> From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-23-212385159 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 13:29:35 -0500 References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:29:41 -0000 --Apple-Mail-23-212385159 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Quick response to the clarifying questions: > >> The security consideration section is not yet sufficient. If there is > an The sentence in section 4.1 talks effective >> attack here, we need text that explores it. If there isn't, we need > text that argues it isn't. > > I am not sure I understand the comment. Could you please clarify? Wow - that got paste clobbered somewhere along the way. It should have said: The security consideration section is not yet sufficient. If there is an effective attack here, we need text that explores it. If there isn't, we need text that argues it isn't. > > ------------------- > >> Minor Comments >> >> Bottom of page 3, next to last paragraph, last sentence: This assumes > the response can't be recovered from, precluding >> responding to authentication challenges, extension negotiation, etc. > > Again, I am not sure I understand the comment. This sentence: When SIP entities upstream receive the non-2xx final response they will release resources associated with the session, and the UAC will terminate the session setup. is assuming the final response wasn't something the UAC could react to by trying again with some related changes (like responding to a 401/407). --Apple-Mail-23-212385159 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Quick response to the = clarifying questions:

<large chunk = snipped>


The security consideration section is not yet sufficient. = If there is
an The sentence in section 4.1 talks = effective
attack here, we need text that = explores it. If there isn't, we need
text that argues it = isn't.

I am not sure I understand the comment. Could you please = clarify?

Wow - that got paste clobbered = somewhere along the way.
It should have = said:

The security consideration section is not = yet sufficient. If there is
an  effective attack = here, we need text that explores it. If there = isn't, 
we need text that argues = it isn't. 



-------------------

Minor Comments

Bottom of page = 3, next to last paragraph, last sentence: This = assumes
the response can't be recovered from, precluding =
responding to authentication challenges, = extension negotiation, etc.

Again, I am not sure I = understand the comment.

This = sentence:
   When SIP entities upstream receive the =
non-2xx
   final response they will release resources associated with the
   session, and the UAC will terminate the session setup.
is = assuming the final response wasn't something the UAC could react = to
by trying again with some related changes (like responding = to a 401/407).


= --Apple-Mail-23-212385159-- From rjsparks@nostrum.com Wed Oct 14 11:37:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA3C28C1B6 for ; Wed, 14 Oct 2009 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VarwRhoBVcy9 for ; Wed, 14 Oct 2009 11:37:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6E89328C1D9 for ; Wed, 14 Oct 2009 11:37:08 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EIb7gC020496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 13:37:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <94E9DDAB-22CD-410A-B764-E504AD2955C5@nostrum.com> From: Robert Sparks To: Gonzalo Camarillo In-Reply-To: <4AD47E1C.7010302@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 13:37:07 -0500 References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 18:37:09 -0000 In fact, many of the sections are complete rewrites, and it has helped the draft. Please take some time to review it. RjS On Oct 13, 2009, at 8:18 AM, Gonzalo Camarillo wrote: > Folks, > > given that the changes from 00 to 01 have been quite extensive, we > have decided to issue a new WGLC on this draft. This WGLC will end > on October 27th. Please, send your comments to this list. > > Thanks, > > Gonzalo > SIPCORE co-chair > > Gonzalo Camarillo wrote: >> Folks, >> the authors have submitted a new revision of this draft, which >> addresses the WGLC comments they received. Please, have a look at >> it since we intend to request its publication shortly. >> Thanks, >> Gonzalo >> SIPCORE co-chair >> Christer Holmberg wrote: >>> >>> INFO lovers, INFO haters, and those who couldn't care less, >>> >>> Based on the earlier comments, WGLC comments, and the recent >>> discussions, we've put together a new version of the info events >>> draft. >>> >>> The comments we have got indicated confusion and inconsistancy >>> about the terminology used (UAC/UAC, negotiation etc etc etc). >>> We've really worked hard trying to fix that in the new version. >>> However, that has meant quite big editorial changes in some >>> places, so I really request people that have provided comments on >>> earlier versions (and maybe even got their comments implemented >>> later) to take a look and make sure they are ok with the text. >>> >>> You can also get the draft from: >>> >>> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01.txt_ >>> >>> 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 rjsparks@nostrum.com Wed Oct 14 13:52:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02F23A682B for ; Wed, 14 Oct 2009 13:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, MANGLED_TOOL=2.3, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2z34wJleG-x for ; Wed, 14 Oct 2009 13:52:07 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BADEC3A69C9 for ; Wed, 14 Oct 2009 13:52:06 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EKq5kF032183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 15:52:05 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <9F746F53-8685-4554-A15B-6EB4EF9B1A9B@nostrum.com> From: Robert Sparks To: Gonzalo Camarillo In-Reply-To: <4AD47E1C.7010302@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 15:52:05 -0500 References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:52:08 -0000 Just as a point of convenience, it would really help, days or maybe months from now, to have the string WGLC in the subject line for things like this. RjS On Oct 13, 2009, at 8:18 AM, Gonzalo Camarillo wrote: > Folks, > > given that the changes from 00 to 01 have been quite extensive, we > have decided to issue a new WGLC on this draft. This WGLC will end > on October 27th. Please, send your comments to this list. > > Thanks, > > Gonzalo > SIPCORE co-chair > > Gonzalo Camarillo wrote: >> Folks, >> the authors have submitted a new revision of this draft, which >> addresses the WGLC comments they received. Please, have a look at >> it since we intend to request its publication shortly. >> Thanks, >> Gonzalo >> SIPCORE co-chair >> Christer Holmberg wrote: >>> >>> INFO lovers, INFO haters, and those who couldn't care less, >>> >>> Based on the earlier comments, WGLC comments, and the recent >>> discussions, we've put together a new version of the info events >>> draft. >>> >>> The comments we have got indicated confusion and inconsistancy >>> about the terminology used (UAC/UAC, negotiation etc etc etc). >>> We've really worked hard trying to fix that in the new version. >>> However, that has meant quite big editorial changes in some >>> places, so I really request people that have provided comments on >>> earlier versions (and maybe even got their comments implemented >>> later) to take a look and make sure they are ok with the text. >>> >>> You can also get the draft from: >>> >>> _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-01.txt_ >>> >>> 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 rjsparks@nostrum.com Wed Oct 14 13:55:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4003F3A683E for ; Wed, 14 Oct 2009 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov2TsiHys1UM for ; Wed, 14 Oct 2009 13:55:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 464013A681F for ; Wed, 14 Oct 2009 13:55:50 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9EKtVAX032523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2009 15:55:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> From: Robert Sparks To: SIPCORE In-Reply-To: <4AD47E1C.7010302@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 15:55:31 -0500 References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Adam Roach , draft-ietf-sipcore-info-events@tools.ietf.org Subject: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:55:52 -0000 First, this version is a big improvement to the text. Christer put in a great deal of thought and effort resulting in a really good job rewriting several sections. Thanks! I have a lot of comments below, but overall I think the document is gettig much closer to done. Here's my feedback (as an individual) on -01: Major This is my biggest comment for this version and I'm taking it out of order to call attention to it. I think we've got some confusion in the IANA considerations section that we need to talk through. The document is setting up a First-Come-First-Served registry using "Specification Required" (which means that document has to exist somewhere, but not necessarily one that's been "approved" by any standards body), but we're calling such things "Standards Track" in the registration. What is it that we're really trying to set up? Whatever it is, please align it with 3427bis. (If the current text survives, we'll need to be very explicit with what "modified" means before this gets to IANA). When thinking about this, we need to make sure section 7.11 is aligned to the conclusion. Specifically, is it ok to have a package registered that points to a company or individual's website for the application procedures? I spotted two things to call attention to that _aren't_ in the draft. One thing that didn't survive the rewrite that I think we should work back in is a note to implementors that an INFO might arrive from a peer even before the first end-to-end provisional (because it might win a race with an immediate 200 OK) and this is not an error. The edit also addressed my concern about calling out to the obsoleted INFO document for definition of behavor by leaving removing any references of a normative nature. I think the current approach will probably work, but I'm still thinking it through and encourage review from this point of view from others. The rest of these are in document order. I would like 3.4 (which requires putting Recv-Info into REGISTER requests) to be deleted. I don't believe there is sufficient motivation to include this requirement and there is certainly insufficient specification of what it would mean for it to be there for it to be useful. If some future package or usage really wants to affect rendezvous this way, then let it specify it. Requiring that extra bits be pumped around the network because something _might_ want to use it is not the right thing to do. Similarly, it seems very strange to both require that elements put information into an OPTIONS request and then require other elements to ignore it (Section 3.5). What good is going to come from putting these bits in the OPTIONS request? The structure of section 4.4 is a little off. It would help the logic flow to move the meaning of the last paragraph to the first of the section. Words like "Normal processing as required by [RFC3261] might require a failure response to be sent to the INFO request. If no such requirement constrains the UA, then..." I still have not reviewed the tables in 5.1 and 5.2. Please make sure someone is on record as having done so before this is pub-requested. That said, I noticed based on looking at the diffs that "o"'s have been added for NOT and RFR. Why? (and if it makes sense for them to be there, why didn't they also end up in SUB?). Btw - thanks for working with my suggestion leading to the m* under INF. Section 7.1 last paragraph. I think we should ask any future packages to explicitly explain when one of the issues section 7 calls out is not applicable. I suggest replacing "unless an issue is not applicable" with "or document why an issue is not applicable". Section 7.7 last paragraph: This MUST NOT requirement makes no sense, _especially_ for the specific case the paragraph calls out. What is the paragraph trying to accomplish? Section 8.2 ABNF: We've struggled before with the addition of new header fields to the ABNF. Trying to use / as the document currently does for extension-method does the wrong thing. I suggest we follow the approach the outbound draft took instead. Has anybody run the ABNF in this section through an automated checker? Section 11 should be titled "Security Considerations". I suggest Section 7.10 be relabelled "Info Package Security Considerations". The first sentence from Section 11 (quoted below) is at odds with the proposed First-come-first-served registration: "By eliminating multiple uses of INFO messages without adequate community review and by eliminating the possibility for rogue SIP UAs from confusing another User Agent by purposely sending unrelated INFO requests, we expect this document's clarification of the use of INFO to improve the security of the Internet." Why is Appendix A an appendix? I suspect that's editing legacy. Unless there's a compeling reason to leave it as an appendix, please move it into the main body of the document. (B and C are ok as Appendices) Minor There are still several instances of using 2119 words to constrain other documents or standards work rather than constraining protocol. There should be no 2119 words, for instance, in section 4.6. The MUST NOT in section 7.12 is another strong example. Page 5 second to last pararaph last sentence: I don't think "identical" is the word you want to use here. I suggest "analogous" instead. Page 9, ACK message: * The branch parameter must be different in an ACK to a 200 * The message needs a Max-Forwards * The CSeq doesn't match the INVITE/200. Page 10, section 4.1 Second paragraph: This wording is confusing. It essentially says "New things follow this specification and old things don't. New things should be prepared to act like old things when old things talk to them". This backwards-compatibility requirement is adequately captured elsewhere, I suggest deleting the paragraph. Page 10, section 4.2 3rd paragraph: Suggest adding "beyond its transaction" after "has no lifetime" Page 11, section 4.3, 6th paragraph: Suggest adding "even" as follows: "In that case, even if multipart MIME is used," Page 12 second paragraph: Suggest adding a forward reference to the section defining the 469 response code here where the code is first mentioned. Page 12 section 4.5 : "is normally generated by the SIP stack" goes too far. Similarly the MUST requirement in the 2nd paragraph (sending a INFO) not really the constraint we need. I suggest replacing the section with this text: "The Info Package Framework is designed to allow a SIP stack to generate a response to an INFO message without application interaction. As a result, Info Packages cannot require bodies in INFO responses, require different response codes, or otherwise require application information be placed in the response to the INFO request. If the application has information to send in the other direction, one alternative available to it is sending a new INFO request." The first paragraph on page 16, last sentence says a request without an Info-Package header MUST NOT contain an Info-Package header :). (What did it really mean to say?) Page 17, Section 7.3: Why is there a requirement for a name here that's separate from the header field value? Page 17 Section 7.4 second paragraph: This could be read to say two packages cant share the same parameter name. Can we rewrite it to avoid that misinterpretation? Why hasn't the changelog been kept up? There are at least two revisions worth of changes (the most recent will probably be pretty hard to write). The working group will need to decide whether to bring it up to date, delete the section before requesting IETF-wide review, or add a section explaining the gap in information before we proceed. Nits: Page 5 second to last paragraph: missing an "of" between "big risk" and "interoperability"? Page 6 3rd paragraph, first sentence should have its commas moved around or be rephrased. Suggest "If a UA supports the Info Package mechanism, it uses the Recv-Info header field, on a per-session bases, to indicate which Info Packages it is willing to receive." Page 8 4th paragraph: wit->with Page 10 1st paragraph: Suggest deleting the first occurance of the word "how". Page 10 section 4.2 3rd paragraph: The document should use a consistent human-readable phrase for 481 throughout. Page 11 section 4.3 3rd paragraph: "filed" -> "field" Page 12 section 4.4 3rd paragraph: Is this "must" supposed to be "MUST"? Page 15 section 6 1st paragraph 1st sentence: "the and a"? Is this really two sentences that need to be teased back apart? Page 15 section 6 2nd paragraph "to not" -> "do not" Page 17 section 7.3 : what should "**9" be? Page 17, section 7.5 : please poing to 3492bis instead. Page 18, section 7.8 first paragraph: Missing "define" after MUST. (and this shouldn't be a 2119 word). Page 19 paragraph at the top of the page: Suggest replacing "The most common method" with "One way". Page 19 end of sedction 8.2 (A very little pedantic nit): Suggest saying "more than one Recv-Info header field name." Appendix C : Out of curiosity, which are the four paragraphs from the Litmus draft? Are they still here and intact? Appendix C : I think we should delete the "My, we have been" sentence. Appendix C : The number of messages stats are impressive, but completely useless to the reader of an RFC once it's published. I suggest we move that information out of the draft, into the tracker in the "protocol quality" field of the writeup. From christer.holmberg@ericsson.com Thu Oct 15 08:54:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8A128C104 for ; Thu, 15 Oct 2009 08:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhbQ01jRNPfm for ; Thu, 15 Oct 2009 08:54:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C4B5728C117 for ; Thu, 15 Oct 2009 08:54:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-1a-4ad745bf5a02 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E3.CD.04191.FB547DA4; Thu, 15 Oct 2009 17:54:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 17:53:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 17:53:19 +0200 Message-ID: In-Reply-To: <0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 Thread-Index: AcpM/EzyUg4F5md1Trejk8QBtAWnlgAsjyIQ References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> <0C768562-119E-46AB-A3C9-2C0130B7B6A3@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" X-OriginalArrivalTime: 15 Oct 2009 15:53:20.0507 (UTC) FILETIME=[9E5E34B0:01CA4DAF] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 15:54:38 -0000 Hi, =20 >Quick response to the clarifying questions: > >=20 >=09 >=09 >The security consideration section is not yet sufficient. > >It should have said: > >The security consideration section is not yet sufficient. If there is >an effective attack here, we need text that explores it. If there isn't,=20 >we need text that argues it isn't.=20 Ok, I'll look into that.=20 =09 ------------------- =09 >Bottom of page 3, next to last paragraph, > > >This sentence: > When SIP entities upstream receive the non-2xx > final response they will release resources associated with the > session, and the UAC will terminate the session setup. >is assuming the final response wasn't something the UAC could react to >by trying again with some related changes (like responding to a 401/407). Ok, now I got it. So, I guess the text should say something like: "When SIP entities upstream receive the non-2xx final response they will normally release resources associated with the session, and the UAC will terminate the session setup, unless the final response (e.g. a 401/407 final response) triggers a new session setup request to be sent." Regards, Christer From john.elwell@siemens-enterprise.com Thu Oct 15 13:46:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E3928C165 for ; Thu, 15 Oct 2009 13:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn+o1ygnNfT6 for ; Thu, 15 Oct 2009 13:46:53 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id C60AD28C181 for ; Thu, 15 Oct 2009 13:46:50 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9FKkp31004818; Thu, 15 Oct 2009 22:46:51 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9FKkpKf017979; Thu, 15 Oct 2009 22:46:51 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 15 Oct 2009 22:46:50 +0200 From: "Elwell, John" To: SIPCORE , Christer Holmberg Date: Thu, 15 Oct 2009 22:46:47 +0200 Thread-Topic: WGLC comments (was RE: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) Thread-Index: AcpMB6lpHVs+DMl9Q5mmFhWKPSpi6QBnsssw Message-ID: <7402509E63C5A145A6095D46C179A5B71477DB8A@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> In-Reply-To: <4AD47E1C.7010302@ericsson.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] WGLC comments (was RE: Draft new version: draft-ietf-sipcore-info-events-01) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 20:46:55 -0000 I appreciate this document has undergone a significant rewrite, but unfortu= nately this seems to have introduced a bunch more errors. Perhaps I didn't = read the previous version carefully enough. Below are my main comments. The= re are lots of nits, which I will send to Christer separately. 1. I think the document would benefit from having a definition of Info Pack= age at some point early on. In section 1 we have "This document defines a m= echanism, using Info Packages, which provides the possibility for UAs to indicate what INFO usages they support, and to define content syntax and semantics for the data transported in the INFO messages.", but that describes the mechanism, rather than defining Info package. As a s= tarter, how about something like: "A specified usage of the SIP INFO method, detailing the format and semanti= cs of information transported." 2. In several places in the document (e.g., Abstract, section 1), it talks = about receiving Info Packages, but I think that is incorrect. Shouldn't it = really be worded along the lines of receiving information within the contex= t of an Info Package? (c.f., RFC 3265, where we don't receive event package= s in NOTIFY requests, we receive events). 3. Was there a reason why we decided to use "Recv-Info: nil" rather than si= mply "Recv-Info:" if not willing to receive? 4. Although much of the document talks about INFO within the context of an = invite dialog usage, there are many places that mention session, which seem= s inconsistent. Session is used early in section 1, but that is probably re= asonable, as it describes the basic capability of SIP. However, later we ha= ve "INFO messages are always part of, and share the fate of, an invite dialog usage. INFO message can not be sent as part of other dialog usages, and they can not be sent outside an existing session." I cannot rationalise this mixture of invite dialog usage and session in the= same sentence. In this particular case, I don't see what value "and they c= an not be sent outside an existing session" adds. Then later: "which Info Packages it is willing to receive, on a per-session basis" and "during the lifetime of the invite dialog usage of the session" What is "dialog usage of the session"? And so on. We should decide whether to talk about INFO being used in the co= ntext of a session or of an invite dialog usage and use that terminology co= nsistently. 5. I think it has already been questioned why we use Recv-Info in a REGISTE= R request. Forking decisions are based on RFC 3840 UA capabilities, and if = decisions need to be made based on Info Package support, we should extend t= hat mechanism. Also, the semantics of Recv-Info are that it indicates packa= ges it is willing to receive. The presence of a package in Recv-Info in an = INVITE request does NOT convey any meaning about wanting to select a UAS th= at can receive that same package. 6. In the example in 3.6: "Since the UAS does not support Info Package P, the UAC decides to indicate in the ACK request that it is only willing to receive Info Package R, which the UAS also indicated support of." Whilst this is certainly legitimate behaviour (a UA can change its mind abo= ut what it wishes to receive at any time), isn't there a danger with this e= xample of implying that a UA should limit what it is prepared to receive to= what the peer UA has indicated it is willing to receive? I don't think thi= s aspect of the example is particularly helpful. 7. In 4.2: "If a UA receives an INFO request outside an existing dialog, the UA MUST response with a 481 Call Does Not Exist error response." What if INFO request is received within the context of a dialog but a dialo= g for which there is no invite usage? But I see that is covered in 4.4. Shouldn't both conditions be covered in 4= .4, rather than one in 4.2 and the other in 4.4? 8. In 4.3: "The application data associated with an Info Package SHOULD be carried as a payload in the message body of the INFO request, unless the information can be retrieved from a SIP header field." I don't remember discussing this exception. What sort of thing do we have i= n mind? 9. In 4.3 "In that case, if multipart MIME is used, the UA does not need to insert an 'Info- Package' header value for the individual body parts." Does this mean it doesn't need to have a Content-Disposition header field a= ssociated with individual body parts? 10. In 4.4 "If a UA receives an INFO request, that carries a message body t= hat the UA does not support, and support of the message body is required in the Content-Disposition header field, the UA MUST send a 415 Unsupported Media Type response. If support of the message body is optional, the UA MUST send a 200 OK response even if the UA does not support the message body." I am confused. In 4.3 it says that Content-Disposition has the value "Info-= Package", so how can it indicate support required/not required? In addition, this paragraph should cover body parts, not just bodies. 11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and in REFE= R request? These doesn't related to invite dialog usages. 12. In 5.2.2 "This document adds Recv-Info to the definition of the element "general-header" in the SIP [RFC3261] message grammar" I can't find "general-header" in RFC 3261. 13. In section 6 "An INFO request associated with an Info Package MUST cont= ain a Info- Package header field." Since section 6 deals with "Legacy INFO Usage", this is not the place to ma= ke a normative statement concerning Info Packages. Instead it would be acce= ptable to mention what is mandated elsewhere (section 4). 14. In section 7.7 "If Info Package restrictions are violated (i.e. if over= lapping INFO requests are not allowed for an Info Package, but a UA still receives overlapping requests), the UA MUST NOT reject such requests. " This is in the section on Info Package Usage Restrictions. Such a normative= statement on UA behaviour should occur in section 4. It can then be mentio= ned (informatively) in 7.7. 15. "5.2.2. Recv-Info header field" This occurs within section 5 "Formal INFO method definition", but has nothi= ng to do with the INFO method. Furthermore, I am not keen on the separation between the method and header = field descriptions in 5 and the ABNF for these in section 8. Maybe 8 could = be moved to directly after 5. 16. In 9.5: "Please add the following registration to the Content-Dispositi= on registry. The description suitable for the IANA registry is as follows. The payload of the message carrying this Content-Disposition header field value is the payload of an Info Package" This text fails to state the value that is being registered. 17. Section 10 gives examples of the INFO method, whereas section 3.6 gives= an example of the Recv-Info header field. It would make sense either to ha= ve all examples in one place or to have all examples in the sections to whi= ch they relate. 18. "11. Modifications to SIP Change Process" This is a strange title. The contents look like they constitute a Security = Considerations section. 19. In B.2: "QSIG uses Content-Type to identify QSIG protocol elements in a= n INFO message. See RFC4497 [RFC4497]." I am sure I made this comment before. RFC 4497 does NOT cover the conveyan= ce of QSIG in INFO (it covers interworking between SIP and QSIG). The conve= yance of QSIG in INFO is covered by Standard ECMA-355 (the IETF never adopt= ed this work). 20. In 4.1 "It also describes how an UA can indicate support of Info Packages in OPTIONS requests and during registration." Wasn't this already described in section 3? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 13 October 2009 14:18 > To: SIPCORE > Subject: Re: [sipcore] Draft new version:=20 > draft-ietf-sipcore-info-events-01 >=20 > Folks, >=20 > given that the changes from 00 to 01 have been quite=20 > extensive, we have=20 > decided to issue a new WGLC on this draft. This WGLC will end=20 > on October=20 > 27th. Please, send your comments to this list. >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair >=20 > Gonzalo Camarillo wrote: > > Folks, > >=20 > > the authors have submitted a new revision of this draft,=20 > which addresses=20 > > the WGLC comments they received. Please, have a look at it since we=20 > > intend to request its publication shortly. > >=20 > > Thanks, > >=20 > > Gonzalo > > SIPCORE co-chair > >=20 > > Christer Holmberg wrote: > >> > >> INFO lovers, INFO haters, and those who couldn't care less, > >> > >> Based on the earlier comments, WGLC comments, and the recent=20 > >> discussions, we've put together a new version of the info=20 > events draft. > >> > >> The comments we have got indicated confusion and=20 > inconsistancy about=20 > >> the terminology used (UAC/UAC, negotiation etc etc etc).=20 > We've really=20 > >> worked hard trying to fix that in the new version.=20 > However, that has=20 > >> meant quite big editorial changes in some places, so I=20 > really request=20 > >> people that have provided comments on earlier versions=20 > (and maybe even=20 > >> got their comments implemented later) to take a look and make sure=20 > >> they are ok with the text. > >> > >> You can also get the draft from: > >> > >>=20 > _http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-inf > o-events-01.txt_=20 > >> > >> > >> Regards, > >> > >> Christer > >> > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Fri Oct 16 11:29:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F2F3A68AB for ; Fri, 16 Oct 2009 11:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vog9108qdadm for ; Fri, 16 Oct 2009 11:29:15 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 4602E3A685A for ; Fri, 16 Oct 2009 11:29:15 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-d4-4ad8bb7dd81e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B8.F8.08816.D7BB8DA4; Fri, 16 Oct 2009 20:29:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 20:29:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 20:29:16 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response Thread-Index: AcpM2hfIvARsTcQqR2mdOZi5hjZFqQAEfGVwAGg1WlA= References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Robert Sparks" , X-OriginalArrivalTime: 16 Oct 2009 18:29:17.0552 (UTC) FILETIME=[9203B700:01CA4E8E] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - 199 after final response X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:29:16 -0000 Hi,=20 >>I don't think the document currently provides a solid answer to this >>question (maybe I'm missing it): If a proxy has=20 >>multiple branches outstanding and receives a 200 OK on one of them, it >>forwards it immediately. As the other branches=20 >>complete, should the proxy send 199s for them (assuming they didn't >>complete with additional 200s)? > >The intention is that NO 199s are sent after 200 OK has been forwarded on a branch, and the proxy sends CANCEL on the other branches.=20 > >I DO agree that it is not clear in the spec, and that we can add some text about that. Actually, when taking a closer look at the text, I think this is already covered. The text says that when the proxy receives a non-2xx final response, it sends 199 if the forking proxy has not already sent a final resposne for any of the early dialogs. So, if a final response (2xx or non-2xx) response has been sent, additional non-2xx responses will not trigger 199. Regards, Christer From christer.holmberg@ericsson.com Fri Oct 16 11:41:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29913A6802 for ; Fri, 16 Oct 2009 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.129 X-Spam-Level: X-Spam-Status: No, score=-6.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppg3cMfXHayy for ; Fri, 16 Oct 2009 11:41:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D81763A6953 for ; Fri, 16 Oct 2009 11:41:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-73-4ad8be7331c4 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2D.18.24026.37EB8DA4; Fri, 16 Oct 2009 20:41:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 20:40:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 20:40:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] AD review draft-ietf-sipcore-199-00 - DTLS/SRTP Thread-Index: AcpM2hfIvARsTcQqR2mdOZi5hjZFqQAEfGVwAGjJcJA= References: <70463F72-4486-4384-B294-078EA191CC9B@nostrum.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Robert Sparks" , X-OriginalArrivalTime: 16 Oct 2009 18:40:59.0616 (UTC) FILETIME=[347A2E00:01CA4E90] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00 - DTLS/SRTP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:41:54 -0000 =20 Hi, >>Page 6 - NOTE in section 4.1: Why isn't this calling out DTLS/SRTP? > >I can add it. How would you like to change to look like? I would need some clarification on why DTLS would have to be added here. The issue is not related to a specific key management mechanism used, but with the fact that the media is encrypted in general. Of course different key management mechanisms may have different impacts on the needed resources etc, but I still don't see why this would be an issue specific to DTLS.=20 Regards, Christer From christer.holmberg@ericsson.com Fri Oct 16 14:14:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B4A3A657C for ; Fri, 16 Oct 2009 14:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKRI8mgw74Fd for ; Fri, 16 Oct 2009 14:14:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 365B93A67EB for ; Fri, 16 Oct 2009 14:14:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-2c-4ad8e236637d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0E.BA.24026.632E8DA4; Fri, 16 Oct 2009 23:14:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 23:14:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 23:14:30 +0200 Message-ID: In-Reply-To: <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (was Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwBgSPBA References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "SIPCORE" X-OriginalArrivalTime: 16 Oct 2009 21:14:30.0734 (UTC) FILETIME=[A6BB3EE0:01CA4EA5] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:14:29 -0000 =20 Hi, --------------- >I would like 3.4 (which requires putting Recv-Info into REGISTER >requests) to be deleted. I don't believe there is sufficient motivation = to include this requirement and >there is certainly insufficient = specification of what it would mean for it to be there for it to be = useful. >If some future package or usage really wants to affect = rendezvous this way, then let it specify it. >Requiring that extra bits = be pumped around the network because something _might_ want to use it is = not the >right thing to do. I am not sure I agree this would be package specific. I think that, for = all packages, it could be useful to be able to do forking based this. = Otherwise operators may have to rely on static configuration in the = network, which I thought is something we want to avoid. One of the biggest problem I hear about from the market is related to = not being able to design reliable, consistent and effective forking = algorithms, since some clients indicate some capabilities in = registrations, other clients indicate some other capabilities in = registrations, and some clients don't indicate anything. --------------- >Similarly, it seems very strange to both require that elements put = information into an OPTIONS request and=20 >then require other elements to ignore it (Section 3.5). What good is = going to come from putting these bits=20 >in the OPTIONS request? I don=92t think the text talks about =93ignoring=94. OPTIONS is used to query capabilities/extensions, but when sessions are = established all capabilities/extensions etc must still be = negotiated/required for each specific session. That is normal SIp = procedures, and Info Packages are no different from any other = capability/extension in that sense. --------------- Regards, Christer From adam@estacado.net Fri Oct 16 14:54:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475B03A67AA for ; Fri, 16 Oct 2009 14:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBpfjjIN+vSk for ; Fri, 16 Oct 2009 14:54:02 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 186643A6358 for ; Fri, 16 Oct 2009 14:54:01 -0700 (PDT) Received: from [172.16.3.231] (orthrus.test.estacado.net [172.16.3.231] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9GLs0X7092915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 16:54:00 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AD8EB78.9080408@estacado.net> Date: Fri, 16 Oct 2009 16:54:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Oct 2009 14:55:43 -0700 Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:54:03 -0000 On 10/16/09 4:14 PM, Christer Holmberg wrote: > > Hi, > > --------------- > > >> I would like 3.4 (which requires putting Recv-Info into REGISTER >> requests) to be deleted. I don't believe there is sufficient motivation to include this requirement and>there is certainly insufficient specification of what it would mean for it to be there for it to be useful.>If some future package or usage really wants to affect rendezvous this way, then let it specify it.>Requiring that extra bits be pumped around the network because something _might_ want to use it is not the>right thing to do. >> > I am not sure I agree this would be package specific. I think that, for all packages, it could be useful to be able to do forking based this. Otherwise operators may have to rely on static configuration in the network, which I thought is something we want to avoid. > That was the reasoning for SUBSCRIBE and NOTIFY, from which this behavior has been borrowed. However, I don't think the situations are particularly comparable. With SUBSCRIBE, the rationale was: if an endpoint registered with support for an event package, then a proxy could preferentially select it during target processing when a SUBSCRIBE came in for the associated event package. This is pretty watertight, because anything that doesn't support the event package is going to be completely incapable of doing anything even remotely useful if the SUBSCRIBE gets routed to it. INFO is radically different. You can't send INFO outside of a dialog -- so, by the time an INFO is on the wire, it's ultimate destination has already been written in stone. The corresponding INVITE is very different than the SUBSCRIBE case -- if that INVITE gets routed to something that doesn't necessarily understand every kind of INFO that the caller's UA might want to send, very useful things can still happen. /a From christer.holmberg@ericsson.com Fri Oct 16 19:12:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D41E3A69AE for ; Fri, 16 Oct 2009 19:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZ+jAwPinqvw for ; Fri, 16 Oct 2009 19:12:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 557343A691D for ; Fri, 16 Oct 2009 19:12:15 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-25-4ad9280269e1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 32.D1.04191.20829DA4; Sat, 17 Oct 2009 04:12:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 04:12:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Oct 2009 04:12:17 +0200 Message-ID: In-Reply-To: <4AD8EB78.9080408@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (was Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpOqy3nYud2gnagRDWG04HSocjg+QAI40cg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <4AD8EB78.9080408@estacado.net> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 17 Oct 2009 02:12:18.0136 (UTC) FILETIME=[40886D80:01CA4ECF] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 02:12:16 -0000 Hi,=20 >>>I would like 3.4 (which requires putting Recv-Info into REGISTER >>>requests) to be deleted. I don't believe there is sufficient motivation to include this requirement and there is=20 >>>certainly insufficient specification of what it would mean for it to be there for it to be useful. If some future=20 >>>package or usage really wants to affect rendezvous this way, then let it specify it. Requiring that extra bits be=20 >>>pumped around the network because something _might_ want to use it is not the right thing to do. >> =20 >>I am not sure I agree this would be package specific. I think that, for all packages, it could be useful to be able to=20 >>do forking based this. Otherwise operators may have to rely on static configuration in the network, which I thought is=20 >>something we want to avoid. > =20 > >That was the reasoning for SUBSCRIBE and NOTIFY, from which this behavior has been borrowed. However, I don't think the=20 >situations are particularly comparable. > >With SUBSCRIBE, the rationale was: if an endpoint registered with support for an event package, then a proxy could=20 >preferentially select it during target processing when a SUBSCRIBE came in for the associated event package. This is=20 >pretty watertight, because anything that doesn't support the event package is going to be completely incapable of doing=20 >anything even remotely useful if the SUBSCRIBE gets routed to it. > >INFO is radically different. You can't send INFO outside of a dialog -- so, by the time an INFO is on the wire, it's=20 >ultimate destination has already been written in stone. The corresponding INVITE is very different than the SUBSCRIBE=20 >case -- if that INVITE gets routed to something that doesn't necessarily understand every kind of INFO that the caller's=20 >UA might want to send, very useful things can still happen. I agree.=20 But, I am not proposing that a proxy MUST fork based on Info Packages. I only want to make sure the information is always there IF the proxy wants to do it. Regards, Christer From adam@nostrum.com Fri Oct 16 19:51:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75A93A6909 for ; Fri, 16 Oct 2009 19:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyJZC19dqTLe for ; Fri, 16 Oct 2009 19:51:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B56D93A6899 for ; Fri, 16 Oct 2009 19:51:53 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9H2pdn3012853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Oct 2009 21:51:46 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4AD93139.2020304@nostrum.com> Date: Fri, 16 Oct 2009 21:51:37 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <4AD8EB78.9080408@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 02:51:54 -0000 On 10/16/09 21:12, Oct 16, Christer Holmberg wrote: > But, I am not proposing that a proxy MUST fork based on Info Packages. > I only want to make sure the information is always there IF the proxy > wants to do it. And I am agreeing with Robert's evaluation that these are largely semantic-free bits wasting space in the network for no demonstrable benefit. If a proxy declines to fork an INVITE to a registered contact on the basis of INFO packages, it is *doing* *the* *wrong* *thing*. /a From christer.holmberg@ericsson.com Sat Oct 17 10:08:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855F93A68EE for ; Sat, 17 Oct 2009 10:08:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dqiiAyKTULj for ; Sat, 17 Oct 2009 10:08:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 562B43A6827 for ; Sat, 17 Oct 2009 10:08:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-3c-4ad9f9f66304 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9F.FC.04191.6F9F9DA4; Sat, 17 Oct 2009 19:08:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 19:08:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Oct 2009 19:08:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (was Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpO1MpopS8S7Fx0QDS4eCMmS6V9YgAdWMG7 References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <4AD8EB78.9080408@estacado.net> <4AD93139.2020304@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 17 Oct 2009 17:08:06.0477 (UTC) FILETIME=[650A67D0:01CA4F4C] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:08:06 -0000 Hi, =20 >>But, I am not proposing that a proxy MUST fork based on Info Packages. >>I only want to make sure the information is always there IF the proxy >>wants to do it. > >And I am agreeing with Robert's evaluation that these are largely >semantic-free bits wasting space in the network for no demonstrable >benefit. =20 So, being able to fork based on capabilities (no matter whether they are = info packages or something else) is not beneficial ? =20 >If a proxy declines to fork an INVITE to a registered contact on the = basis of INFO packages, it is *doing* *the* *wrong*=20 >*thing*. =20 I didn't say it would decline, but if it does serial forking it may give = higher priority to a terminal which has registered support for certain = info packages. Of course the forking decission may also be done in = conjunction with criterias related to other types of capabilities. As far as I remember, 3261 says that forking can be done pretty much = based on ANY information - there is no "right" or "wrong" way from a = protocol perspective. Are we now going to start telling operators how = they shall do their forking? I also think that being able to fork based on info packages fits very = well into the do-what-I-say approach which we discussed during the = service-id era... Regards, Christer =20 From christer.holmberg@ericsson.com Sat Oct 17 10:22:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F383A689C for ; Sat, 17 Oct 2009 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxPxSlkm-Ovq for ; Sat, 17 Oct 2009 10:22:03 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AE0A83A6855 for ; Sat, 17 Oct 2009 10:22:02 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-f6-4ad9fd3d0774 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A6.4A.08816.D3DF9DA4; Sat, 17 Oct 2009 19:22:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 19:22:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Oct 2009 19:22:04 +0200 Message-ID: In-Reply-To: <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (was Re: [sipcore] Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwCPJSIg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "SIPCORE" X-OriginalArrivalTime: 17 Oct 2009 17:22:05.0502 (UTC) FILETIME=[592375E0:01CA4F4E] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - when can a UAS send INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:22:04 -0000 =20 Hi, >One thing that didn't survive the rewrite that I think we should work back in is a note to implementors that an INFO might arrive from a peer even before the first end-to-end provisional (because it=20 >might win a race with an immediate 200 OK) and this is not an error. You gave this comment to me earlier, in your previous comments. I replied, but you never got back to me :) The idea is that the UAS can start sending INFOs once the dialog (early or final) has been established from the UAS's perpective. If I remember corretly, that occurs when the UAS receives an acknolwedgement (PRACK or ACK) to the response which established the dialog. In that case there could be no race condition, because the UAS knows that the UAC has received the 18x/200 response. Regards, Christer From shida@ntt-at.com Sun Oct 18 00:16:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E146A3A6783 for ; Sun, 18 Oct 2009 00:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngwWT5eQ7iBm for ; Sun, 18 Oct 2009 00:16:37 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.72.130]) by core3.amsl.com (Postfix) with SMTP id 0D77E3A63EB for ; Sun, 18 Oct 2009 00:16:36 -0700 (PDT) Received: (qmail 4366 invoked from network); 18 Oct 2009 07:36:00 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 18 Oct 2009 07:36:00 -0000 Received: from fl1-122-135-49-232.tky.mesh.ad.jp ([122.135.49.232]:52111 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1MzQ0O-00024V-Pr; Sun, 18 Oct 2009 02:16:41 -0500 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed From: Shida Schubert In-Reply-To: <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> Date: Sun, 18 Oct 2009 16:16:39 +0900 Content-Transfer-Encoding: 7bit Message-Id: <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> To: Francois Audet X-Mailer: Apple Mail (2.1076) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , "Elwell, John" , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 07:16:38 -0000 The reason why current use of "mp" tag is not semantically correct for freephone, is because Service-URN and free-phone is a "name" and not an "address" based on the definition in the target-uri draft. I believe we need to define another tag for "name" to "address" translation. ## Definition of address/name in the target-uri draft ## A name is a moniker for an entity which refers to it in a way which reveals nothing about where it is in a network. In SIP, tel URI which doesn't represent the location of the entity is a name. An address is an identifier for an entity which describes it by its location on the network. In SIP, the SIP URI itself is a form of address because the host part of the URI, the only mandatory part of the URI besides the scheme itself, indicates the location of a SIP server that can be used to handle the request. ## -- ## In deployment, name to name translation never happens and generally "name" to "address" translation is very deterministic that entity doing the mapping/translation can tag the entry with confidence. For example, If one sends a request to PSAP using 911, directory assistance using 411, name(411,911 or service-URN) is translated to an address. That address may be translated numerous times to another address (PSAP in NYC to PSAP in NJ) but will never be translated again to another name(911 to 411). Furthermore, entity/organization that is expecting to be reached by name usually knows what name it will be reached by, so having the ability to distinguish one service to another is probably not necessary but having the ability to tag "name" to "address" translation, I believe is very helpful. Any thoughts? Regards Shida On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: > Other idea? > > (I really don't care personally about "freephone"...) > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Thursday, September 24, 2009 11:48 >> To: Audet, Francois (SC100:3055); Elwell, John; Shida >> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >> Dean Willis; Elwell, John; Keith Drage >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> Yes got that, but that does not justify a service specific >> tag in 4244bis. >> /hans erik >> From audet.francois@gmail.com Sun Oct 18 07:37:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060583A68EF for ; Sun, 18 Oct 2009 07:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYIwPEcXaWBu for ; Sun, 18 Oct 2009 07:37:10 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id D150A3A68D3 for ; Sun, 18 Oct 2009 07:37:09 -0700 (PDT) Received: by ewy4 with SMTP id 4so747553ewy.37 for ; Sun, 18 Oct 2009 07:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=KtBRLRpoi+4GBqcFepK/B0IKvm9CmNvb7cmANd7GfIE=; b=F+5QBfXmApYYscbwXloCKz8T56ya+1clylboRyScuuCLQJTIhvQKcY+5jg15dFAmRW YQeEt4Cg3mKrVEyUc46AQ74009jGnEiVaYKmzRHngCWvZeqSmvE5nTTSNsGVwaZSdBy1 Poomvl4xuxWZFTgjhlcndFEuzYzUrwhTGmk8w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QcW2XEqk8F40Rh6FldMFcm9jO4fPJbLiusMoQ+mUNN0ZSlD7+UL/HVo3SjVR8WLNvE zie+aLs6SVY9hQbBMhF2Qebim02CmBUVIbKqgLJSwF72xRSSu84qNMSSYbwdQ/xVeonH W02Dget1rN+vsg4V8cw0IpXj23qF7H23BrBqc= Received: by 10.211.128.15 with SMTP id f15mr4179658ebn.84.1255876633371; Sun, 18 Oct 2009 07:37:13 -0700 (PDT) Received: from ?192.168.15.100? (adsl-75-36-217-101.dsl.pltn13.sbcglobal.net [75.36.217.101]) by mx.google.com with ESMTPS id 5sm4385522eyh.25.2009.10.18.07.37.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Oct 2009 07:37:11 -0700 (PDT) Message-Id: <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com> From: =?ISO-8859-1?Q?Fran=E7ois_AUDET?= To: Shida Schubert In-Reply-To: <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Oct 2009 07:37:06 -0700 References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> X-Mailer: Apple Mail (2.936) Cc: Jonathan Lennox , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 14:37:11 -0000 This is quite an interesting idea. Probably wider in scope than History-Info, but it sounds like a good way to tackle the problem. On Oct 18, 2009, at 24:16 , Shida Schubert wrote: > > The reason why current use of "mp" tag is not > semantically correct for freephone, is because Service-URN > and free-phone is a "name" and not an "address" based on > the definition in the target-uri draft. > > I believe we need to define another tag for "name" to > "address" translation. > > ## Definition of address/name in the target-uri draft ## > > A name is a moniker for an entity which refers to it in a way which > reveals nothing about where it is in a network. In SIP, tel URI > which doesn't represent the location of the entity is a name. > > An address is an identifier for an entity which describes it by its > location on the network. In SIP, the SIP URI itself is a form of > address because the host part of the URI, the only mandatory part of > the URI besides the scheme itself, indicates the location of a SIP > server that can be used to handle the request. > > ## -- ## > > In deployment, name to name translation never happens > and generally "name" to "address" translation is very > deterministic that entity doing the mapping/translation can > tag the entry with confidence. > > For example, If one sends a request to PSAP using 911, directory > assistance using 411, name(411,911 or service-URN) is translated > to an address. That address may be translated numerous times to > another address (PSAP in NYC to PSAP in NJ) but will never be > translated again to another name(911 to 411). > > Furthermore, entity/organization that is expecting to be reached > by name usually knows what name it will be reached by, so having > the ability to distinguish one service to another is probably not > necessary but having the ability to tag "name" to "address" > translation, I believe is very helpful. > > Any thoughts? > > Regards > Shida > > > On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: > >> Other idea? >> >> (I really don't care personally about "freephone"...) >> >>> -----Original Message----- >>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> Sent: Thursday, September 24, 2009 11:48 >>> To: Audet, Francois (SC100:3055); Elwell, John; Shida >>> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >>> Dean Willis; Elwell, John; Keith Drage >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>> >>> Yes got that, but that does not justify a service specific >>> tag in 4244bis. >>> /hans erik >>> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Mon Oct 19 00:12:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8240128B23E for ; Mon, 19 Oct 2009 00:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0665NLZxW7cL for ; Mon, 19 Oct 2009 00:12:42 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 4EB5228C0D8 for ; Mon, 19 Oct 2009 00:12:41 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9J7CcpX031520; Mon, 19 Oct 2009 09:12:38 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J7CbYv016554; Mon, 19 Oct 2009 09:12:37 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Mon, 19 Oct 2009 09:12:36 +0200 From: "Elwell, John" To: =?iso-8859-1?Q?Fran=E7ois_AUDET?= , "Shida Schubert" Date: Mon, 19 Oct 2009 09:12:35 +0200 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcpQAH+z22T+G0hwSXOZNMsuIzNH3wAit8ug Message-ID: <7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com> In-Reply-To: <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox , "sipcore@ietf.org" , Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 07:12:43 -0000 But in actual fact, any E.164 number is a name, so the tag would apply to a= ny E.164 to SIP URI translation. Is this helpful? John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET > Sent: 18 October 2009 15:37 > To: Shida Schubert > Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean=20 > Willis; ELWELL John; Keith Drage > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > This is quite an interesting idea. Probably wider in scope than =20 > History-Info, but it sounds like a good way to tackle the problem. >=20 > On Oct 18, 2009, at 24:16 , Shida Schubert wrote: >=20 > > > > The reason why current use of "mp" tag is not > > semantically correct for freephone, is because Service-URN > > and free-phone is a "name" and not an "address" based on > > the definition in the target-uri draft. > > > > I believe we need to define another tag for "name" to > > "address" translation. > > > > ## Definition of address/name in the target-uri draft ## > > > > A name is a moniker for an entity which refers to it in a=20 > way which > > reveals nothing about where it is in a network. In SIP, tel URI > > which doesn't represent the location of the entity is a name. > > > > An address is an identifier for an entity which describes=20 > it by its > > location on the network. In SIP, the SIP URI itself is a form of > > address because the host part of the URI, the only=20 > mandatory part of > > the URI besides the scheme itself, indicates the location of a SIP > > server that can be used to handle the request. > > > > ## -- ## > > > > In deployment, name to name translation never happens > > and generally "name" to "address" translation is very > > deterministic that entity doing the mapping/translation can > > tag the entry with confidence. > > > > For example, If one sends a request to PSAP using 911, directory > > assistance using 411, name(411,911 or service-URN) is translated > > to an address. That address may be translated numerous times to > > another address (PSAP in NYC to PSAP in NJ) but will never be > > translated again to another name(911 to 411). > > > > Furthermore, entity/organization that is expecting to be reached > > by name usually knows what name it will be reached by, so having > > the ability to distinguish one service to another is probably not > > necessary but having the ability to tag "name" to "address" > > translation, I believe is very helpful. > > > > Any thoughts? > > > > Regards > > Shida > > > > > > On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: > > > >> Other idea? > >> > >> (I really don't care personally about "freephone"...) > >> > >>> -----Original Message----- > >>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > >>> Sent: Thursday, September 24, 2009 11:48 > >>> To: Audet, Francois (SC100:3055); Elwell, John; Shida > >>> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; > >>> Dean Willis; Elwell, John; Keith Drage > >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >>> > >>> Yes got that, but that does not justify a service specific > >>> tag in 4244bis. > >>> /hans erik > >>> > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Mon Oct 19 02:38:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E7928C0F1 for ; Mon, 19 Oct 2009 02:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoo75I8wELBq for ; Mon, 19 Oct 2009 02:38:41 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 25CEA28C0EC for ; Mon, 19 Oct 2009 02:38:40 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J9cjAr029824; Mon, 19 Oct 2009 11:38:45 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9J9ciuQ021634; Mon, 19 Oct 2009 11:38:44 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Mon, 19 Oct 2009 11:38:44 +0200 From: "Elwell, John" To: Christer Holmberg , Adam Roach Date: Mon, 19 Oct 2009 11:38:43 +0200 Thread-Topic: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpO1MpopS8S7Fx0QDS4eCMmS6V9YgAdWMG7AFPFf9A= Message-ID: <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> <4AD8EB78.9080408@estacado.net> <4AD93139.2020304@nostrum.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (was Re: Draft new version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 09:38:42 -0000 The presence of Recv-Info: foo in an INVITE request from UA1 means UA1 is c= apable of receiving foo. The presence of Recv-Info: foo in a REGISTER reque= st from UA2 means that UA2 is capable of receiving foo. Preferentially rout= ing an INVITE request from UA1 with Recv-Info: foo to UA2 assumes that the = conjunction of UA1's ability to receive foo and UA2's ability to receive fo= o has some meaning. This may be true for some info packages, but how does a= proxy know whether it is true for foo? I think if UA1 has a preference for= a UA2 that can receive foo, UA1 needs some other way of expressing this pr= eference. Something based on RFC 3841 would make sense. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 17 October 2009 18:08 > To: Adam Roach > Cc: draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE;=20 > Gonzalo Camarillo > Subject: Re: [sipcore] WGLC comments (was Re: Draft new=20 > version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS >=20 > Hi, > =20 > >>But, I am not proposing that a proxy MUST fork based on=20 > Info Packages. > >>I only want to make sure the information is always there IF=20 > the proxy > >>wants to do it. > > > >And I am agreeing with Robert's evaluation that these are largely > >semantic-free bits wasting space in the network for no demonstrable > >benefit. > =20 > So, being able to fork based on capabilities (no matter=20 > whether they are info packages or something else) is not beneficial ? > =20 > >If a proxy declines to fork an INVITE to a registered=20 > contact on the basis of INFO packages, it is *doing* *the* *wrong*=20 > >*thing*. > =20 > I didn't say it would decline, but if it does serial forking=20 > it may give higher priority to a terminal which has=20 > registered support for certain info packages. Of course the=20 > forking decission may also be done in conjunction with=20 > criterias related to other types of capabilities. >=20 > As far as I remember, 3261 says that forking can be done=20 > pretty much based on ANY information - there is no "right" or=20 > "wrong" way from a protocol perspective. Are we now going to=20 > start telling operators how they shall do their forking? >=20 > I also think that being able to fork based on info packages=20 > fits very well into the do-what-I-say approach which we=20 > discussed during the service-id era... >=20 > Regards, >=20 > Christer >=20 > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Mon Oct 19 03:55:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79873A67E6 for ; Mon, 19 Oct 2009 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Up6fH7RTfqz for ; Mon, 19 Oct 2009 03:55:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7C0253A67AC for ; Mon, 19 Oct 2009 03:55:38 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-5f-4adc45af1b9d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 20.4C.04191.FA54CDA4; Mon, 19 Oct 2009 12:55:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 12:55:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 12:55:42 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpO1MpopS8S7Fx0QDS4eCMmS6V9YgAdWMG7AFPFf9AABB5bQA== References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Adam Roach" X-OriginalArrivalTime: 19 Oct 2009 10:55:43.0429 (UTC) FILETIME=[B45F5750:01CA50AA] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:55:39 -0000 Hi,=20 >The presence of Recv-Info: foo in an INVITE request from UA1=20 >means UA1 is capable of receiving foo. Correct. >The presence of Recv-Info: foo in a REGISTER request from UA2 means that UA2 is capable of receiving foo.=20 Correct. >Preferentially routing an INVITE request from UA1 with Recv-Info: foo to UA2 assumes that the=20 >conjunction of UA1's ability to receive foo and UA2's ability=20 >to receive foo has some meaning.=20 I guess the assumption is that if one is capable/willing to receive, it is also capable/willing to send. But, I agree that in some cases that is not true. For example, DTMF can be one-way only. But, for other types of application the information must be sent two-way in order for the application to work. >This may be true for some info packages, but how does a proxy know whether it is true for foo? That's a good point. So, maybe the way forward would be as Robert suggested: the specific Info Package defines whether a UA shall include the Info Package in the register or not. >I think if UA1 has a preference for a UA2 that can receive foo, UA1 needs some other way of expressing this preference.=20 >Something based on RFC 3841 would make sense. That would be another alternative, yes: say that an Info Package that wants this information need to register a feature tag. That of course assumes that the feature tag can be defined as part of the Info Package specification, because I don't think one should have to write a separate RFC because of the feature tag. Regards, Christer =20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 17 October 2009 18:08 > > To: Adam Roach > > Cc: draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE; Gonzalo=20 > > Camarillo > > Subject: Re: [sipcore] WGLC comments (was Re: Draft new > > version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS > >=20 > > Hi, > > =20 > > >>But, I am not proposing that a proxy MUST fork based on > > Info Packages. > > >>I only want to make sure the information is always there IF > > the proxy > > >>wants to do it. > > > > > >And I am agreeing with Robert's evaluation that these are largely=20 > > >semantic-free bits wasting space in the network for no=20 > demonstrable=20 > > >benefit. > > =20 > > So, being able to fork based on capabilities (no matter=20 > whether they=20 > > are info packages or something else) is not beneficial ? > > =20 > > >If a proxy declines to fork an INVITE to a registered > > contact on the basis of INFO packages, it is *doing* *the* *wrong* > > >*thing*. > > =20 > > I didn't say it would decline, but if it does serial forking it may=20 > > give higher priority to a terminal which has registered support for=20 > > certain info packages. Of course the forking decission may also be=20 > > done in conjunction with criterias related to other types of=20 > > capabilities. > >=20 > > As far as I remember, 3261 says that forking can be done=20 > pretty much=20 > > based on ANY information - there is no "right" or "wrong"=20 > way from a=20 > > protocol perspective. Are we now going to start telling=20 > operators how=20 > > they shall do their forking? > >=20 > > I also think that being able to fork based on info packages=20 > fits very=20 > > well into the do-what-I-say approach which we discussed during the=20 > > service-id era... > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From christer.holmberg@ericsson.com Mon Oct 19 06:11:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4243A689A for ; Mon, 19 Oct 2009 06:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Dd3TXg2YON for ; Mon, 19 Oct 2009 06:11:33 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 374D43A6857 for ; Mon, 19 Oct 2009 06:11:33 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-8c-4adc658a7a81 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 5F.CE.08816.A856CDA4; Mon, 19 Oct 2009 15:11:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 15:11:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 15:11:37 +0200 Message-ID: In-Reply-To: <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - IANA considerations Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwDrDi0A References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "SIPCORE" X-OriginalArrivalTime: 19 Oct 2009 13:11:38.0371 (UTC) FILETIME=[B118BD30:01CA50BD] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - IANA considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:11:34 -0000 Hi Robert, I want to thank you, and John, for the comments you've given. It's 7 pages in total, but I think it will improve the document even further :) As you may have noticed, I am separating comments into separate e-mail threads. >This is my biggest comment for this version and I'm taking it=20 >out of order to call attention to it. I think we've got some=20 >confusion in the IANA considerations section that we need to=20 >talk through. The document is setting up a=20 >First-Come-First-Served registry using "Specification=20 >Required" (which means that document has to exist somewhere,=20 >but not necessarily one that's been "approved" by any=20 >standards body), but we're calling such things "Standards=20 >Track" in the registration. What is it that we're really=20 >trying to set up? >Whatever it is, please align it with 3427bis. >=20 >(If the current text survives, we'll need to be very explicit=20 >with what "modified" means before this gets to IANA). >=20 >When thinking about this, we need to make sure section 7.11=20 >is aligned to the conclusion. Specifically, is it ok to have=20 >a package registered that points to a company or individual's=20 >website for the application procedures? Do you think this is something I should request agenda time to discuss at the meeting? >The edit also addressed my concern about calling out to the=20 >obsoleted INFO document for definition of behavor by leaving=20 >removing any references of a normative nature. I think the=20 >current approach will probably work, but I'm still thinking=20 >it through and encourage review from this point of view from others. I am not sure I understood correctly, but I have tried not to refer to specific procedures in the RFC. But, of course, we are not copy/pasting the RFC, so please let me know if you think there is text which is problematic. Regards, Christer =20 From christer.holmberg@ericsson.com Mon Oct 19 07:02:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CFB28C149 for ; Mon, 19 Oct 2009 07:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnOYuzFaN+4k for ; Mon, 19 Oct 2009 07:02:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 7D3BB28C1AE for ; Mon, 19 Oct 2009 07:02:38 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-fd-4adc7184fbc2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7A.DC.04191.3817CDA4; Mon, 19 Oct 2009 16:02:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 16:02:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 16:02:12 +0200 Message-ID: In-Reply-To: <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - Rest of Robert's comment Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwDsFPLw References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com> <2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , "SIPCORE" X-OriginalArrivalTime: 19 Oct 2009 14:02:13.0651 (UTC) FILETIME=[C243B630:01CA50C4] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - Rest of Robert's comment X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:02:40 -0000 =20 Hi Robert, Below are my comments on your feedback which I haven't addressed in separate e-mails. -------- >The structure of section 4.4 is a little off. It would help=20 >the logic flow to move the meaning of the last paragraph to=20 >the first of the section. Words like "Normal processing as=20 >required by [RFC3261] might require a failure response to be=20 >sent to the INFO request. If no such requirement constrains=20 >the UA, then..." Fixed. I can move the text from the last paragraph up to the first paragraph. I suggest to also move the 200-for-legacy-INFO a=20 little further up, so that the 200-response cases are first described, and then the non-200 cases.=20 -------- >I still have not reviewed the tables in 5.1 and 5.2. >Please make sure someone is on record as having done so=20 >before this is pub-requested. That said, I noticed based on=20 >looking at the diffs that "o"'s have been added for NOT and RFR. Why? >(and if it makes sense for them to be there, why didn't they=20 >also end up in SUB?). Btw - thanks for working with my=20 >suggestion leading to the m* under INF. I can't remember why the "o" was added for NOT/REF. Eric/Hadriel? Of course, REF CAN be sent within a invite dialog usage, and it is a target refresh request, so I guess that is=20 the reason why it was seen appropriate to allow to use it also for Info Package indication. However, I agree that it is probably doesn't make much sense to send Info-Package in NOT/REF, so unless someone provides me with a justification (or I find it myself) I can remove it. -------- >Section 7.1 last paragraph. I think we should ask any future=20 >packages to explicitly explain when one of the issues section >7 calls out is not applicable. I suggest replacing "unless an=20 >issue is not applicable" with "or document why an issue is=20 >not applicable". Fixed. -------- >Section 7.7 last paragraph: This MUST NOT requirement makes=20 >no sense, _especially_ for the specific case the paragraph=20 >calls out. What is the paragraph trying to accomplish? The idea behind the text is that the SIP stack does not need to be aware of the restrictions.=20 Assuming the INFO request is otherwise ok, the SIP stack can generate a 200 OK response to=20 the INFO, and the application layer will then deal with broken restrictions associated with the package. -------- >Section 8.2 ABNF: We've struggled before with the addition of=20 >new header fields to the ABNF. Trying to use / as the=20 >document currently does for extension-method does the wrong thing. Extension-method is used for adding INFO method name, not the new header fields. >I suggest we follow the approach the outbound draft took instead. >Has anybody run the ABNF in this section through an automated checker? I have been studying it very carefully, but I haven't used a checker. I can look for one. -------- >Section 11 should be titled "Security Considerations". I=20 >suggest Section 7.10 be relabelled "Info Package Security=20 >Considerations". >The first sentence from Section 11 (quoted below) is at odds=20 >with the proposed First-come-first-served registration: >"By eliminating multiple uses of INFO messages without=20 >adequate community review and by eliminating the possibility=20 >for rogue SIP UAs from confusing another User Agent by=20 >purposely sending unrelated INFO requests, we expect this=20 >document's clarification of the use of INFO to improve the=20 >security of the Internet." I guess this is related to the IANA issue you mentioned at the start of your comments. I am not sure how the text you refer to would go against the first-come-first-served mechanism, though. -------- >Why is Appendix A an appendix? I suspect that's editing legacy. >Unless there's a compeling reason to leave it as an appendix,=20 >please move it into the main body of the document. >(B and C are ok as Appendices) I can move it into the main spec. The whole document used to suffer a little from the fact that we used the justification draft as base for the mechanism, and that is also one of the reasons why I re-wrote it :) -------- >There are still several instances of using 2119 words to=20 >constrain other documents or standards work rather than=20 >constraining protocol. >There should be no 2119 words, for instance, in section 4.6. >The MUST NOT in section 7.12 is another strong example. I have had a look, and in some places I've decided to move from uppercase to lowercase. -------- >Page 5 second to last pararaph last sentence: I don't think=20 >"identical" is the word you want to use here. I suggest "analogous" >instead. Fixed. -------- >Page 9, ACK message: > * The branch parameter must be different in an ACK to a 200 > * The message needs a Max-Forwards > * The CSeq doesn't match the INVITE/200. Fixed. -------- =20 >Page 10, section 4.1 Second paragraph: >This wording is confusing. It essentially says "New things=20 >follow this specification and old things don't. New things=20 >should be prepared to act like old things when old things=20 >talk to them". This backwards-compatibility requirement is=20 >adequately captured elsewhere, I suggest deleting the paragraph. Fixed. (I assume you meant the 3rd paragraph) -------- =20 >Page 10, section 4.2 3rd paragraph: >Suggest adding "beyond its transaction" after "has no lifetime" Fixed. -------- >Page 11, section 4.3, 6th paragraph: >Suggest adding "even" as follows: "In that case, even if=20 >multipart MIME is used," Fixed. -------- >Page 12 second paragraph: Suggest adding a forward reference=20 >to the section defining the 469 response code here where the=20 >code is first mentioned. Fixed. -------- >Page 12 section 4.5 : "is normally generated by the SIP=20 >stack" goes too far. Similarly the MUST requirement in the=20 >2nd paragraph (sending a INFO) not really the constraint we=20 >need. I suggest replacing the section with this text: >"The Info Package Framework is designed to allow a SIP=20 >stack to generate a response to an INFO message without=20 >application interaction. As a result, Info Packages cannot=20 >require bodies in INFO responses, require different response=20 >codes, or otherwise require application information be placed=20 >in the response to the INFO request. If the application has=20 >information to send in the other direction, one alternative=20 >available to it is sending a new INFO request." Fixed. I did some small changes to your suggested text, and replaced the existing paragraph text with: "The Info Package framework allows a SIP stack to generate a response to an INFO request without application interaction. As a result, Info Packages cannot require bodies in INFO responses, require different response codes, or otherwise require the response to the INFO request to contain application information. If the application needs to send information in the other direction, it can send a new INFO request which contains the information." -------- >The first paragraph on page 16, last sentence says a request=20 >without an Info-Package header MUST NOT contain an=20 >Info-Package header :). >(What did it really mean to say?) Fixed. It's supposed to say: "An INFO request without an associated Info Package header MUST NOT contain an Info-Package header field,..."=20 -------- >Page 17, Section 7.3: Why is there a requirement for a name=20 >here that's separate from the header field value? The name of the package could be rather long, but the header field value would be shorter. For example, the package name could be: "Info Package for DTMF transport", while the header field value could be "infoDTMF".=20 -------- >Page 17 Section 7.4 second paragraph: This could be read to=20 >say two packages cant share the same parameter name. Can we=20 >rewrite it to avoid that misinterpretation? I suggest adding the following note: "NOTE: Info Package parameters defined for specific Info Packages may share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined."=20 -------- =20 >Why hasn't the changelog been kept up? There are at least two=20 >revisions worth of changes (the most recent will probably be=20 >pretty hard to write). The working group will need to decide=20 >whether to bring it up to date, delete the section before=20 >requesting IETF-wide review, or add a section explaining the=20 >gap in information before we proceed. Since I only did the last update, I can only speak on behalf of that. When I started to update the document based on comments I had received earlier (by you and others) I tried to keep track of the changes. However, at some point I decided to re-write most of the document, instead of trying to fix pieces here and there, but at that point I soon also realized that it would be very difficult to document the changes in a sensible way. Also, many of the previously done updates weren't valid anymore, which I why I also asked people who at any point had given feedback to take a look at the new version. -------- Nits: NOTE: I fixed most of your nits findings, so I will only show the ones where I have a comment. -------- >Page 6 3rd paragraph, first sentence should have its commas=20 >moved around or be rephrased. Suggest "If a UA supports the=20 >Info Package mechanism, it uses the Recv-Info header field,=20 >on a per-session bases, to indicate which Info Packages it is=20 >willing to receive." I agree.=20 Based on John's comments, I will try to make the session vs dialog text more consistant, but otherwise I have used your text. >Page 15 section 6 1st paragraph 1st sentence: "the and a"? Is=20 >this really two sentences that need to be teased back apart? -------- >Page 17 section 7.3 : what should "**9" be? Fixed. It shall be a reference to the "IANA Considerations" section. -------- >Page 19 end of sedction 8.2 (A very little pedantic nit): >Suggest saying "more than one Recv-Info header field name." I am not sure I agree. The text does not talk about the name of the header field, but the presence of the header field in a SIP message. -------- >Appendix C : Out of curiosity, which are the four paragraphs=20 >from the Litmus draft? Are they still here and intact? I don't know which they are, and due to the re-write I doubt they are still there intact, so I removed the sentence. I think it is enough to mention the Litmus draft. >Appendix C : I think we should delete the "My, we have been" sentence. > >Appendix C : The number of messages stats are impressive, but=20 >completely useless to the reader of an RFC once it's published. >I suggest we move that information out of the draft, into the=20 >tracker in the "protocol quality" field of the writeup. I re-wrote Annex C, and made it shorter. It now more or less only includes the >names of the individuals who have been involved in the work. NOTE: PLEASE LET ME KNOW IF YOU THINK THERE IS ANYONE WHO BELONGS TO BE MENTIONED. NOBODY HAS BEEN LEFT OUT ON PURPOSE. -------- Regards, Christer From john.elwell@siemens-enterprise.com Mon Oct 19 07:19:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841CF3A6778 for ; Mon, 19 Oct 2009 07:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKR2hYmc8Fem for ; Mon, 19 Oct 2009 07:19:14 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id E9A553A6899 for ; Mon, 19 Oct 2009 07:19:13 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9JEJI10004477; Mon, 19 Oct 2009 16:19:18 +0200 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9JEJHaH027733; Mon, 19 Oct 2009 16:19:17 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Mon, 19 Oct 2009 16:19:17 +0200 From: "Elwell, John" To: Christer Holmberg , Adam Roach Date: Mon, 19 Oct 2009 16:19:24 +0200 Thread-Topic: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpO1MpopS8S7Fx0QDS4eCMmS6V9YgAdWMG7AFPFf9AABB5bQAAHHX9g Message-ID: <7402509E63C5A145A6095D46C179A5B71477DEA7@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:19:15 -0000 Christer, What if a UA1 that is not willing to receive info package foo wants to expr= ess a preference for a UA2 that can receive INFO package foo? I agree extending caller preferences to cover this would be more work, but = just including Recv-Info in REGISTER and pretending it solves the problem s= eems wrong to me. In the past, have we ever agreed on a requirement for a UAC to be able to e= xpress a preference for a UAS that supports receiving a particular info pac= kage? I am concerned about whether this is really within the scope of this = work item, which is already in WGLC. John =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 19 October 2009 11:56 > To: Elwell, John; Adam Roach > Cc: draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE;=20 > Gonzalo Camarillo > Subject: RE: [sipcore] WGLC comments (was Re: Draft new=20 > version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS >=20 >=20 > Hi,=20 >=20 > >The presence of Recv-Info: foo in an INVITE request from UA1=20 > >means UA1 is capable of receiving foo. >=20 > Correct. >=20 > >The presence of Recv-Info: foo in a REGISTER request from UA2 means > that UA2 is capable of receiving foo.=20 >=20 > Correct. >=20 > >Preferentially routing an INVITE request from UA1 with Recv-Info: foo > to UA2 assumes that the=20 > >conjunction of UA1's ability to receive foo and UA2's ability=20 > >to receive foo has some meaning.=20 >=20 > I guess the assumption is that if one is capable/willing to=20 > receive, it > is also capable/willing to send. >=20 > But, I agree that in some cases that is not true. For=20 > example, DTMF can > be one-way only. But, for other types of application the information > must be sent two-way in order for the application to work. >=20 > >This may be true for some info packages, but how does a proxy know > whether it is true for foo? >=20 > That's a good point. >=20 > So, maybe the way forward would be as Robert suggested: the specific > Info Package defines whether a UA shall include the Info=20 > Package in the > register or not. >=20 > >I think if UA1 has a preference for a UA2 that can receive foo, UA1 > needs some other way of expressing this preference.=20 > >Something based on RFC 3841 would make sense. >=20 > That would be another alternative, yes: say that an Info Package that > wants this information need to register a feature tag. That of course > assumes that the feature tag can be defined as part of the=20 > Info Package > specification, because I don't think one should have to write=20 > a separate > RFC because of the feature tag. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > =20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 17 October 2009 18:08 > > > To: Adam Roach > > > Cc: draft-ietf-sipcore-info-events@tools.ietf.org;=20 > SIPCORE; Gonzalo=20 > > > Camarillo > > > Subject: Re: [sipcore] WGLC comments (was Re: Draft new > > > version: draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS > > >=20 > > > Hi, > > > =20 > > > >>But, I am not proposing that a proxy MUST fork based on > > > Info Packages. > > > >>I only want to make sure the information is always there IF > > > the proxy > > > >>wants to do it. > > > > > > > >And I am agreeing with Robert's evaluation that these=20 > are largely=20 > > > >semantic-free bits wasting space in the network for no=20 > > demonstrable=20 > > > >benefit. > > > =20 > > > So, being able to fork based on capabilities (no matter=20 > > whether they=20 > > > are info packages or something else) is not beneficial ? > > > =20 > > > >If a proxy declines to fork an INVITE to a registered > > > contact on the basis of INFO packages, it is *doing* *the* *wrong* > > > >*thing*. > > > =20 > > > I didn't say it would decline, but if it does serial=20 > forking it may=20 > > > give higher priority to a terminal which has registered=20 > support for=20 > > > certain info packages. Of course the forking decission=20 > may also be=20 > > > done in conjunction with criterias related to other types of=20 > > > capabilities. > > >=20 > > > As far as I remember, 3261 says that forking can be done=20 > > pretty much=20 > > > based on ANY information - there is no "right" or "wrong"=20 > > way from a=20 > > > protocol perspective. Are we now going to start telling=20 > > operators how=20 > > > they shall do their forking? > > >=20 > > > I also think that being able to fork based on info packages=20 > > fits very=20 > > > well into the do-what-I-say approach which we discussed=20 > during the=20 > > > service-id era... > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > =20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > >=20 > = From pkyzivat@cisco.com Mon Oct 19 07:22:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6BE23A67BD for ; Mon, 19 Oct 2009 07:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1LDZ3IqL9eU for ; Mon, 19 Oct 2009 07:22:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BAF2128C177 for ; Mon, 19 Oct 2009 07:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=697; q=dns/txt; s=rtpiport01001; t=1255962147; x=1257171747; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(was=20Re:=20Draft =20new=09version:draft-ietf-sipcore-info-events-01)=0D=0A =20-=20REGISTER=20and=20OPTIONS|Date:=20Mon,=2019=20Oct =202009=2010:22:25=20-0400|Message-ID:=20<4ADC7621.209080 5@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20=20Adam =20Roach=20,=20SIPCORE=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Camarillo=20 ,=0D=0A=20=20=20=20=20=20 =20=20draft-ietf-sipcore-info-events@tools.ietf.org |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20<4AD35107.6090705@ericsson.com>=09<4AD47E1C.7010302@eri csson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.c om><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com>=09=09<7 402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww 902.siemens.net>=20; bh=hH1o/uC8WkNE94uUmDv5fUnM5BreNHqohOaStMcJ6fI=; b=vzKmkmz9c7mLtW6ehsCvm4zRj3HkXrmfLLWezf1V1ZeOiG8CIjJzoiHq 0AinwybH0eVpGctklAbSa8aaW4ifgk9UZzDV7pdASysXDNAeeDdKMqn5Q 3FqNgUl1pYpsaDNMmcUZs8EBqyj1t4ZWVcCZ8GNmr00Pl6Dk0HV6fcj87 E=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4GAG8S3EpAZnwN/2dsb2JhbACDAcFJlmiEMQQ X-IronPort-AV: E=Sophos;i="4.44,585,1249257600"; d="scan'208";a="63761127" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Oct 2009 14:22:26 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9JEMQGm012859; Mon, 19 Oct 2009 14:22:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:22:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 10:22:25 -0400 Message-ID: <4ADC7621.2090805@cisco.com> Date: Mon, 19 Oct 2009 10:22:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 14:22:25.0570 (UTC) FILETIME=[949FE020:01CA50C7] Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:22:21 -0000 Christer Holmberg wrote: >> I think if UA1 has a preference for a UA2 that can receive foo, UA1 > needs some other way of expressing this preference. >> Something based on RFC 3841 would make sense. > > That would be another alternative, yes: say that an Info Package that > wants this information need to register a feature tag. That of course > assumes that the feature tag can be defined as part of the Info Package > specification, because I don't think one should have to write a separate > RFC because of the feature tag. You could define a new feature tag (e.g. "+sip.info") as part of this draft, where the possible values are info package names. Thanks, Paul From adam@nostrum.com Mon Oct 19 07:57:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0A628C1DD for ; Mon, 19 Oct 2009 07:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFIp6KTVCHI2 for ; Mon, 19 Oct 2009 07:57:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 61A5328C1DB for ; Mon, 19 Oct 2009 07:57:06 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9JEulBl083746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Oct 2009 09:56:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4ADC7E2F.20104@nostrum.com> Date: Mon, 19 Oct 2009 09:56:47 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Kyzivat References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> In-Reply-To: <4ADC7621.2090805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:57:07 -0000 [as chair] On 10/19/09 9:22 AM, Paul Kyzivat wrote: > You could define a new feature tag (e.g. "+sip.info") as part of this > draft, where the possible values are info package names. No. We're in a *second* WGLC on this document. Now is not the time to add features. What we're supposed to be doing is fixing identifiable problems with the document. If someone wants to tackle issues around INFO and rendezvous, that's grand. But we can't throw together a slapdash mechanism at the last possible moment and have any expectation that we've done it correctly. It's a new effort, and it needs to take place after we get this document out of the working group. /a From christer.holmberg@ericsson.com Mon Oct 19 10:41:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69673A68D0 for ; Mon, 19 Oct 2009 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsUJQkUJwggu for ; Mon, 19 Oct 2009 10:41:40 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C55333A67EC for ; Mon, 19 Oct 2009 10:41:36 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-f9-4adca4d6f129 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FB.7D.08816.6D4ACDA4; Mon, 19 Oct 2009 19:41:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 19:41:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Oct 2009 19:41:16 +0200 Message-ID: In-Reply-To: <4ADC7E2F.20104@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpQzHJHXsbUMIIISzuuhPXWO3vdPQAFfHRQ References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> From: "Christer Holmberg" To: "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Oct 2009 17:41:16.0997 (UTC) FILETIME=[5C4F2750:01CA50E3] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:41:42 -0000 Hi, I agree with Paul and John that a +sip.into feature tag would be the best and cleanest thing. Having said that, I do agree with Adam that we should not start adding new features to THIS document at this point. We can write a separate draft, which proposes a +sip.info feature tag.=20 So, regarding REGISTER, would people be ok to allow (by indicating "o") Recv-Info in REGISTER, but say that individual Info Packages must describe if and how to use it? I THINK that is what Robert proposed. And, are people ok with using the header in OPTIONS? OPTIONS is a generic capabiltiy mechanism, where you can insert more or less anything, so I see no reason why we should forbit Recv-Info. Regards, Christer -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 19. lokakuuta 2009 17:57 To: Paul Kyzivat Cc: Christer Holmberg; Elwell, John; SIPCORE; Gonzalo Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (was Re: Draft new version:draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS [as chair] On 10/19/09 9:22 AM, Paul Kyzivat wrote: > You could define a new feature tag (e.g. "+sip.info") as part of this=20 > draft, where the possible values are info package names. No. We're in a *second* WGLC on this document. Now is not the time to add features. What we're supposed to be doing is fixing identifiable problems with the document. If someone wants to tackle issues around INFO and rendezvous, that's grand. But we can't throw together a slapdash mechanism at the last possible moment and have any expectation that we've done it correctly.=20 It's a new effort, and it needs to take place after we get this document out of the working group. /a From adam@nostrum.com Mon Oct 19 10:55:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F133A6954 for ; Mon, 19 Oct 2009 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFKDNaUhaC1r for ; Mon, 19 Oct 2009 10:55:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7679E3A68D0 for ; Mon, 19 Oct 2009 10:55:08 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9JHt9W8097022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Oct 2009 12:55:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4ADCA7FD.3070608@nostrum.com> Date: Mon, 19 Oct 2009 12:55:09 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:55:09 -0000 [as an individual] On 10/19/09 12:41 PM, Christer Holmberg wrote: > So, regarding REGISTER, would people be ok to allow (by indicating "o") > Recv-Info in REGISTER, but say that individual Info Packages must > describe if and how to use it? I THINK that is what Robert proposed. > It sounds like a reasonable place to take things. Make sure the text clearly spells out that event packages expecting to make use of this mechanism must define how it is expected to work. > And, are people ok with using the header in OPTIONS? OPTIONS is a > generic capabiltiy mechanism, where you can insert more or less > anything, so I see no reason why we should forbit Recv-Info. > I have no problems with including it in OPTIONS. /a From john.elwell@siemens-enterprise.com Mon Oct 19 12:40:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0807628C151 for ; Mon, 19 Oct 2009 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WaRrJJhQpGi for ; Mon, 19 Oct 2009 12:40:23 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 8143528C12E for ; Mon, 19 Oct 2009 12:40:19 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9JJeKBK003096; Mon, 19 Oct 2009 21:40:20 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9JJeK3r018314; Mon, 19 Oct 2009 21:40:20 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Mon, 19 Oct 2009 21:40:19 +0200 From: "Elwell, John" To: Adam Roach , Christer Holmberg Date: Mon, 19 Oct 2009 21:40:17 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpQ5VHeZz8fqb8vTnyQycuWCxk+EgADoGQA Message-ID: <7402509E63C5A145A6095D46C179A5B71477DF43@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD35107.6090705@ericsson.com> <4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> <4ADCA7FD.3070608@nostrum.com> In-Reply-To: <4ADCA7FD.3070608@nostrum.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo, Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 19:40:25 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 19 October 2009 18:55 > To: Christer Holmberg > Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS >=20 > [as an individual] >=20 > On 10/19/09 12:41 PM, Christer Holmberg wrote: > > So, regarding REGISTER, would people be ok to allow (by=20 > indicating "o") > > Recv-Info in REGISTER, but say that individual Info Packages must > > describe if and how to use it? I THINK that is what Robert proposed. > > =20 >=20 > It sounds like a reasonable place to take things. Make sure the text=20 > clearly spells out that event packages expecting to make use of this=20 > mechanism must define how it is expected to work. [JRE] I can accept Christer's proposal, although my preference would have b= een to leave it out of REGISTER. John >=20 > > And, are people ok with using the header in OPTIONS? OPTIONS is a > > generic capabiltiy mechanism, where you can insert more or less > > anything, so I see no reason why we should forbit Recv-Info. > > =20 >=20 > I have no problems with including it in OPTIONS. >=20 > /a > = From dworley@nortel.com Mon Oct 19 14:22:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CFC3A683C for ; Mon, 19 Oct 2009 14:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMHRhnf+DEA3 for ; Mon, 19 Oct 2009 14:22:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 49E1D3A699C for ; Mon, 19 Oct 2009 14:22:16 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n9JLMK926142 for ; Mon, 19 Oct 2009 21:22:20 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 17:22:16 -0400 From: "Dale Worley" To: SIPCORE In-Reply-To: <20091018165027.4C8643A68B9@core3.amsl.com> References: <20091018165027.4C8643A68B9@core3.amsl.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 19 Oct 2009 17:22:16 -0400 Message-Id: <1255987336.3767.62.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 21:22:16.0916 (UTC) FILETIME=[3BD63940:01CA5102] Subject: Re: [sipcore] New Version Notification for draft-worley-instrument-identification-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:22:17 -0000 I've written up an internet-draft describing how the sipXecs open-source PBX identifies which telephone makes each registration, which allows us to obtain information about specific telephones rather than about AORs. For example, "SUBSCRIBE sip:~~in~0000DEADBEEF@example.net" will get the complete dialog status for the telephone with MAC address 0000DEADBEEF, even if the AORs that appear on it appear on other telephones. The mechanism works well in practice, but it's a hack, since it involves inserting the phone's MAC address into the authorization user-name field. What we want to do is use the phone's "SIP instance" URI to identify itself, but there are a number of problems involved in doing that. It doesn't look like they are particularly difficult, but they would require consensus and getting the phone vendors to bring their devices into line. See section 5 of the draft, which I have copied into the bottom of this message. The announcement of the I-D follows, and then section 5, which I want comments on. Dale On Sun, 2009-10-18 at 09:50 -0700, IETF I-D Submission Tool wrote: > A new version of I-D, draft-worley-instrument-identification-00.txt has been successfuly submitted by Dale Worley and posted to the IETF repository. > > Filename: draft-worley-instrument-identification > Revision: 00 > Title: Identifying Individual Telephone Instruments in SIP > Creation_date: 2009-10-18 > WG ID: Independent Submission > Number_of_pages: 18 > > http://www.ietf.org/id/draft-worley-instrument-identification-00.txt > > Abstract: > When requesting and reporting dialog status in SIP, users often want > to know the status of a particular telephone instrument, rather than > the status of an Address of Record (AOR). The architecture of SIP > makes it difficult to obtain the status of a telephone instrument in > a way that is convenient for use in common situations, in particular, > in an organization's PBX. This document describes a method for > identifying which telephone instrument is making each registration > request that is convenient to deploy in PBXs. This information can > be used to obtain the status of individual telephone instruments. > > Unfortunately, although the method works well in practice, it > violates separation of concerns by carrying instrument identification > information in an authentication-related field. This draft includes > a preliminary discussion of better ways to identify instruments. 5. Future Improvements As well as this method works, it is a hack that violates separation of concerns because instrument identification information is carried in a field which is intended for authentication information. This requires all elements that need to authenticate the source of a request to understand the syntax of the authentication user name. This burden is smaller for centralized systems, but in decentralized systems, there may be a large number of elements that need to authenticate requests, requiring a broad distribution of information that in principle should be encapsulated in the "user name and password" database. The philosophically ideal way to identify instruments is via the SIP "instance id". The instance id is used to support the "SIP outbound" mechanism[outbound], the GRUU mechanism[gruu], and the SIP Forum's UA configuration system[ua-config]. There are two distinct ways to use the SIP instance id to support instrument identification: 1. The instance id is carried in the "+sip.instance" field parameter of each Contact in each REGISTER request. The proxy/registrar can extract the instance id and use it to label each registration database record. Once the registrations are labelled with instrument identifications, requests can be directed to special URIs that route to the registered contacts of a specific instrument. 2. Each instrument can register a single special contact which is intended to identify the instrument as a whole rather than any line appearance on the instrument. This contact can be recognized by containing the instance id as either a component of the contact URI or as a "+sip.instance" field parameter. With this method, the functions described in this document are be implemented by sending SIP requests to this special contact. E.g., the overall dialog status of the instrument would be obtained by a dialog subscription to the special contact. A number of problems need to be overcome before the instance id can be used to provide instrument identification: 1. While the authentication user name is a baseline part of SIP and is always configurable by a PBX's provisioning system, the SIP instance id is not part of baseline SIP, and user agents need to be upgraded to support the SIP instance id. In practice, only some makes of instrument support SIP instance ids. 2. Ideally, all line appearances on an instrument would use the same instance id. Whether this is required by the RFCs is not entirely clear (probably because there has never been any reason to debate doing so). In practice, some instruments do use different instance ids for each line appearance that they register. However, since the preferred format of instance ids is a URN derived from a UUID, which is in turn based on the MAC address of the instrument, it is straightforward to extract the instrument's MAC address from each instance id, and the extracted MAC addresses of the various line appearances will be the same. 3. The PBX's provisioning system needs to be able to map instance ids into its internal instrument identities, which likely requires having the user enter the instrument identifiers into the provisioning system. It would be inconvenient to use full instance id URNs for this reason: UUID-based URNs are quite long and tedious to type. However, using the base MAC addresses of the URNs as the instrument identifiers would be convenient, as they are short enough to be convenient to enter and most SIP phones are clearly labeled with their MAC address 4. The reverse problem can happen with software-based instruments: The provisioning system needs to output an instrument identifier which can be input into the instrument, as the network interface of the hardware platform is not "owned" by the instrument, and the instrument may not be the only one on the platform. In the method of this document, doing so is relatively simple, since the instrument's interface allows the authentication user name to be entered directly by the user. To utilize the instance id, the instrument needs to allow its instance id to be configured, or else it needs to output its instance id so that it can be entered into the provisioning system. From pkyzivat@cisco.com Mon Oct 19 16:32:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E73943A69AC for ; Mon, 19 Oct 2009 16:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2lkawH7zS6L for ; Mon, 19 Oct 2009 16:32:57 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9744A3A699E for ; Mon, 19 Oct 2009 16:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4761; q=dns/txt; s=rtpiport02001; t=1255995185; x=1257204785; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20rfc4244bis:=20what=20is=20an=20AoR? |Date:=20Mon,=2019=20Oct=202009=2019:33:03=20-0400 |Message-ID:=20<4ADCF72F.3080604@cisco.com>|To:=20"Elwell ,=20John"=20|CC:=20 =3D?ISO-8859-1?Q?Fran=3DE7ois_AUDET?=3D=20,=0D=0A=20=20=20=20=20=20=20=20Shida=20Schuber t=20,=0D=0A=20=20=20=20=20=20=20=20Jona than=20Lennox=20,=0D=0A=20=20=20=20 =20=20=20=20"sipcore@ietf.org"=20,=0D =0A=20=20=20=20=20=20=20=20Hadriel=20Kaplan=20,=0D=0A=20=20=20=20=20=20=20=20Dean=20Willis =20,=0D=0A=20=20=20=20=20=20=20 =20ELWELL=20John=20,=20Keith=20D rage=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=208bit|In-Reply-To:=20<740250 9E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.s iemens.net>|References:=20<4A5FAF4E.4030901@cisco.com>=09 <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.n ortel.com>=09<8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at .com>=09<1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm 0.corp.nortel.com>=09<7402509E63C5A145A6095D46C179A5B705C 6D11D@DEMCHP99E35MSX.ww902.siemens.net>=09<1ECE0EB5038817 4790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com>=09<7 402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww 902.siemens.net>=09<1ECE0EB50388174790F9694F77522CCF203EE CA3@zrc2hxm0.corp.nortel.com>=09<9ae56b1e0909241127k6ec04 3a7vcdec27bf81bfa9c@mail.gmail.com>=09<1ECE0EB50388174790 F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com>=09<9ae56 b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com>=09 <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.n ortel.com>=09<5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at .com>=09<03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com> =20<7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35M SX.ww902.siemens.net>; bh=uKU/KEpFexDPeBUwJ27tnXtV4v0ptO/uUAgf3eQWHtI=; b=AZOGj0u/Oef4ckVbezgYiAdeBQpreSmk1sM+tgIZ6g86lliqC9AJMXrC X32AZCA3KF3eV/cFix51OprAub5ZRzpK1IdJga9IoNoaUnjZReK8l/geV usyjAKdxZgGOnAMn3YDQ++01CMZmXBDY31PXKTEprxnN/hhy3csQoo7/f I=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM+T3EpAZnwN/2dsb2JhbADDB4kZCY4Vgk6BYwQ X-IronPort-AV: E=Sophos;i="4.44,587,1249257600"; d="scan'208";a="63877601" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2009 23:33:04 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9JNX4ck015862; Mon, 19 Oct 2009 23:33:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 19:33:04 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 19:33:03 -0400 Message-ID: <4ADCF72F.3080604@cisco.com> Date: Mon, 19 Oct 2009 19:33:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com> <7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Oct 2009 23:33:03.0770 (UTC) FILETIME=[80ED1FA0:01CA5114] Cc: Jonathan Lennox , =?ISO-8859-1?Q?Fran=E7ois_AUDET?= , "sipcore@ietf.org" , Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 23:32:59 -0000 Elwell, John wrote: > But in actual fact, any E.164 number is a name, so the tag would apply to any E.164 to SIP URI translation. Is this helpful? Yes, any E.164 number is a name, even if it is embedded in a SIP uri containing a domain name. (Its quite likely the domain name doesn't reflect the "owner" of the E.164 number, just a convenient server that will hopefully figure out what to do next based on the number.) Of course, once upon a time phone numbers *were* addresses, and were routed digit by digit. But that time is over. Similarly, the domain names in SIP URIs are *name*s, not addresses. And the IP addresses are actually names too, ... What's a name and what's an address is a matter of perspective and layering. So, to go this will will require careful definition of the distinction in this context. Also, Shida said: > In deployment, name to name translation never happens That's not really true is it? IIUC, its pretty normal for a "name" like 1-800-666-1111 to be translated to another name,like 1-212-555-1234, which then must be routed to a responsible server. Thanks, Paul > John > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of François AUDET >> Sent: 18 October 2009 15:37 >> To: Shida Schubert >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean >> Willis; ELWELL John; Keith Drage >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> This is quite an interesting idea. Probably wider in scope than >> History-Info, but it sounds like a good way to tackle the problem. >> >> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: >> >>> The reason why current use of "mp" tag is not >>> semantically correct for freephone, is because Service-URN >>> and free-phone is a "name" and not an "address" based on >>> the definition in the target-uri draft. >>> >>> I believe we need to define another tag for "name" to >>> "address" translation. >>> >>> ## Definition of address/name in the target-uri draft ## >>> >>> A name is a moniker for an entity which refers to it in a >> way which >>> reveals nothing about where it is in a network. In SIP, tel URI >>> which doesn't represent the location of the entity is a name. >>> >>> An address is an identifier for an entity which describes >> it by its >>> location on the network. In SIP, the SIP URI itself is a form of >>> address because the host part of the URI, the only >> mandatory part of >>> the URI besides the scheme itself, indicates the location of a SIP >>> server that can be used to handle the request. >>> >>> ## -- ## >>> >>> In deployment, name to name translation never happens >>> and generally "name" to "address" translation is very >>> deterministic that entity doing the mapping/translation can >>> tag the entry with confidence. >>> >>> For example, If one sends a request to PSAP using 911, directory >>> assistance using 411, name(411,911 or service-URN) is translated >>> to an address. That address may be translated numerous times to >>> another address (PSAP in NYC to PSAP in NJ) but will never be >>> translated again to another name(911 to 411). >>> >>> Furthermore, entity/organization that is expecting to be reached >>> by name usually knows what name it will be reached by, so having >>> the ability to distinguish one service to another is probably not >>> necessary but having the ability to tag "name" to "address" >>> translation, I believe is very helpful. >>> >>> Any thoughts? >>> >>> Regards >>> Shida >>> >>> >>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: >>> >>>> Other idea? >>>> >>>> (I really don't care personally about "freephone"...) >>>> >>>>> -----Original Message----- >>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>>> Sent: Thursday, September 24, 2009 11:48 >>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida >>>>> Schubert; Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; >>>>> Dean Willis; Elwell, John; Keith Drage >>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>>>> >>>>> Yes got that, but that does not justify a service specific >>>>> tag in 4244bis. >>>>> /hans erik >>>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Oct 19 23:12:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17FE3A65A6 for ; Mon, 19 Oct 2009 23:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN7Y2lLtcQQv for ; Mon, 19 Oct 2009 23:12:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 712543A672E for ; Mon, 19 Oct 2009 23:12:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-45-4add54e8dc53 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 84.3E.04191.8E45DDA4; Tue, 20 Oct 2009 08:12:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 08:12:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 08:12:51 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477DF43@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpQ5VHeZz8fqb8vTnyQycuWCxk+EgADoGQAABXyMwA= References: <4AD35107.6090705@ericsson.com><4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com><7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> <4ADCA7FD.3070608@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DF43@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Adam Roach" X-OriginalArrivalTime: 20 Oct 2009 06:12:52.0040 (UTC) FILETIME=[5B0CA480:01CA514C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 06:12:51 -0000 Hi,=20 >>>So, regarding REGISTER, would people be ok to allow (by indicating "o") >>>Recv-Info in REGISTER, but say that individual Info Packages must=20 >>>describe if and how to use it? I THINK that is what Robert proposed. >>> =20 >>=20 >>It sounds like a reasonable place to take things. Make sure the text=20 >>clearly spells out that event packages expecting to make use of this=20 >>mechanism must define how it is expected to work. >[JRE] I can accept Christer's proposal, although my preference would have been to leave it out of REGISTER. Would the following text be ok? "This document allows a UA to insert a Recv-Info header field in a REGISTER request. However, a UA SHALL NOT include a header value for a specfic Info Package unless the specific Info Package specification describes the how the header field value is to be intepreted and used by the registrar, e.g. for forking decissions. NOTE: Rather than using the Recv-Info header field for forking decissions, it is recommended to use more appropriate mechanisms, e.g. based on RFC 3840." Regards, Christer From john.elwell@siemens-enterprise.com Mon Oct 19 23:33:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17AE83A67F3 for ; Mon, 19 Oct 2009 23:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.79 X-Spam-Level: X-Spam-Status: No, score=-5.79 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCuU9fB18+uc for ; Mon, 19 Oct 2009 23:33:39 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id E98773A67A1 for ; Mon, 19 Oct 2009 23:33:38 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9K6Xer6024845; Tue, 20 Oct 2009 08:33:40 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9K6XdwF022276; Tue, 20 Oct 2009 08:33:39 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Tue, 20 Oct 2009 08:33:38 +0200 From: "Elwell, John" To: Christer Holmberg , Adam Roach Date: Tue, 20 Oct 2009 08:33:37 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpQ5VHeZz8fqb8vTnyQycuWCxk+EgADoGQAABXyMwAAALiB8A== Message-ID: <7402509E63C5A145A6095D46C179A5B71477DF60@DEMCHP99E35MSX.ww902.siemens.net> References: <4AD35107.6090705@ericsson.com><4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com><7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> <4ADCA7FD.3070608@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DF43@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo, Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 06:33:40 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 20 October 2009 07:13 > To: Elwell, John; Adam Roach > Cc: Paul Kyzivat; SIPCORE; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: RE: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS >=20 >=20 > Hi,=20 >=20 > >>>So, regarding REGISTER, would people be ok to allow (by indicating > "o") > >>>Recv-Info in REGISTER, but say that individual Info Packages must=20 > >>>describe if and how to use it? I THINK that is what Robert=20 > proposed. > >>> =20 > >>=20 > >>It sounds like a reasonable place to take things. Make sure=20 > the text=20 > >>clearly spells out that event packages expecting to make=20 > use of this=20 > >>mechanism must define how it is expected to work. > >[JRE] I can accept Christer's proposal, although my preference would > have been to leave it out of REGISTER. >=20 > Would the following text be ok? >=20 > "This document allows a UA to insert a Recv-Info header field in a > REGISTER request. However, a UA SHALL NOT include a header value for a > specfic Info Package unless the specific Info Package specification > describes the how the header field value is to be intepreted=20 > and used by > the registrar, e.g. for forking decissions. >=20 > NOTE: Rather than using the Recv-Info header field for forking > decissions, it is recommended to use more appropriate mechanisms, e.g. > based on RFC 3840." [JRE] First I don't think "forking decisions" is the correct term. I think = what we are talking about here is "determining request targets" (see 16.5 o= f RFC 3261). Such determinations may or may not lead to forking, but that i= s irrelevant here. Also a nit: change "the how the" to "how the". Otherwise this formulation seems OK. John >=20 > Regards, >=20 > Christer > = From christer.holmberg@ericsson.com Mon Oct 19 23:43:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0113F3A67A1 for ; Mon, 19 Oct 2009 23:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k380idbdk+dl for ; Mon, 19 Oct 2009 23:43:04 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9C5963A683D for ; Mon, 19 Oct 2009 23:43:03 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-76-4add5bfd53f9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A5.D4.08816.DFB5DDA4; Tue, 20 Oct 2009 08:43:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 08:41:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 08:41:56 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477DF60@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS Thread-Index: AcpQ5VHeZz8fqb8vTnyQycuWCxk+EgADoGQAABXyMwAAALiB8AAAZATg References: <4AD35107.6090705@ericsson.com><4AD47E1C.7010302@ericsson.com><2CDB6AB1-4A06-4294-BAFE-A86C22D16167@nostrum.com><4AD8EB78.9080408@estacado.net><4AD93139.2020304@nostrum.com><7402509E63C5A145A6095D46C179A5B71477DD9F@DEMCHP99E35MSX.ww902.siemens.net> <4ADC7621.2090805@cisco.com> <4ADC7E2F.20104@nostrum.com> <4ADCA7FD.3070608@nostrum.com> <7402509E63C5A145A6095D46C179A5B71477DF43@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B71477DF60@DEMCHP99E35MSX.ww902.s iemens.n et> From: "Christer Holmberg" To: "Elwell, John" , "Adam Roach" X-OriginalArrivalTime: 20 Oct 2009 06:41:57.0615 (UTC) FILETIME=[6B7E3FF0:01CA5150] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - REGISTER and OPTIONS X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 06:43:05 -0000 Hi, >>Would the following text be ok? >>=20 >>"This document allows a UA to insert a Recv-Info header field in a=20 >>REGISTER request. However, a UA SHALL NOT include a header value for a >>specfic Info Package unless the specific Info Package specification=20 >>describes the how the header field value is to be intepreted and used=20 >>by the registrar, e.g. for forking decissions. >>=20 >>NOTE: Rather than using the Recv-Info header field for forking=20 >>decissions, it is recommended to use more appropriate mechanisms, e.g. >>based on RFC 3840." >[JRE] First I don't think "forking decisions" is the correct=20 >term. I think what we are talking about here is "determining=20 >request targets" (see 16.5 of RFC 3261). Such determinations=20 >may or may not lead to forking, but that is irrelevant here. >=20 >Also a nit: change "the how the" to "how the". >=20 >Otherwise this formulation seems OK. New text: "This document allows a UA to insert a Recv-Info header field in a REGISTER request. However, a UA SHALL NOT include a header value for=20 a specfic Info Package unless the specific Info Package specification describes how the header field value shall be intepreted and used=20 by the registrar, e.g. in order to determine request targets. NOTE: Rather than using the Recv-Info header field in order to determine request targets, it is recommended to use more appropriate mechanisms, e.g. based on RFC 3840." I also did some changes to the OPTIONS text, in order to address Robert's comment about "ignorning" the infomation in OPTIONS: "If a UA sends an OPTIONS request, or a response, the UA SHALL include Recv-Info header field in the message, and list the Info Packages that it supports to receive. =20 NOTE: As for any other capability and extension, for a specific dialog UAs need to indicate which Info Packages they are willing to receive within that dialog." Regards, Christer From christer.holmberg@ericsson.com Tue Oct 20 02:58:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A616A3A6982 for ; Tue, 20 Oct 2009 02:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEaF+WKxmHBv for ; Tue, 20 Oct 2009 02:57:59 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 94DC53A67E1 for ; Tue, 20 Oct 2009 02:57:58 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-79-4add89aea57f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4B.BA.24026.EA98DDA4; Tue, 20 Oct 2009 11:58:06 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:57:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 11:57:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfA= From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 20 Oct 2009 09:57:14.0992 (UTC) FILETIME=[B3981700:01CA516B] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:58:00 -0000 =20 Hi, Below are my comments on the feedback from John. >1. I think the document would benefit from having a definition of Info=20 >Package at some point early on. In section 1 we have "This document=20 >defines a mechanism, using Info Packages, which provides the=20 >possibility for UAs to indicate what INFO usages they support, and to=20 >define content syntax and semantics for the data transported in the=20 >INFO messages.", but that describes the mechanism, rather than defining Info package. As a starter, how about something like: >"A specified usage of the SIP INFO method, detailing the format and=20 >semantics of information transported." Sounds ok. Need to think where to put the text. ----------- >2. In several places in the document (e.g., Abstract, section 1), it=20 >talks about receiving Info Packages, but I think that is incorrect.=20 >Shouldn't it really be worded along the lines of receiving information=20 >within the context of an Info Package? (c.f., RFC 3265, where we don't receive event packages in NOTIFY >requests, we receive events). I guess an alternative is to talk about "receiving information associated with an Info Package". It would be more words, though.. ----------- >3. Was there a reason why we decided to use "Recv-Info: nil" rather=20 >than simply "Recv-Info:" if not willing to receive? There was a discussion about that at some point, but I don't remember the details. At the end of the day, I assume it's just a beauty contest. I agree an empty header would maybe be more aligned with how we use other headers, though. ----------- >4. Although much of the document talks about INFO within the context of >an invite dialog usage, there are many places that mention session,=20 >which seems inconsistent. Session is used early in section 1, but that=20 >is probably reasonable, as it describes the basic capability of SIP.=20 >However, later we have "INFO messages are always part of, and share the >fate of, an invite dialog usage. INFO message can not be sent as part=20 >of other dialog usages, and they can not be sent outside an existing session." >I cannot rationalise this mixture of invite dialog usage and session in >the same sentence. In this particular case, I don't see what value "and >they can not be sent outside an existing session" adds. I will remove that particular sentence, and I will try to make the usage of dialog versus session more consistent. ----------- >Then later: >"which Info Packages it is willing to receive, on a per-session basis" >and >"during the lifetime of the invite dialog usage of the session" >What is "dialog usage of the session"? I changed to "on a per-dialog basis" and removed "of the session". ----------- >And so on. We should decide whether to talk about INFO being used in the context of a session or of an invite dialog usage and use that terminology consistently. I agree. As you said, there may be places where session IS more appropriate, but generally I think we should talk about dialogs. ----------- >5. I think it has already been questioned why we use Recv-Info in a=20 >REGISTER request. Forking decisions are based on RFC 3840 UA=20 >capabilities, and if decisions need to be made based on Info Package=20 >support, we should extend that mechanism. Also, the semantics of=20 >Recv-Info are that it indicates packages it is willing to receive. The=20 >presence of a package in Recv-Info in an INVITE request does NOT convey >any meaning about wanting to select a UAS that can receive that same package. See separate thread. ----------- >6. In the example in 3.6: >"Since the UAS does not support Info Package P, the UAC decides to=20 >indicate in the ACK request that it is only willing to receive Info=20 >Package R, which the UAS also indicated support of." >Whilst this is certainly legitimate behaviour (a UA can change its mind about >what it wishes to receive at any time), isn't there a danger with this example >of implying that a UA should limit what it is prepared to receive to what the >peer UA has indicated it is willing to receive? I don't think this aspect of the >example is particularly helpful. I was thinking about the same thing when I re-wrote the document. I removed the "limit stuff" from the ACK.=20 In addition, I've moved the example to section 10, as you requested in another comment. ----------- >7. In 4.2: "If a UA receives an INFO >request outside an existing dialog, the UA MUST response with a 481=20 >Call Does Not Exist error response." >What if INFO request is received within the context of a dialog but a=20 >dialog for which there is no invite usage? >But I see that is covered in 4.4. Shouldn't both conditions be covered=20 >in 4.4, rather than one in 4.2 and the other in 4.4? Yes. I moved the particular sentence from 4.2 to 4.4. ----------- >8. In 4.3: "The application data associated with an Info Package SHOULD >be carried as a payload in the message body of the INFO request, unless >the information can be retrieved from a SIP header field." >I don't remember discussing this exception. What sort of thing do we have in >mind? The idea is that if there is an existing header field which can be used to carry information associated with an Info Package, that header field can be used - it is not mandatory to send the same information in the message body. A simple example is when the application needs information on what time the INFO request was sent. I believe that information can be carried in a header filed, so the information does not need to be in the message body. ----------- >9. In 4.3 "In that case, if multipart MIME is used, the UA does not=20 >need to insert an 'Info-Package' header value for the individual body parts." >Does this mean it doesn't need to have a Content-Disposition header=20 >field associated with individual body parts? The specifications for the individual body parts (some of which may of course be defined as part of the particular Info-Package specification) shall define how/if C-D is used for those body parts. The Info Package mechanism as such does not change those rules. ----------- >10. In 4.4 "If a UA receives an INFO request, that carries a message=20 >body that the UA does not support, and support of the message body is=20 >required in the Content-Disposition header field, the UA MUST send a=20 >415 Unsupported Media Type response. If support of the message body is >optional, the UA MUST send a 200 OK response even if the UA does not=20 >support the message body." >I am confused. In 4.3 it says that Content-Disposition has the value "Info->Package", so how can it indicate support required/not required? >In addition, this paragraph should cover body parts, not just bodies. You can also have a handling parameter in C-D, which indicates whether support is required or not. However, I think the paragraph is just copying normal SIP procedures, so I think we can remove it. ----------- >11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and in REFER >request? These doesn't related to invite dialog usages. See separate thread. ----------- >12. In 5.2.2 "This document adds Recv-Info to the definition of the=20 >element "general-header" in the SIP [RFC3261] message grammar" >I can't find "general-header" in RFC 3261. It shall be message-header, as for the Info-Package header field. ----------- >13. In section 6 "An INFO request associated with an Info Package MUST >contain a Info-Package header field." >Since section 6 deals with "Legacy INFO Usage", this is not the place to make >a normative statement concerning Info Packages. Instead it would be >acceptable to mention what is mandated elsewhere (section 4). The reason for the sentence is to really point out the difference between a legacy INFO request and a I-P INFO request.=20 But, I can modify the text related to Info Package usage to become less normative: "As described in section 4, an INFO request associated with an Info Package always contains an Info-Package header field. A legacy INFO request MUST NOT contain an Info-Package header field." ----------- >14. In section 7.7 "If Info Package restrictions are violated (i.e. if=20 >overlapping INFO requests are not allowed for an Info Package, but a UA >still receives overlapping requests), the UA MUST NOT reject such requests. " >This is in the section on Info Package Usage Restrictions. Such a=20 >normative statement on UA behaviour should occur in section 4. It can=20 >then be mentioned (informatively) in 7.7. I re-wrote the paragraph in a less normative way: "As the SIP stack may not be aware of Info Package specific restrictions, it cannot be=20 assumed that overlapping requests would be rejected. As defined in section 4.4, in most cases=20 a 200 OK response will be sent for the INFO request. The application logic associated with the=20 Info Package needs to handle situations which can occur due to overlapping requests." ----------- >15. "5.2.2. Recv-Info header field" >This occurs within section 5 "Formal INFO method definition", but has=20 >nothing to do with the INFO method. >Furthermore, I am not keen on the separation between the method and=20 >header field descriptions in 5 and the ABNF for these in section 8.=20 >Maybe 8 could be moved to directly after 5. I moved section 8 after 5. In addition, I changed section 5.2 into a new section 6, to separate the method definition from the header field definitions. ----------- >16. In 9.5: "Please add the following registration to the=20 >Content-Disposition registry. The description suitable for the IANA registry is as follows. >The payload of the message carrying this Content-Disposition header=20 >field value is the payload of an Info Package" >This text fails to state the value that is being registered. I re-wrote the section: "Please add the following new header field value to the Content-Disposition registry. Name: info-package Description: the body contains information associated with an Info Package Reference: RFCXXXX" ----------- >17. Section 10 gives examples of the INFO method, whereas section 3.6 gives an example of the Recv-Info header field. >It would make sense either to have all examples in one place or to have all examples in the sections to which they relate. I moved all examples to Section 10. ----------- 18. "11. Modifications to SIP Change Process" This is a strange title. The contents look like they constitute a Security Considerations section. I think this is old text which was useful in the justification phase, but is not needed anymore.=20 I will take a second look at it, possible move something to the Security Considerations section,=20 and remove the rest of the section. Maybe some text can also be put in the introduction of the document, where we describe the advantage of using Info Packages. ----------- >19. In B.2: "QSIG uses Content-Type to identify QSIG protocol elements in an=20 >INFO message. See RFC4497 [RFC4497]." >I am sure I made this comment before. RFC 4497 does NOT cover the=20 >conveyance of QSIG in INFO (it covers interworking between SIP and QSIG).=20 >The conveyance of QSIG in INFO is covered by Standard ECMA-355 (the IETF never adopted this work). Ok, so I guess we'll need to replace the RFC reference with the ECMA reference. ----------- >20. In 4.1 "It also describes how an UA can indicate support of Info Packages in OPTIONS requests and during registration." >Wasn't this already described in section 3? I removed the sentence from 4.1. ----------- Regards, Christer From christer.holmberg@ericsson.com Tue Oct 20 03:51:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93AE3A6874 for ; Tue, 20 Oct 2009 03:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjzPAcfIG55A for ; Tue, 20 Oct 2009 03:51:52 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A0FE23A6822 for ; Tue, 20 Oct 2009 03:51:47 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-25-4add9644ae36 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FE.3A.04191.4469DDA4; Tue, 20 Oct 2009 12:51:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 12:50:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 12:50:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAACGYywA== References: From: "Christer Holmberg" To: "Christer Holmberg" , "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 20 Oct 2009 10:50:58.0084 (UTC) FILETIME=[34B4E640:01CA5173] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 10:51:54 -0000 Hi, Just a small correction. The "Modifications to SIP Change Process" section IS the "Security Considerations" section, and will be renamed. Nothing will be thrown away. I was looking at the wrong section... Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 20. lokakuuta 2009 12:57 > To: Elwell, John; SIPCORE > Cc: Adam Roach; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) -John E's comments >=20 >=20 > =20 > Hi, >=20 > Below are my comments on the feedback from John. >=20 > >1. I think the document would benefit from having a=20 > definition of Info=20 > >Package at some point early on. In section 1 we have "This document=20 > >defines a mechanism, using Info Packages, which provides the=20 > >possibility for UAs to indicate what INFO usages they=20 > support, and to=20 > >define content syntax and semantics for the data transported in the=20 > >INFO messages.", but that describes the mechanism, rather=20 > than defining > Info package. As a starter, how about something like: > >"A specified usage of the SIP INFO method, detailing the format and=20 > >semantics of information transported." >=20 > Sounds ok. Need to think where to put the text. >=20 > ----------- >=20 > >2. In several places in the document (e.g., Abstract, section 1), it=20 > >talks about receiving Info Packages, but I think that is incorrect. > >Shouldn't it really be worded along the lines of receiving=20 > information=20 > >within the context of an Info Package? (c.f., RFC 3265,=20 > where we don't > receive event packages in NOTIFY >requests, we receive events). >=20 > I guess an alternative is to talk about "receiving information > associated with an Info Package". It would be more words, though.. >=20 >=20 > ----------- >=20 > >3. Was there a reason why we decided to use "Recv-Info: nil" rather=20 > >than simply "Recv-Info:" if not willing to receive? >=20 > There was a discussion about that at some point, but I don't remember > the details. At the end of the day, I assume it's just a=20 > beauty contest. >=20 > I agree an empty header would maybe be more aligned with how we use > other headers, though. >=20 > ----------- >=20 >=20 > >4. Although much of the document talks about INFO within the=20 > context of >=20 > >an invite dialog usage, there are many places that mention session,=20 > >which seems inconsistent. Session is used early in section=20 > 1, but that=20 > >is probably reasonable, as it describes the basic capability of SIP.=20 > >However, later we have "INFO messages are always part of,=20 > and share the >=20 > >fate of, an invite dialog usage. INFO message can not be=20 > sent as part=20 > >of other dialog usages, and they can not be sent outside an existing > session." > >I cannot rationalise this mixture of invite dialog usage and=20 > session in >=20 > >the same sentence. In this particular case, I don't see what=20 > value "and >=20 > >they can not be sent outside an existing session" adds. >=20 > I will remove that particular sentence, and I will try to=20 > make the usage > of dialog versus session more consistent. >=20 > ----------- >=20 > >Then later: > >"which Info Packages it is willing to receive, on a=20 > per-session basis" > >and > >"during the lifetime of the invite dialog usage of the session" > >What is "dialog usage of the session"? >=20 > I changed to "on a per-dialog basis" and removed "of the session". >=20 > ----------- >=20 > >And so on. We should decide whether to talk about INFO being used in > the context of a session or of an invite dialog usage and use that > terminology consistently. >=20 > I agree. As you said, there may be places where session IS more > appropriate, but generally I think we should talk about dialogs. >=20 > ----------- >=20 > >5. I think it has already been questioned why we use Recv-Info in a=20 > >REGISTER request. Forking decisions are based on RFC 3840 UA=20 > >capabilities, and if decisions need to be made based on Info Package=20 > >support, we should extend that mechanism. Also, the semantics of=20 > >Recv-Info are that it indicates packages it is willing to=20 > receive. The=20 > >presence of a package in Recv-Info in an INVITE request does=20 > NOT convey >=20 > >any meaning about wanting to select a UAS that can receive that same > package. >=20 > See separate thread. >=20 > ----------- >=20 > >6. In the example in 3.6: > >"Since the UAS does not support Info Package P, the UAC decides to=20 > >indicate in the ACK request that it is only willing to receive Info=20 > >Package R, which the UAS also indicated support of." > >Whilst this is certainly legitimate behaviour (a UA can=20 > change its mind > about >what it wishes to receive at any time), isn't there a=20 > danger with > this example >of implying that a UA should limit what it is=20 > prepared to > receive to what the >peer UA has indicated it is willing to receive? I > don't think this aspect of the >example is particularly helpful. >=20 > I was thinking about the same thing when I re-wrote the document. >=20 > I removed the "limit stuff" from the ACK.=20 >=20 > In addition, I've moved the example to section 10, as you requested in > another comment. >=20 > ----------- >=20 > >7. In 4.2: "If a UA receives an INFO > >request outside an existing dialog, the UA MUST response with a 481=20 > >Call Does Not Exist error response." > >What if INFO request is received within the context of a=20 > dialog but a=20 > >dialog for which there is no invite usage? > >But I see that is covered in 4.4. Shouldn't both conditions=20 > be covered=20 > >in 4.4, rather than one in 4.2 and the other in 4.4? >=20 > Yes. I moved the particular sentence from 4.2 to 4.4. >=20 > ----------- >=20 > >8. In 4.3: "The application data associated with an Info=20 > Package SHOULD >=20 > >be carried as a payload in the message body of the INFO=20 > request, unless >=20 > >the information can be retrieved from a SIP header field." > >I don't remember discussing this exception. What sort of thing do we > have in >mind? >=20 > The idea is that if there is an existing header field which=20 > can be used > to carry information associated with an Info Package, that=20 > header field > can be used - it is not mandatory to send the same information in the > message body. >=20 > A simple example is when the application needs information on=20 > what time > the INFO request was sent. I believe that information can be=20 > carried in > a header filed, so the information does not need to be in the message > body. >=20 > ----------- >=20 > >9. In 4.3 "In that case, if multipart MIME is used, the UA does not=20 > >need to insert an 'Info-Package' header value for the individual body > parts." > >Does this mean it doesn't need to have a Content-Disposition header=20 > >field associated with individual body parts? >=20 > The specifications for the individual body parts (some of which may of > course be defined as part of the particular Info-Package=20 > specification) > shall define how/if C-D is used for those body parts. The Info Package > mechanism as such does not change those rules. >=20 > ----------- >=20 > >10. In 4.4 "If a UA receives an INFO request, that carries a message=20 > >body that the UA does not support, and support of the=20 > message body is=20 > >required in the Content-Disposition header field, the UA MUST send a=20 > >415 Unsupported Media Type response. If support of the=20 > message body is >=20 > >optional, the UA MUST send a 200 OK response even if the UA does not=20 > >support the message body." > >I am confused. In 4.3 it says that Content-Disposition has the value > "Info->Package", so how can it indicate support required/not required? > >In addition, this paragraph should cover body parts, not just bodies. >=20 > You can also have a handling parameter in C-D, which indicates whether > support is required or not. >=20 > However, I think the paragraph is just copying normal SIP=20 > procedures, so > I think we can remove it. >=20 > ----------- >=20 > >11. In 5.2, why is Recv-Info allowed in NOTIFY=20 > request/response and in > REFER >request? These doesn't related to invite dialog usages. >=20 > See separate thread. >=20 > ----------- >=20 > >12. In 5.2.2 "This document adds Recv-Info to the definition of the=20 > >element "general-header" in the SIP [RFC3261] message grammar" > >I can't find "general-header" in RFC 3261. >=20 > It shall be message-header, as for the Info-Package header field. >=20 > ----------- >=20 > >13. In section 6 "An INFO request associated with an Info=20 > Package MUST > >contain a Info-Package header field." > >Since section 6 deals with "Legacy INFO Usage", this is not the place > to make >a normative statement concerning Info Packages. Instead it > would be >acceptable to mention what is mandated elsewhere=20 > (section 4). >=20 > The reason for the sentence is to really point out the difference > between a legacy INFO request and a I-P INFO request.=20 >=20 > But, I can modify the text related to Info Package usage to=20 > become less > normative: >=20 > "As described in section 4, an INFO request associated with an Info > Package always contains an Info-Package header field. A legacy INFO > request MUST NOT contain an Info-Package header field." >=20 > ----------- >=20 > >14. In section 7.7 "If Info Package restrictions are=20 > violated (i.e. if=20 > >overlapping INFO requests are not allowed for an Info=20 > Package, but a UA >=20 > >still receives overlapping requests), the UA MUST NOT reject such > requests. " > >This is in the section on Info Package Usage Restrictions. Such a=20 > >normative statement on UA behaviour should occur in section=20 > 4. It can=20 > >then be mentioned (informatively) in 7.7. >=20 > I re-wrote the paragraph in a less normative way: >=20 > "As the SIP stack may not be aware of Info Package specific > restrictions, it cannot be=20 > assumed that overlapping requests would be rejected. As defined in > section 4.4, in most cases=20 > a 200 OK response will be sent for the INFO request. The application > logic associated with the=20 > Info Package needs to handle situations which can occur due to > overlapping requests." >=20 > ----------- >=20 > >15. "5.2.2. Recv-Info header field" > >This occurs within section 5 "Formal INFO method=20 > definition", but has=20 > >nothing to do with the INFO method. > >Furthermore, I am not keen on the separation between the method and=20 > >header field descriptions in 5 and the ABNF for these in section 8.=20 > >Maybe 8 could be moved to directly after 5. >=20 > I moved section 8 after 5. >=20 > In addition, I changed section 5.2 into a new section 6, to=20 > separate the > method definition from the header field definitions. >=20 > ----------- >=20 > >16. In 9.5: "Please add the following registration to the=20 > >Content-Disposition registry. The description suitable for the IANA > registry is as follows. > >The payload of the message carrying this Content-Disposition header=20 > >field value is the payload of an Info Package" > >This text fails to state the value that is being registered. >=20 > I re-wrote the section: >=20 > "Please add the following new header field value to the > Content-Disposition registry. >=20 > Name: info-package > Description: the body contains information associated with an Info > Package > Reference: RFCXXXX" >=20 > ----------- >=20 > >17. Section 10 gives examples of the INFO method, whereas section 3.6 > gives an example of the Recv-Info header field. > >It would make sense either to have all examples in one place=20 > or to have > all examples in the sections to which they relate. >=20 > I moved all examples to Section 10. >=20 > ----------- >=20 > 18. "11. Modifications to SIP Change Process" > This is a strange title. The contents look like they constitute a > Security Considerations section. >=20 > I think this is old text which was useful in the justification phase, > but is not needed anymore.=20 > I will take a second look at it, possible move something to=20 > the Security > Considerations section,=20 > and remove the rest of the section. >=20 > Maybe some text can also be put in the introduction of the document, > where we describe the advantage of using Info Packages. >=20 > ----------- >=20 > >19. In B.2: "QSIG uses Content-Type to identify QSIG=20 > protocol elements > in an=20 > >INFO message. See RFC4497 [RFC4497]." > >I am sure I made this comment before. RFC 4497 does NOT cover the=20 > >conveyance of QSIG in INFO (it covers interworking between SIP and > QSIG).=20 > >The conveyance of QSIG in INFO is covered by Standard ECMA-355 (the > IETF never adopted this work). >=20 > Ok, so I guess we'll need to replace the RFC reference with the ECMA > reference. >=20 > ----------- >=20 > >20. In 4.1 "It also describes how an UA can indicate support of Info > Packages in OPTIONS requests and during registration." > >Wasn't this already described in section 3? >=20 > I removed the sentence from 4.1. >=20 > ----------- >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From john.elwell@siemens-enterprise.com Tue Oct 20 05:57:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5D43A6934 for ; Tue, 20 Oct 2009 05:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkjABEPnvipP for ; Tue, 20 Oct 2009 05:57:35 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id C54923A692B for ; Tue, 20 Oct 2009 05:57:34 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9KCv2qd016856; Tue, 20 Oct 2009 14:57:03 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9KCv2Ce008235; Tue, 20 Oct 2009 14:57:02 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Tue, 20 Oct 2009 14:57:01 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Tue, 20 Oct 2009 14:56:58 +0200 Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0A== Message-ID: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Roach , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 12:57:36 -0000 Christer, Thanks for addressing my tedious comments. Just a few further remarks below= . I cut out the comments we agree on. >=20 > >2. In several places in the document (e.g., Abstract, section 1), it=20 > >talks about receiving Info Packages, but I think that is incorrect.=20 > >Shouldn't it really be worded along the lines of receiving=20 > information=20 > >within the context of an Info Package? (c.f., RFC 3265,=20 > where we don't > receive event packages in NOTIFY >requests, we receive events). >=20 > I guess an alternative is to talk about "receiving information > associated with an Info Package". It would be more words, though.. [JRE] Yes, that would work, but I am open to suggestions to shorten it, as = long as we don't resort to inaccurate formulations like we have at present. >=20 > >8. In 4.3: "The application data associated with an Info=20 > Package SHOULD > >be carried as a payload in the message body of the INFO=20 > request, unless > >the information can be retrieved from a SIP header field." > >I don't remember discussing this exception. What sort of thing do we > have in >mind? >=20 > The idea is that if there is an existing header field which=20 > can be used > to carry information associated with an Info Package, that=20 > header field > can be used - it is not mandatory to send the same information in the > message body. >=20 > A simple example is when the application needs information on=20 > what time > the INFO request was sent. I believe that information can be=20 > carried in > a header filed, so the information does not need to be in the message > body. [JRE] Sounds like a layer violation to me. Suppose a particular application= needs date/time, but the info-package decides to omit it on the basis that= the Date header field will convey this information. The application passes= the info down to the SIP stack, and expects the SIP stack to know that for= this particular info-package it must include the Date header field. Sounds= like it would be safer to include in the info anyway. Similarly, at the UA= S, the SIP stack would need to pass the contents of the received Date heade= r field up to the application. Also, what if the application data can be carried over transports other tha= n SIP, and in particular needs to be passed on transparently when SIP inter= works with some other transport (e.g., PSTN UUI)? Can it rely on that other= protocol also having date/time (or whatever other information is conveyed = in the SIP header), and can it rely on correct interworking at the gateway? I would prefer to keep it simple and say all application information associ= ated with a package be carried in a body part. >=20 > ----------- >=20 > >9. In 4.3 "In that case, if multipart MIME is used, the UA does not=20 > >need to insert an 'Info-Package' header value for the individual body > parts." > >Does this mean it doesn't need to have a Content-Disposition header=20 > >field associated with individual body parts? >=20 > The specifications for the individual body parts (some of which may of > course be defined as part of the particular Info-Package=20 > specification) > shall define how/if C-D is used for those body parts. The Info Package > mechanism as such does not change those rules. [JRE] Having re-read the paragraphs concerned, I withdraw my original comme= nt. However, just for clarification, can you confirm or deny the following? If I have multi-part, and all parts relate to info-package(s), I just need = Content-Disposition: Info-Package at the SIP level and not in the individua= l body parts. Since an INFO request is allowed to contain only one info-pac= kage, this case would apply only when a single info-package requires 2 or m= ore body parts. I suspect we probably discussed this at some point in the p= ast, and if we agreed on this possibility, then fine - I don't want to open= it up again. However, we should perhaps take a careful look at the wording= of 7.6: "The Info Package specification MUST define what type of message bodies, if any, are associated with the Info Package, and MUST refer to specifications where the syntax, semantics and MIME type of the message body is described." It says "bodies" in the first part and "body" in the second part. Also it s= hould allow for body parts. > >11. In 5.2, why is Recv-Info allowed in NOTIFY=20 > request/response and in > REFER >request? These doesn't related to invite dialog usages. >=20 > See separate thread. [JRE] I couldn't find any discussion of Recv-Info in REFER and NOTIFY. Can = you point me at a particular message in that thread? John= From pkyzivat@cisco.com Tue Oct 20 08:42:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CF228C138 for ; Tue, 20 Oct 2009 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHiQY5KlKUTl for ; Tue, 20 Oct 2009 08:42:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5A2F428C152 for ; Tue, 20 Oct 2009 08:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1508; q=dns/txt; s=sjiport03001; t=1256053329; x=1257262929; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments|Date: =20Tue,=2020=20Oct=202009=2011:42:08=20-0400|Message-ID: =20<4ADDDA50.1050704@cisco.com>|To:=20"Elwell,=20John"=20 |CC:=20Christer=20Hol mberg=20,=0D=0A=20=20=20 =20=20=20=20=20SIPCORE=20,=20Adam=20Roa ch=20,=0D=0A=20=20=20=20=20=20=20=20Go nzalo=20Camarillo=20,=0D =0A=20=20=20=20=20=20=20=20"draft-ietf-sipcore-info-event s@tools.ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding: =207bit|In-Reply-To:=20<7402509E63C5A145A6095D46C179A5B71 477E0CA@DEMCHP99E35MSX.ww902.siemens.net>|References:=20< CA9998CD4A020D418654FCDEF4E707DF0F501323@esealmw113.eemea .ericsson.se>=20<7402509E63C5A145A6095D46C179A5B71477E0CA @DEMCHP99E35MSX.ww902.siemens.net>; bh=YpL0YK81OL4Wok+KfNyUzpH5ZaVxaeaCdl/0RIiXI3E=; b=KiOj9P5nsezqg1IzieYMHqCELfYbv0lUZSjTJYTD6VsXsqJ9Ma46UDWd 9pdFjSEI6/xA174Elxs0WstqxnX9M4uZwmPyHBv7BVVduY0mdMMtrPU7v kQtZ/4wZc44/RcT/b7rMs+uWUwofQdArv+zaffO5bZo366nJj11WwExZR U=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK923UqrR7Hu/2dsb2JhbADCJpgthDEE X-IronPort-AV: E=Sophos;i="4.44,592,1249257600"; d="scan'208";a="197676366" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2009 15:42:09 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9KFg1Jv012613; Tue, 20 Oct 2009 15:42:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:42:08 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:42:07 -0400 Message-ID: <4ADDDA50.1050704@cisco.com> Date: Tue, 20 Oct 2009 11:42:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 15:42:07.0744 (UTC) FILETIME=[E16F7800:01CA519B] Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 15:42:03 -0000 Elwell, John wrote: > If I have multi-part, and all parts relate to info-package(s), I just need Content-Disposition: Info-Package at the SIP level and not in the individual body parts. Since an INFO request is allowed to contain only one info-package, this case would apply only when a single info-package requires 2 or more body parts. I suspect we probably discussed this at some point in the past, and if we agreed on this possibility, then fine - I don't want to open it up again. However, we should perhaps take a careful look at the wording of 7.6: > "The Info Package specification MUST define what type of message > bodies, if any, are associated with the Info Package, and MUST refer > to specifications where the syntax, semantics and MIME type of the > message body is described." > It says "bodies" in the first part and "body" in the second part. Also it should allow for body parts. My take on this is that an info-package must consist of a single body part in the INFO message, which itself may be a multipart. This can occur two ways: 1) it is the entire body of the INFO message. The C-D in the sip message is Info-Package. 2) the INFO message contains a multipart/mixed body which contains, as one of its immediately contained parts, a part with C-D Info-Package. In either case, the type and other rules regarding the part with C-D Info-Package is subject to specification by the definition of the individual package type. Thanks, Paul From john.elwell@siemens-enterprise.com Tue Oct 20 09:41:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4AD3A68E4 for ; Tue, 20 Oct 2009 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZJFyDxn5K1i for ; Tue, 20 Oct 2009 09:41:32 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 8EC883A6873 for ; Tue, 20 Oct 2009 09:41:29 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9KGf94n012636; Tue, 20 Oct 2009 18:41:09 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9KGf9dE015522; Tue, 20 Oct 2009 18:41:09 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Tue, 20 Oct 2009 18:41:08 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 20 Oct 2009 18:41:06 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpRm+NVRfmHdMnVQ0KZ5pWeWkBLrQABxbAQ Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> In-Reply-To: <4ADDDA50.1050704@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:41:34 -0000 Paul, Your explanation sounds reasonable. I think it requires some clarification = in both 7.6 and 4.3: - in 7.6 it should talk about a body part, which may be multipart; - in 4.3 it should talk about labelling the Info-Package body part with Con= tent-Disposition: Info-Package, this being at the SIP level if it is the so= le body part (i.e., the entire body of the SIP message). John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20 October 2009 16:42 > To: Elwell, John > Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo=20 > Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments >=20 >=20 >=20 > Elwell, John wrote: >=20 > > If I have multi-part, and all parts relate to=20 > info-package(s), I just need Content-Disposition:=20 > Info-Package at the SIP level and not in the individual body=20 > parts. Since an INFO request is allowed to contain only one=20 > info-package, this case would apply only when a single=20 > info-package requires 2 or more body parts. I suspect we=20 > probably discussed this at some point in the past, and if we=20 > agreed on this possibility, then fine - I don't want to open=20 > it up again. However, we should perhaps take a careful look=20 > at the wording of 7.6: > > "The Info Package specification MUST define what type of message > > bodies, if any, are associated with the Info Package,=20 > and MUST refer > > to specifications where the syntax, semantics and MIME=20 > type of the > > message body is described." > > It says "bodies" in the first part and "body" in the second=20 > part. Also it should allow for body parts. >=20 > My take on this is that an info-package must consist of a single body=20 > part in the INFO message, which itself may be a multipart. This can=20 > occur two ways: >=20 > 1) it is the entire body of the INFO message. The C-D in the=20 > sip message=20 > is Info-Package. >=20 > 2) the INFO message contains a multipart/mixed body which=20 > contains, as=20 > one of its immediately contained parts, a part with C-D Info-Package. >=20 > In either case, the type and other rules regarding the part with C-D=20 > Info-Package is subject to specification by the definition of the=20 > individual package type. >=20 > Thanks, > Paul > = From christer.holmberg@ericsson.com Tue Oct 20 11:53:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA1F28C119 for ; Tue, 20 Oct 2009 11:53:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6mJ+6Fu2q0U for ; Tue, 20 Oct 2009 11:53:34 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6E9CA28C117 for ; Tue, 20 Oct 2009 11:53:33 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-27-4ade073383cd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 02.69.08816.3370EDA4; Tue, 20 Oct 2009 20:53:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 20:53:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 20:53:20 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8w References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 20 Oct 2009 18:53:21.0217 (UTC) FILETIME=[98288310:01CA51B6] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:53:35 -0000 Hi,=20 >>>2. In several places in the document (e.g., Abstract, section 1), it=20 >>>talks about receiving Info Packages, but I think that is incorrect. >>>Shouldn't it really be worded along the lines of receiving >>>information within the context of an Info Package? (c.f., RFC 3265, >>>where we don't receive event packages in NOTIFY >requests, we receive events). >>=20 >>I guess an alternative is to talk about "receiving information=20 >>associated with an Info Package". It would be more words, though.. >[JRE] Yes, that would work, but I am open to suggestions to shorten it, as long as we don't resort to inaccurate formulations like we have at present. Or, we could somewhere in the beginning of the document clarify that "receive Info Package" means to receive an INFO associated with an Info Package, or something like that... --------- >>>8. In 4.3: "The application data associated with an Info >>>Package SHOULD be carried as a payload in the message body of the INFO >>>request, unless the information can be retrieved from a SIP header field." >>>I don't remember discussing this exception. What sort of thing do we >>>have in mind? >>=20 >>The idea is that if there is an existing header field which can be=20 >>used to carry information associated with an Info Package, that header >>field can be used - it is not mandatory to send the same information=20 >>in the message body. >>=20 >>A simple example is when the application needs information on what=20 >>time the INFO request was sent. I believe that information can be=20 >>carried in a header filed, so the information does not need to be in=20 >>the message body. >[JRE] Sounds like a layer violation to me. Suppose a particular application needs date/time, but the info-package decides to omit it on the basis that the Date header field will convey this information.=20 >The application passes the info down to the SIP stack, and expects the SIP stack to know that for this particular info-package it must include the Date header field. Sounds like it would be safer to=20 >include in the info anyway. Similarly, at the UAS, the SIP stack would need to pass the contents of the received Date header field up to the application. Well, maybe should clarify, and say unless the APPLICATION is able to convey the information in an existing header. But, I guess the problem then is that all stacks/APIs may not give access to all headers, and the Info Package should of course not be stack/API specific. Of course, there are some MANDATORY SIP headers which the application can assume will be present, but I doubt any of those headers would carry very much information of interest for the application. >Also, what if the application data can be carried over transports other than SIP, and in particular needs to be passed on transparently when SIP interworks with some other transport (e.g., PSTN UUI)? Can=20 >it rely on that other protocol also having date/time (or whatever other information is conveyed in the SIP header), and can it rely on correct interworking at the gateway? > >I would prefer to keep it simple and say all application information associated with a package be carried in a body part. Personally I have no problem with that. That of course means that the INFOs will always carry a message body. In reality that would probably be the case anyway, but the intention was to allow also body-free INFOs. =20 ----------- >>>9. In 4.3 "In that case, if multipart MIME is used, the UA does not=20 >>>need to insert an 'Info-Package' header value for the individual body parts." >>>Does this mean it doesn't need to have a Content-Disposition header=20 >>>field associated with individual body parts? >> >>The specifications for the individual body parts (some of which may of >>course be defined as part of the particular Info-Package specification) >>shall define how/if C-D is used for those body parts. The Info Package >>mechanism as such does not change those rules. >[JRE] Having re-read the paragraphs concerned, I withdraw my original comment. However, just for clarification, can you confirm or deny the following? >If I have multi-part, and all parts relate to info-package(s), I just need Content-Disposition: Info-Package at the SIP level and not in the individual body parts. > > >Since an INFO request is allowed to contain only one info-package, this case would apply only when a single info-package requires 2 or more body parts. I suspect we probably discussed this at some point=20 >in the past, and if we agreed on this possibility, then fine - I don't want to open it up again. However, we should perhaps take a careful look at the wording of 7.6: >"The Info Package specification MUST define what type of message >bodies, if any, are associated with the Info Package, and MUST refer >to specifications where the syntax, semantics and MIME type of the >message body is described." >It says "bodies" in the first part and "body" in the second part. Also it should allow for body parts. I'll address this in my reply to your reply to Paul's reply :) -------- >>>11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and in >>>REFER request? These doesn't related to invite dialog usages. >>=20 >>See separate thread. >[JRE] I couldn't find any discussion of Recv-Info in REFER and NOTIFY. Can you point me at a particular message in that thread? Sorry, I didn't mean that there was a separate thread dedicated to that particular issue. But, Robert had the same comment, and I addresses it in my of my replies on his comments. But, I HAVE removed Recv-Info from REF and NOT, because I can't remember why they were put there. ANYONE WHO REMEMBERS WHY THEY WERE PUT THERE, PLEASE SPEAK NOW OR FOREVER SEND YOUR REFERS WITHOUT INFO PACKAGES! :) ------- Regards, Christer From john.elwell@siemens-enterprise.com Tue Oct 20 12:07:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE613A6827 for ; Tue, 20 Oct 2009 12:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+DwN78pm-9w for ; Tue, 20 Oct 2009 12:07:21 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id CEC2F3A681E for ; Tue, 20 Oct 2009 12:07:20 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9KJ6uqW011708; Tue, 20 Oct 2009 21:06:56 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9KJ6tBL010505; Tue, 20 Oct 2009 21:06:55 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Tue, 20 Oct 2009 21:06:54 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Tue, 20 Oct 2009 21:06:53 +0200 Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAAENTmA= Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Roach , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 19:07:22 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 20 October 2009 19:53 > To: Elwell, John; SIPCORE > Cc: Gonzalo Camarillo; Adam Roach;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: RE: WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments >=20 >=20 > Hi,=20 >=20 > >>>2. In several places in the document (e.g., Abstract,=20 > section 1), it=20 > >>>talks about receiving Info Packages, but I think that is incorrect. > >>>Shouldn't it really be worded along the lines of receiving > >>>information within the context of an Info Package? (c.f., RFC 3265, > >>>where we don't receive event packages in NOTIFY >requests,=20 > we receive > events). > >>=20 > >>I guess an alternative is to talk about "receiving information=20 > >>associated with an Info Package". It would be more words, though.. > >[JRE] Yes, that would work, but I am open to suggestions to=20 > shorten it, > as long as we don't resort to inaccurate formulations like we have at > present. >=20 > Or, we could somewhere in the beginning of the document clarify that > "receive Info Package" means to receive an INFO associated=20 > with an Info > Package, or something like that... [JRE] If this would make the document more readable (in terms of avoiding l= ong formulations in many places in the document), it would at least be an i= mprovement on what we have at present. John From christer.holmberg@ericsson.com Tue Oct 20 12:46:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448CE3A6830 for ; Tue, 20 Oct 2009 12:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHgD-acm6kAR for ; Tue, 20 Oct 2009 12:46:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 002B23A680F for ; Tue, 20 Oct 2009 12:46:24 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-72-4ade13977c9e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 54.D2.24026.7931EDA4; Tue, 20 Oct 2009 21:46:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 21:45:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 21:45:52 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpRm+NVRfmHdMnVQ0KZ5pWeWkBLrQABxbAQAAWjuJA= References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 20 Oct 2009 19:45:53.0215 (UTC) FILETIME=[EEE53CF0:01CA51BD] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 19:46:26 -0000 Hi, >Your explanation sounds reasonable. I think it requires some clarification in both 7.6 and 4.3: >- in 7.6 it should talk about a body part, which may be multipart; 7.6 shall definitely be changed. It should say "body parts". "7.6. INFO Message Body The Info Package specification MUST define what type of message body parts, are associated with the Info Package, and MUST refer to specifications where the syntax, semantics and MIME type of each message body part is described." - The old text used to say "message bodies, if any", but I removed "if any" due to the change that the Info Package shall not assume on information being conveyed in SIP headers (see other e-mail). ------------- >- in 4.3 it should talk about labelling the Info-Package body part with Content-Disposition: Info-Package, this being at the SIP level if it is the sole body part (i.e., the entire body of the SIP=20 >message). Yes. Basically the text shall say that each message body part associated with the Info Package shall have a associated C-D header filed with an 'info-package' value. And, if there is only a single body part in a message the SIP level C-D header field contains the 'info-package' value. Also, 4.3 talks about "message body payloads", but I will change to "message body parts" there, to be consistent with 7.6. NOTE: The new 4.3 text below may also contain changes I've already done based on other comments: "4.3. INFO Request Message Body The purpose of the INFO request is to carry application level information between SIP UAs. The application data associated with an Info Package is carried as a payload in the message body of the INFO request.=20 An INFO request message body can contain a single body part, or multiple=20 body parts (multipart/mixed). Info Package specifications MUST describe the application level information associated with the Info Package. Message body parts MUST have a MIME type value defined. If a UA indicates that it is willing to receive a specific Info Package, it means that the UA also supports any associated message body MIME type associated with the Info Package. However, the UA MUST still indicate support of those MIME types also in the Accept header field, according to the procedures in [RFC3261]. Some SIP extensions that are orthogonal to INFO MAY insert body parts unrelated to the Info Package. UAs MUST conform to [RFC3261] as updated by body-handling [I-D.ietf-sip-body-handling] to support multipart MIME handling. Each message body part associated with an Info Package MUST contain a Content-Disposition header field with an 'Info-Package' value, in order to in an easy way distinguish payloads associated with the Info Package from other payloads.=20 If the message body only contains a single body part, the SIP level Content-Disposition header field contains an 'info-package' value. If the message body contains multiple body parts (multipart/mixed) the SIP level Content-Disposition header field does not need to include an 'info-package' value, since each body part associated with the Info Package will include a Content-Disposition header field for that specific body part. NOTE: To avoid corner cases with legacy INFO usage, the Info-Package header field is used to indicate the Info Package name, rather than to use a Content-Disposition header field parameter in order to indicate the name." ------------- Regards, Christer From pkyzivat@cisco.com Tue Oct 20 13:00:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D22B3A697C for ; Tue, 20 Oct 2009 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FXhHN98hiDc for ; Tue, 20 Oct 2009 13:00:03 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 350503A6978 for ; Tue, 20 Oct 2009 13:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5061; q=dns/txt; s=sjiport03001; t=1256068811; x=1257278411; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments|Date: =20Tue,=2020=20Oct=202009=2015:59:11=20-0400|Message-ID: =20<4ADE168F.7060303@cisco.com>|To:=20Christer=20Holmberg =20|CC:=20"Elwell,=20John "=20,=0D=0A=20=20=20 =20=20=20=20=20SIPCORE=20,=20Adam=20Roa ch=20,=0D=0A=20=20=20=20=20=20=20=20Go nzalo=20Camarillo=20,=0D =0A=20=20=20=20=20=20=20=20draft-ietf-sipcore-info-events @tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20=20<7402509E63C5A145A 6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> =20<4ADDDA50.1050704@cisco.com>=20<7402509E63C5A145A6095D 46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net>=20; bh=7yEMkQTzek1GGmoVXO4Lm2x4QqeK1bc7bHxW1cvFLjY=; b=SwQIbC21n2w3hVEpsIcAWoADwN/Rd1Lp5sYbEQvnO8SgBfhKpLGO3T2j hedQY6KOOVqZQpi5LiVOEjS6rdhDBufpambz297YCwlPhN2CNrFX/7YeU C1yUyiqBXwHKkDynmEMmgrxHTOstsKed4f84NHLFv3wneYKS28Ech1crd Y=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ+z3UpAZnwM/2dsb2JhbADDE5hIhDEE X-IronPort-AV: E=Sophos;i="4.44,593,1249257600"; d="scan'208";a="197748909" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2009 19:59:08 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9KJx8Ae020764; Tue, 20 Oct 2009 19:59:08 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:59:08 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:59:08 -0400 Message-ID: <4ADE168F.7060303@cisco.com> Date: Tue, 20 Oct 2009 15:59:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 19:59:08.0240 (UTC) FILETIME=[C8C46D00:01CA51BF] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:00:04 -0000 Christer, It sounds like we may have different conceptions of how body parts might be strung together for this. If I read your text below correctly, then it would be possible for the INFO message to have a multipart mixed body, where some body parts are not part of the info package (authentication stuff, geoloc stuff), but where one *or more* other parts are considered part of the info package. It was my thinking that there will always be *one* body part that is the root of all stuff that is associated with the info package. In the simplest case this would be the whole body of the message, containing for example DTMF info. In a slightly more complicated case it might be that same DTMF body, but as one body part in a multipart/mixed, where the other body parts are for incidental purposes but not part of the info package. In cases where the info package itself needs more than one body part, it would consist of a multipart containing all of its pieces. Then that multipart would be just as above - either the only thing in the message, or else it would be a multipart within a multipart, along with other incidental parts. I think that is different from what you are saying. Thanks, Paul Christer Holmberg wrote: > Hi, > >> Your explanation sounds reasonable. I think it requires some > clarification in both 7.6 and 4.3: >> - in 7.6 it should talk about a body part, which may be multipart; > > 7.6 shall definitely be changed. It should say "body parts". > > "7.6. INFO Message Body > > The Info Package specification MUST define what type of message > body parts, are associated with the Info Package, and MUST refer > to specifications where the syntax, semantics and MIME type of each > message body part is described." > > - The old text used to say "message bodies, if any", but I removed "if > any" due to the change that the Info Package shall not assume on > information being conveyed in SIP headers (see other e-mail). > > ------------- > >> - in 4.3 it should talk about labelling the Info-Package body part with > Content-Disposition: Info-Package, this being at the SIP level if it is > the sole body part (i.e., the entire body of the SIP >> message). > > Yes. Basically the text shall say that each message body part associated > with the Info Package shall have a associated C-D header filed with an > 'info-package' value. And, if there is only a single body part in a > message the SIP level C-D header field contains the 'info-package' > value. > > Also, 4.3 talks about "message body payloads", but I will change to > "message body parts" there, to be consistent with 7.6. > > NOTE: The new 4.3 text below may also contain changes I've already done > based on other comments: > > "4.3. INFO Request Message Body > > The purpose of the INFO request is to carry application level > information between SIP UAs. The application data associated with an > Info Package is carried as a payload in the message body of > the INFO request. > > An INFO request message body can contain a single body part, or > multiple > body parts (multipart/mixed). > > Info Package specifications MUST describe the application level > information associated with the Info Package. Message body parts > MUST have a MIME type value defined. > > If a UA indicates that it is willing to receive a specific Info > Package, it means that the UA also supports any associated message > body MIME type associated with the Info Package. However, the UA > MUST still indicate support of those MIME types also in the Accept > header field, according to the procedures in [RFC3261]. > > Some SIP extensions that are orthogonal to INFO MAY insert body parts > unrelated to the Info Package. UAs MUST conform to [RFC3261] as > updated by body-handling [I-D.ietf-sip-body-handling] to support > multipart MIME handling. > > Each message body part associated with an Info Package MUST > contain a Content-Disposition header field with an 'Info-Package' > value, in order to in an easy way distinguish payloads associated > with the Info Package from other payloads. > > If the message body only contains a single body part, the SIP level > Content-Disposition header field > contains an 'info-package' value. > > If the message body contains multiple body parts (multipart/mixed) > the SIP level Content-Disposition header field > does not need to include an 'info-package' value, since each body > part associated with the Info Package will include > a Content-Disposition header field for that specific body part. > > NOTE: To avoid corner cases with legacy INFO usage, the Info-Package > header field is used to indicate the Info Package name, rather than > to use a Content-Disposition header field parameter in order to > indicate the name." > > ------------- > > Regards, > > Christer > > > From christer.holmberg@ericsson.com Tue Oct 20 13:16:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD743A67E5 for ; Tue, 20 Oct 2009 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkKdWjL5aqgv for ; Tue, 20 Oct 2009 13:16:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 504243A6784 for ; Tue, 20 Oct 2009 13:16:07 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-4d-4ade1a8d8277 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 34.6C.04191.D8A1EDA4; Tue, 20 Oct 2009 22:16:13 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 22:16:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 22:15:58 +0200 Message-ID: In-Reply-To: <4ADE168F.7060303@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpRv8vfgPxq0MdzSqCaX9A3QYaaqAAAPQDA References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 20 Oct 2009 20:16:00.0203 (UTC) FILETIME=[23F1B9B0:01CA51C2] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:16:09 -0000 Hi,=20 >It sounds like we may have different conceptions of how body parts might be strung together for this. > >If I read your text below correctly, then it would be possible for the INFO message to have a multipart mixed body, where some body parts are not part of the info package (authentication stuff, geoloc=20 >stuff), but where one *or more* other parts are considered part of the info package. Section 4.3 talks about "SIP extensions that are orthogonal to INFO MAY insert body parts unrelated to the Info Package".=20 Personally, though, I doubt that someone would say "Hey, someone is about the send an INFO, so I'll throw in my message body part there too!". I think that any application who wants to send an INFO (no matter whether it's legacy of I-P based, should trigger a dedicated INFO, and not try to get a "free ride" by someone else... >It was my thinking that there will always be *one* body part that is the root of all stuff that is associated with the info package. In the simplest case this would be the whole body of the message,=20 >containing for example DTMF info. In a slightly more complicated case it might be that same DTMF body, but as one body part in a multipart/mixed, where the other body parts are for incidental purposes=20 >but not part of the info package. Personally I agree with you, but the text has been there for a while already. If people want to remove it, though, I am happy to do it. >In cases where the info package itself needs more than one body part, it would consist of a multipart containing all of its pieces. Then that multipart would be just as above - either the only thing in=20 >the message, or else it would be a multipart within a multipart, along with other incidental parts. Just to make sure: even if we say that all body parts must be associated with the Info Package, do you agree that they ALL still shall have a C-D with 'info-package'? Otherwise parsers may assign whatever the default C-D value is for them, and we don't want that to happen... Regards, Christer Christer Holmberg wrote: > Hi, >=20 >> Your explanation sounds reasonable. I think it requires some > clarification in both 7.6 and 4.3: >> - in 7.6 it should talk about a body part, which may be multipart; >=20 > 7.6 shall definitely be changed. It should say "body parts". >=20 > "7.6. INFO Message Body >=20 > The Info Package specification MUST define what type of message body=20 > parts, are associated with the Info Package, and MUST refer to=20 > specifications where the syntax, semantics and MIME type of each=20 > message body part is described." >=20 > - The old text used to say "message bodies, if any", but I removed "if > any" due to the change that the Info Package shall not assume on=20 > information being conveyed in SIP headers (see other e-mail). >=20 > ------------- >=20 >> - in 4.3 it should talk about labelling the Info-Package body part=20 >> with > Content-Disposition: Info-Package, this being at the SIP level if it=20 > is the sole body part (i.e., the entire body of the SIP >> message). >=20 > Yes. Basically the text shall say that each message body part=20 > associated with the Info Package shall have a associated C-D header=20 > filed with an 'info-package' value. And, if there is only a single=20 > body part in a message the SIP level C-D header field contains the 'info-package' > value. >=20 > Also, 4.3 talks about "message body payloads", but I will change to=20 > "message body parts" there, to be consistent with 7.6. >=20 > NOTE: The new 4.3 text below may also contain changes I've already=20 > done based on other comments: >=20 > "4.3. INFO Request Message Body >=20 > The purpose of the INFO request is to carry application level > information between SIP UAs. The application data associated with an > Info Package is carried as a payload in the message body of > the INFO request.=20 >=20 > An INFO request message body can contain a single body part, or=20 > multiple > body parts (multipart/mixed). >=20 > Info Package specifications MUST describe the application level > information associated with the Info Package. Message body parts > MUST have a MIME type value defined. >=20 > If a UA indicates that it is willing to receive a specific Info > Package, it means that the UA also supports any associated message > body MIME type associated with the Info Package. However, the UA > MUST still indicate support of those MIME types also in the Accept > header field, according to the procedures in [RFC3261]. >=20 > Some SIP extensions that are orthogonal to INFO MAY insert body parts > unrelated to the Info Package. UAs MUST conform to [RFC3261] as > updated by body-handling [I-D.ietf-sip-body-handling] to support > multipart MIME handling. >=20 > Each message body part associated with an Info Package MUST > contain a Content-Disposition header field with an 'Info-Package' > value, in order to in an easy way distinguish payloads associated > with the Info Package from other payloads.=20 >=20 > If the message body only contains a single body part, the SIP level > Content-Disposition header field > contains an 'info-package' value. >=20 > If the message body contains multiple body parts (multipart/mixed)=20 > the SIP level Content-Disposition header field > does not need to include an 'info-package' value, since each body=20 > part associated with the Info Package will include > a Content-Disposition header field for that specific body part. >=20 > NOTE: To avoid corner cases with legacy INFO usage, the Info-Package > header field is used to indicate the Info Package name, rather than > to use a Content-Disposition header field parameter in order to > indicate the name." >=20 > ------------- >=20 > Regards, >=20 > Christer >=20 >=20 >=20 From pkyzivat@cisco.com Tue Oct 20 13:50:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1436B3A6864 for ; Tue, 20 Oct 2009 13:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce+vAJ4flZWa for ; Tue, 20 Oct 2009 13:49:58 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4F7983A6816 for ; Tue, 20 Oct 2009 13:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7142; q=dns/txt; s=rtpiport02001; t=1256071806; x=1257281406; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Tue,=2020 =20Oct=202009=2016:50:04=20-0400|Message-ID:=20<4ADE227C. 5020500@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20draft-ietf-sipcore-info-events@tools.ietf. org|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20; bh=rwKyJuQdIxtf35iE7HfaR+8XaLA7QIVhP1cnBa0fGl8=; b=SY6rc8dXB3dkZZIZS7ZskoELvziF4b0c0OjxLPM2Fmc2YASAPjcN83oe RoigW7lVcM3P0/r1pTNIEQ1HIGIIB9/E8hjktcCzpsiBmE8xcP+EYI+n2 fqmlltKEwKEPKRVyzRaBSltdv8QAoLF6JriVMEJovHt0MsQ6pma59kEfW c=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM+/3UpAZnwN/2dsb2JhbADDFJhNhDEE X-IronPort-AV: E=Sophos;i="4.44,593,1249257600"; d="scan'208";a="64042712" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Oct 2009 20:50:05 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9KKo5kX023096; Tue, 20 Oct 2009 20:50:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 16:50:05 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 16:50:04 -0400 Message-ID: <4ADE227C.5020500@cisco.com> Date: Tue, 20 Oct 2009 16:50:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2009 20:50:04.0974 (UTC) FILETIME=[E6B904E0:01CA51C6] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 20:50:00 -0000 Christer Holmberg wrote: > Hi, > >> It sounds like we may have different conceptions of how body parts > might be strung together for this. >> If I read your text below correctly, then it would be possible for the > INFO message to have a multipart mixed body, where some body parts are > not part of the info package (authentication stuff, geoloc >> stuff), but where one *or more* other parts are considered part of the > info package. > > Section 4.3 talks about "SIP extensions that are orthogonal to INFO MAY > insert body parts unrelated to the Info Package". > > Personally, though, I doubt that someone would say "Hey, someone is > about the send an INFO, so I'll throw in my message body part there > too!". I think that any application who wants to send an INFO (no matter > whether it's legacy of I-P based, should trigger a dedicated INFO, and > not try to get a "free ride" by someone else... The way I envision this might happen would be because of some optional header inserted in the message that has a reference to a body part, via a cid: url. I guess INFO can't have Alert-Info, but if it could then that would be one example. Another example might be an AIB body. Most are pretty far fetched for INFO, but we should not exclude the possibility. >> It was my thinking that there will always be *one* body part that is > the root of all stuff that is associated with the info package. In the > simplest case this would be the whole body of the message, >> containing for example DTMF info. In a slightly more complicated case > it might be that same DTMF body, but as one body part in a > multipart/mixed, where the other body parts are for incidental purposes >> but not part of the info package. > > Personally I agree with you, but the text has been there for a while > already. If people want to remove it, though, I am happy to do it. The way that C-D works means that technically you *could* have multiple parts with C-D of info-pkg. The question is whether there is any value in making it legal. If so then somebody has to define what it means. Since we have multipart which already has lots of ways to group parts, why do we need to introduce yet another grouping mechanism here? >> In cases where the info package itself needs more than one body part, > it would consist of a multipart containing all of its pieces. Then that > multipart would be just as above - either the only thing in >> the message, or else it would be a multipart within a multipart, along > with other incidental parts. > > Just to make sure: even if we say that all body parts must be associated > with the Info Package, do you agree that they ALL still shall have a C-D > with 'info-package'? Otherwise parsers may assign whatever the default > C-D value is for them, and we don't want that to happen... NO, I don't agree. These are nested structures. They may come from some other place and be formed and processed by non-sip code that knows nothing of info-pkg. Once you unwrap the first box, I think you should be allowed to have whatever you want inside. Thanks, Paul > Regards, > > Christer > > > > > > > Christer Holmberg wrote: >> Hi, >> >>> Your explanation sounds reasonable. I think it requires some >> clarification in both 7.6 and 4.3: >>> - in 7.6 it should talk about a body part, which may be multipart; >> 7.6 shall definitely be changed. It should say "body parts". >> >> "7.6. INFO Message Body >> >> The Info Package specification MUST define what type of message body >> parts, are associated with the Info Package, and MUST refer to >> specifications where the syntax, semantics and MIME type of each >> message body part is described." >> >> - The old text used to say "message bodies, if any", but I removed "if > >> any" due to the change that the Info Package shall not assume on >> information being conveyed in SIP headers (see other e-mail). >> >> ------------- >> >>> - in 4.3 it should talk about labelling the Info-Package body part >>> with >> Content-Disposition: Info-Package, this being at the SIP level if it >> is the sole body part (i.e., the entire body of the SIP >>> message). >> Yes. Basically the text shall say that each message body part >> associated with the Info Package shall have a associated C-D header >> filed with an 'info-package' value. And, if there is only a single >> body part in a message the SIP level C-D header field contains the > 'info-package' >> value. >> >> Also, 4.3 talks about "message body payloads", but I will change to >> "message body parts" there, to be consistent with 7.6. >> >> NOTE: The new 4.3 text below may also contain changes I've already >> done based on other comments: >> >> "4.3. INFO Request Message Body >> >> The purpose of the INFO request is to carry application level >> information between SIP UAs. The application data associated with > an >> Info Package is carried as a payload in the message body of >> the INFO request. >> >> An INFO request message body can contain a single body part, or >> multiple >> body parts (multipart/mixed). >> >> Info Package specifications MUST describe the application level >> information associated with the Info Package. Message body parts >> MUST have a MIME type value defined. >> >> If a UA indicates that it is willing to receive a specific Info >> Package, it means that the UA also supports any associated message >> body MIME type associated with the Info Package. However, the UA >> MUST still indicate support of those MIME types also in the Accept >> header field, according to the procedures in [RFC3261]. >> >> Some SIP extensions that are orthogonal to INFO MAY insert body > parts >> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >> updated by body-handling [I-D.ietf-sip-body-handling] to support >> multipart MIME handling. >> >> Each message body part associated with an Info Package MUST >> contain a Content-Disposition header field with an 'Info-Package' >> value, in order to in an easy way distinguish payloads associated >> with the Info Package from other payloads. >> >> If the message body only contains a single body part, the SIP level > >> Content-Disposition header field >> contains an 'info-package' value. >> >> If the message body contains multiple body parts (multipart/mixed) >> the SIP level Content-Disposition header field >> does not need to include an 'info-package' value, since each body >> part associated with the Info Package will include >> a Content-Disposition header field for that specific body part. >> >> NOTE: To avoid corner cases with legacy INFO usage, the > Info-Package >> header field is used to indicate the Info Package name, rather than >> to use a Content-Disposition header field parameter in order to >> indicate the name." >> >> ------------- >> >> Regards, >> >> Christer >> >> >> > From adam@estacado.net Tue Oct 20 14:55:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBD53A698E for ; Tue, 20 Oct 2009 14:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDv59gYCKnd3 for ; Tue, 20 Oct 2009 14:55:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8DFC73A698B for ; Tue, 20 Oct 2009 14:55:30 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9KLtSJM021919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Oct 2009 16:55:28 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4ADE31D0.1000502@estacado.net> Date: Tue, 20 Oct 2009 16:55:28 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Kyzivat References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> In-Reply-To: <4ADE227C.5020500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 20 Oct 2009 14:57:35 -0700 Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 21:55:33 -0000 [individually] On 10/20/09 15:50, Oct 20, Paul Kyzivat wrote: > The way that C-D works means that technically you *could* have > multiple parts with C-D of info-pkg. The question is whether there is > any value in making it legal. If so then somebody has to define what > it means. Since we have multipart which already has lots of ways to > group parts, why do we need to introduce yet another grouping > mechanism here? I agree with Paul -- the myriad MIME multipart types are pretty much infinitely flexible. I think the correct way to nail this down is to mandate that an INFO contains exactly one or zero parts with a C-D of info-pkg. While this does need to be flexible, I can't imagine any level of flexibility that MIME doesn't currently provide. Above all, we really don't want to make how INFO uses MIME any more complicated than necessary. /a From christer.holmberg@ericsson.com Tue Oct 20 22:14:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5943A68C7 for ; Tue, 20 Oct 2009 22:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsL-mG2UJHC7 for ; Tue, 20 Oct 2009 22:14:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 60CDD3A6893 for ; Tue, 20 Oct 2009 22:14:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-40-4ade98d71d4f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 79.3C.04191.7D89EDA4; Wed, 21 Oct 2009 07:15:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:15:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 07:15:02 +0200 Message-ID: In-Reply-To: <4ADE31D0.1000502@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpR0A7n9FrXX42jRvigLDHnRj/rYwAO7ppw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <4ADE31D0.1000502@estacado.net> From: "Christer Holmberg" To: "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 05:15:02.0993 (UTC) FILETIME=[71BFD410:01CA520D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 05:14:57 -0000 Hi,=20 >>The way that C-D works means that technically you *could* have=20 >>multiple parts with C-D of info-pkg. The question is=20 >>whether there is any value in making it legal. If so then somebody has to=20 >>define what it means. Since we have multipart which already has lots of ways to=20 >>group parts, why do we need to introduce yet another grouping=20 >>mechanism here? >=20 >I agree with Paul -- the myriad MIME multipart types are=20 >pretty much infinitely flexible. I think the correct way to=20 >nail this down is to mandate that an INFO contains exactly=20 >one or zero parts with a C-D of info-pkg. While this does=20 >need to be flexible, I can't imagine any level of flexibility=20 >that MIME doesn't currently provide. >=20 >Above all, we really don't want to make how INFO uses MIME=20 >any more complicated than necessary. I don't see what the problem is in allowing multiple body parts with C-D 'info-package'. In most real-life cases I think there will be only one 'info-package' body part in any case. 1. Assume that we have a multipart/mime which contains only I-P parts, and define C-D 'info-package' for that multipart/mime. Does that automatically give C-D 'info-package' to all body parts within that multipart/mime? Or, will they be assigned whatever default value? 2. Assume a UA sends an INFO with multipart/mime, which contains a number of body parts. Then someone wants to insert a non-I-P body part. How can we ensure that "someone" won't insert that non-I-P body part within the same multipart/mime which contains the I-P stuff? How can we ensure that "someone" will move the existing multipart/mime body, with the I-P stuff, into a second level multipart/mime? So, I think there is no problem in allowing multiple body parts with C-D 'info-package'. It causes no problem for the SIP stack, and the application will deal with it. Please also remember that we only allow an INFO request to be associated with a single Info Package, so one will always know that all body parts with C-D 'info-package' are associated with the package indicated in the Info-Package header. Regards, Christer From christer.holmberg@ericsson.com Tue Oct 20 22:16:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A583A68D4 for ; Tue, 20 Oct 2009 22:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byj4+hZQn5zh for ; Tue, 20 Oct 2009 22:16:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B99EF3A6893 for ; Tue, 20 Oct 2009 22:16:23 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ad-4ade992ec821 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D3.4C.04191.E299EDA4; Wed, 21 Oct 2009 07:16:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 07:16:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 07:16:30 +0200 Message-ID: In-Reply-To: <4ADE227C.5020500@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpRxujy7Wx9KJwdSiGh77jVX7NIuwARosVw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 05:16:30.0600 (UTC) FILETIME=[A5F79880:01CA520D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 05:16:25 -0000 Hi,=20 >>Section 4.3 talks about "SIP extensions that are orthogonal to INFO=20 >> MAY insert body parts unrelated to the Info Package". >>=20 >>Personally, though, I doubt that someone would say "Hey, someone is=20 >>about the send an INFO, so I'll throw in my message body part there=20 >>too!". I think that any application who wants to send an INFO (no=20 >>matter whether it's legacy of I-P based, should trigger a dedicated=20 >>INFO, and not try to get a "free ride" by someone else... >=20 >The way I envision this might happen would be because of some=20 >optional header inserted in the message that has a reference=20 >to a body part, via a cid: url. I guess INFO can't have=20 >Alert-Info, but if it could then that would be one example. > >Another example might be an AIB body. >=20 >Most are pretty far fetched for INFO, but we should not=20 >exclude the possibility. Good, so we keep the text. I'll address the multipart/mime issue in my reply to Adam's reply to your reply. Regards, Christer From john.elwell@siemens-enterprise.com Tue Oct 20 23:41:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827083A67D4 for ; Tue, 20 Oct 2009 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfZaJD7cHzFB for ; Tue, 20 Oct 2009 23:41:46 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 85BE53A67B6 for ; Tue, 20 Oct 2009 23:41:45 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9L6f1Oq019338; Wed, 21 Oct 2009 08:41:01 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9L6f03d021138; Wed, 21 Oct 2009 08:41:00 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 21 Oct 2009 08:41:00 +0200 From: "Elwell, John" To: Paul Kyzivat , Christer Holmberg Date: Wed, 21 Oct 2009 08:37:43 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpRxuhW1rf16p0wTYS0no17MHzSOwATbQdA Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> In-Reply-To: <4ADE227C.5020500@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo, Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 06:41:48 -0000 Christer, I tend to agree with Paul, and this is the text I would propose: For 7.6: "The Info Package specification MUST define what type of=20 body part is associated with the Info Package, and MUST refer to specifications where the syntax, semantics and MIME type of that=20 body part (and, if multipart/mixed, any child body parts) are described."=20 For 4.3: "The purpose of the INFO request is to carry application level information = between SIP UAs. The application data associated with an Info Package is ca= rried as a body part in the message body of the INFO request. This body par= t is identified by a MIME type, which can be multipart/mixed, in which case= the body part has child body parts. In accordance with section 7.6, the In= fo Package specification defines the type of body part. An INFO request message body can contain just the body part associated with= the Info Package, or this body part along with other body parts (not relat= ed to the Info Package but relating to other SIP extensions) in a message b= ody of type multipart/mixed. If a UA indicates that it is willing to receive a specific Info Package, it= means that the UA also supports the associated body part MIME type associa= ted with that Info Package. However, the UA MUST still indicate support of= that MIME type, and any child MIME types, in the Accept header field, acco= rding to the procedures in [RFC3261]. UAs MUST conform to [RFC3261], as updated by body-handling [I-D.ietf-sip-bo= dy-handling], to support multipart MIME handling. The body part associated with the Info Package MUST contain a Content-Dispo= sition header field with value 'Info-Package', in order easily to distingui= sh payloads associated with the Info Package from other payloads. If the me= ssage body only contains the single body part associated with the Info-Pack= age, the SIP level Content-Disposition header field MUST contain value 'Inf= o-Package'. If the message body is of type multipart/mixed, the child body = part associated with the Info-Package MUST include a Content-Disposition he= ader field with value 'Info-Package'. Child body parts of a multipart/mixed= body part associated with the Info-Package do not require this Content-Dis= position value. NOTE: To avoid corner cases with legacy INFO usage, the Info-Package header= field is used to indicate the Info Package name, rather than using a Conte= nt-Disposition header field parameter in order to indicate the name." How does this sound? John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 20 October 2009 21:50 > To: Christer Holmberg > Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body parts in INFO? >=20 >=20 >=20 > Christer Holmberg wrote: > > Hi,=20 > >=20 > >> It sounds like we may have different conceptions of how body parts > > might be strung together for this. > >> If I read your text below correctly, then it would be=20 > possible for the > > INFO message to have a multipart mixed body, where some=20 > body parts are > > not part of the info package (authentication stuff, geoloc=20 > >> stuff), but where one *or more* other parts are considered=20 > part of the > > info package. > >=20 > > Section 4.3 talks about "SIP extensions that are orthogonal=20 > to INFO MAY > > insert body parts unrelated to the Info Package".=20 > >=20 > > Personally, though, I doubt that someone would say "Hey, someone is > > about the send an INFO, so I'll throw in my message body part there > > too!". I think that any application who wants to send an=20 > INFO (no matter > > whether it's legacy of I-P based, should trigger a=20 > dedicated INFO, and > > not try to get a "free ride" by someone else... >=20 > The way I envision this might happen would be because of some=20 > optional=20 > header inserted in the message that has a reference to a body=20 > part, via=20 > a cid: url. I guess INFO can't have Alert-Info, but if it could then=20 > that would be one example. >=20 > Another example might be an AIB body. >=20 > Most are pretty far fetched for INFO, but we should not exclude the=20 > possibility. >=20 > >> It was my thinking that there will always be *one* body=20 > part that is > > the root of all stuff that is associated with the info=20 > package. In the > > simplest case this would be the whole body of the message,=20 > >> containing for example DTMF info. In a slightly more=20 > complicated case > > it might be that same DTMF body, but as one body part in a > > multipart/mixed, where the other body parts are for=20 > incidental purposes=20 > >> but not part of the info package. > >=20 > > Personally I agree with you, but the text has been there for a while > > already. If people want to remove it, though, I am happy to do it. >=20 > The way that C-D works means that technically you *could*=20 > have multiple=20 > parts with C-D of info-pkg. The question is whether there is=20 > any value=20 > in making it legal. If so then somebody has to define what it means.=20 > Since we have multipart which already has lots of ways to=20 > group parts,=20 > why do we need to introduce yet another grouping mechanism here? >=20 > >> In cases where the info package itself needs more than one=20 > body part, > > it would consist of a multipart containing all of its=20 > pieces. Then that > > multipart would be just as above - either the only thing in=20 > >> the message, or else it would be a multipart within a=20 > multipart, along > > with other incidental parts. > >=20 > > Just to make sure: even if we say that all body parts must=20 > be associated > > with the Info Package, do you agree that they ALL still=20 > shall have a C-D > > with 'info-package'? Otherwise parsers may assign whatever=20 > the default > > C-D value is for them, and we don't want that to happen... >=20 > NO, I don't agree. >=20 > These are nested structures. They may come from some other=20 > place and be=20 > formed and processed by non-sip code that knows nothing of info-pkg.=20 > Once you unwrap the first box, I think you should be allowed to have=20 > whatever you want inside. >=20 > Thanks, > Paul >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Christer Holmberg wrote: > >> Hi, > >> > >>> Your explanation sounds reasonable. I think it requires some > >> clarification in both 7.6 and 4.3: > >>> - in 7.6 it should talk about a body part, which may be multipart; > >> 7.6 shall definitely be changed. It should say "body parts". > >> > >> "7.6. INFO Message Body > >> > >> The Info Package specification MUST define what type of=20 > message body=20 > >> parts, are associated with the Info Package, and MUST refer to=20 > >> specifications where the syntax, semantics and MIME type of each=20 > >> message body part is described." > >> > >> - The old text used to say "message bodies, if any", but I=20 > removed "if > >=20 > >> any" due to the change that the Info Package shall not assume on=20 > >> information being conveyed in SIP headers (see other e-mail). > >> > >> ------------- > >> > >>> - in 4.3 it should talk about labelling the Info-Package=20 > body part=20 > >>> with > >> Content-Disposition: Info-Package, this being at the SIP=20 > level if it=20 > >> is the sole body part (i.e., the entire body of the SIP > >>> message). > >> Yes. Basically the text shall say that each message body part=20 > >> associated with the Info Package shall have a associated=20 > C-D header=20 > >> filed with an 'info-package' value. And, if there is only a single=20 > >> body part in a message the SIP level C-D header field contains the > > 'info-package' > >> value. > >> > >> Also, 4.3 talks about "message body payloads", but I will=20 > change to=20 > >> "message body parts" there, to be consistent with 7.6. > >> > >> NOTE: The new 4.3 text below may also contain changes I've already=20 > >> done based on other comments: > >> > >> "4.3. INFO Request Message Body > >> > >> The purpose of the INFO request is to carry application level > >> information between SIP UAs. The application data=20 > associated with > > an > >> Info Package is carried as a payload in the message body of > >> the INFO request.=20 > >> > >> An INFO request message body can contain a single body part, or=20 > >> multiple > >> body parts (multipart/mixed). > >> > >> Info Package specifications MUST describe the application level > >> information associated with the Info Package. Message body parts > >> MUST have a MIME type value defined. > >> > >> If a UA indicates that it is willing to receive a specific Info > >> Package, it means that the UA also supports any=20 > associated message > >> body MIME type associated with the Info Package. =20 > However, the UA > >> MUST still indicate support of those MIME types also in=20 > the Accept > >> header field, according to the procedures in [RFC3261]. > >> > >> Some SIP extensions that are orthogonal to INFO MAY insert body > > parts > >> unrelated to the Info Package. UAs MUST conform to [RFC3261] as > >> updated by body-handling [I-D.ietf-sip-body-handling] to support > >> multipart MIME handling. > >> > >> Each message body part associated with an Info Package MUST > >> contain a Content-Disposition header field with an=20 > 'Info-Package' > >> value, in order to in an easy way distinguish payloads=20 > associated > >> with the Info Package from other payloads.=20 > >> > >> If the message body only contains a single body part,=20 > the SIP level > >=20 > >> Content-Disposition header field > >> contains an 'info-package' value. > >> > >> If the message body contains multiple body parts=20 > (multipart/mixed)=20 > >> the SIP level Content-Disposition header field > >> does not need to include an 'info-package' value, since=20 > each body=20 > >> part associated with the Info Package will include > >> a Content-Disposition header field for that specific body part. > >> > >> NOTE: To avoid corner cases with legacy INFO usage, the > > Info-Package > >> header field is used to indicate the Info Package name,=20 > rather than > >> to use a Content-Disposition header field parameter in order to > >> indicate the name." > >> > >> ------------- > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >=20 > = From christer.holmberg@ericsson.com Wed Oct 21 00:52:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6D53A6883 for ; Wed, 21 Oct 2009 00:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDw6nvANeLFa for ; Wed, 21 Oct 2009 00:52:14 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 016AE3A67AB for ; Wed, 21 Oct 2009 00:52:13 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-48-4adebdb4d825 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D2.C3.08816.4BDBEDA4; Wed, 21 Oct 2009 09:52:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:52:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 09:52:18 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpRxuhW1rf16p0wTYS0no17MHzSOwATbQdAAAI2o3A= References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 07:52:20.0298 (UTC) FILETIME=[6AD24AA0:01CA5223] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 07:52:16 -0000 Hi,=20 >I tend to agree with Paul, and this is the text I would propose: >=20 >For 7.6: >"The Info Package specification MUST define what type of body=20 >part is associated with the Info Package, and MUST refer to=20 >specifications where the syntax, semantics and MIME type of=20 >that body part (and, if multipart/mixed, any child body=20 >parts) are described."=20 I don't understand the child body thing. A specific body part looks the same no matter whether it is included in a multipart (as a child body part) or not. >For 4.3: >"The purpose of the INFO request is to carry application=20 >level information between SIP UAs. The application data=20 >associated with an Info Package is carried as a body part in=20 >the message body of the INFO request. This body part is=20 >identified by a MIME type, which can be multipart/mixed, in=20 >which case the body part has child body parts. In accordance=20 >with section 7.6, the Info Package specification defines the=20 >type of body part. > >An INFO request message body can contain just the body part=20 >associated with the Info Package, or this body part along=20 >with other body parts (not related to the Info Package but=20 >relating to other SIP extensions) in a message body of type=20 >multipart/mixed. > >=20 >If a UA indicates that it is willing to receive a specific=20 >Info Package, it means that the UA also supports the=20 >associated body part MIME type associated with that Info=20 >Package. > >However, the UA MUST still indicate support of that=20 >MIME type, and any child MIME types, in the Accept header=20 >field, according to the procedures in [RFC3261]. >=20 >UAs MUST conform to [RFC3261], as updated by body-handling=20 >[I-D.ietf-sip-body-handling], to support multipart MIME handling. >=20 >The body part associated with the Info Package MUST contain a=20 >Content-Disposition header field with value 'Info-Package',=20 >in order easily to distinguish payloads associated with the=20 >Info Package from other payloads. If the message body only=20 >contains the single body part associated with the=20 >Info-Package, the SIP level Content-Disposition header field=20 >MUST contain value 'Info-Package'. If the message body is of=20 >type multipart/mixed, the child body part associated with the=20 >Info-Package MUST include a Content-Disposition header field=20 >with value 'Info-Package'. Child body parts of a=20 >multipart/mixed body part associated with the Info-Package do=20 >not require this Content-Disposition value. The beginning of the last paragraph says that the C-D header is used to distinguish the body parts associated with the Info Package. So, I am still wondering why we, if there are non-I-P body parts, in addition would need to encapsulate the body parts (if many) associated with the Info Package into a multipart/mixed. BUT, assuming we would go that way, I would still like to get some clarification on the questions I had related to that: ----------- 1. If we only indicate C-D 'info-package' for the multipart/mixed body part, but not for the child body parts, what C-D value will the child body parts get? Do they automatically get the same 'info-package' value as the "parent" (the multipart/mixed body part)? My understanding of RFC 5621 is that they do NOT automatically get the same value - they will get the default value, which for SIP is "render" (excluding app/sdp). Section 8.2 of RFC 5621 says: "The way the body parts within the 'multipart/mixed' are handled depends on the disposition types of the individual body parts. The actual disposition type of the whole 'multipart/mixed' is irrelevant." So, we would anyway need to indicate C-D 'info-package' for each body part associated with the Info Package... ----------- 2. How can we prevent someone who inserts a non-I-P body part from inserting it into the same multipart/mixed body part which contains the I-P children? ----------- Also, I think we would be able to make the last paragraph more simple, but let's focus on the technical stuff first. Regards, Christer =20 > NOTE: To avoid corner cases with legacy INFO usage, the=20 > Info-Package header field is used to indicate the Info=20 > Package name, rather than using a Content-Disposition header=20 > field parameter in order to indicate the name." >=20 > How does this sound? >=20 > John >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 20 October 2009 21:50 > > To: Christer Holmberg > > Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 > > draft-ietf-sipcore-info-events@tools.ietf.org > > Subject: Re: [sipcore] WGLC comments > > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body=20 > > parts in INFO? > >=20 > >=20 > >=20 > > Christer Holmberg wrote: > > > Hi, > > >=20 > > >> It sounds like we may have different conceptions of how=20 > body parts > > > might be strung together for this. > > >> If I read your text below correctly, then it would be > > possible for the > > > INFO message to have a multipart mixed body, where some > > body parts are > > > not part of the info package (authentication stuff, geoloc > > >> stuff), but where one *or more* other parts are considered > > part of the > > > info package. > > >=20 > > > Section 4.3 talks about "SIP extensions that are orthogonal > > to INFO MAY > > > insert body parts unrelated to the Info Package".=20 > > >=20 > > > Personally, though, I doubt that someone would say "Hey,=20 > someone is=20 > > > about the send an INFO, so I'll throw in my message body=20 > part there=20 > > > too!". I think that any application who wants to send an > > INFO (no matter > > > whether it's legacy of I-P based, should trigger a > > dedicated INFO, and > > > not try to get a "free ride" by someone else... > >=20 > > The way I envision this might happen would be because of=20 > some optional=20 > > header inserted in the message that has a reference to a body part,=20 > > via a cid: url. I guess INFO can't have Alert-Info, but if it could=20 > > then that would be one example. > >=20 > > Another example might be an AIB body. > >=20 > > Most are pretty far fetched for INFO, but we should not exclude the=20 > > possibility. > >=20 > > >> It was my thinking that there will always be *one* body > > part that is > > > the root of all stuff that is associated with the info > > package. In the > > > simplest case this would be the whole body of the message, > > >> containing for example DTMF info. In a slightly more > > complicated case > > > it might be that same DTMF body, but as one body part in a=20 > > > multipart/mixed, where the other body parts are for > > incidental purposes > > >> but not part of the info package. > > >=20 > > > Personally I agree with you, but the text has been there=20 > for a while=20 > > > already. If people want to remove it, though, I am happy to do it. > >=20 > > The way that C-D works means that technically you *could* have=20 > > multiple parts with C-D of info-pkg. The question is=20 > whether there is=20 > > any value in making it legal. If so then somebody has to=20 > define what=20 > > it means. > > Since we have multipart which already has lots of ways to=20 > group parts,=20 > > why do we need to introduce yet another grouping mechanism here? > >=20 > > >> In cases where the info package itself needs more than one > > body part, > > > it would consist of a multipart containing all of its > > pieces. Then that > > > multipart would be just as above - either the only thing in > > >> the message, or else it would be a multipart within a > > multipart, along > > > with other incidental parts. > > >=20 > > > Just to make sure: even if we say that all body parts must > > be associated > > > with the Info Package, do you agree that they ALL still > > shall have a C-D > > > with 'info-package'? Otherwise parsers may assign whatever > > the default > > > C-D value is for them, and we don't want that to happen... > >=20 > > NO, I don't agree. > >=20 > > These are nested structures. They may come from some other=20 > place and=20 > > be formed and processed by non-sip code that knows nothing of=20 > > info-pkg. > > Once you unwrap the first box, I think you should be=20 > allowed to have=20 > > whatever you want inside. > >=20 > > Thanks, > > Paul > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > Christer Holmberg wrote: > > >> Hi, > > >> > > >>> Your explanation sounds reasonable. I think it requires some > > >> clarification in both 7.6 and 4.3: > > >>> - in 7.6 it should talk about a body part, which may be=20 > multipart; > > >> 7.6 shall definitely be changed. It should say "body parts". > > >> > > >> "7.6. INFO Message Body > > >> > > >> The Info Package specification MUST define what type of > > message body > > >> parts, are associated with the Info Package, and MUST refer to=20 > > >> specifications where the syntax, semantics and MIME type of each=20 > > >> message body part is described." > > >> > > >> - The old text used to say "message bodies, if any", but I > > removed "if > > >=20 > > >> any" due to the change that the Info Package shall not assume on=20 > > >> information being conveyed in SIP headers (see other e-mail). > > >> > > >> ------------- > > >> > > >>> - in 4.3 it should talk about labelling the Info-Package > > body part > > >>> with > > >> Content-Disposition: Info-Package, this being at the SIP > > level if it > > >> is the sole body part (i.e., the entire body of the SIP > > >>> message). > > >> Yes. Basically the text shall say that each message body part=20 > > >> associated with the Info Package shall have a associated > > C-D header > > >> filed with an 'info-package' value. And, if there is=20 > only a single=20 > > >> body part in a message the SIP level C-D header field=20 > contains the > > > 'info-package' > > >> value. > > >> > > >> Also, 4.3 talks about "message body payloads", but I will > > change to > > >> "message body parts" there, to be consistent with 7.6. > > >> > > >> NOTE: The new 4.3 text below may also contain changes=20 > I've already=20 > > >> done based on other comments: > > >> > > >> "4.3. INFO Request Message Body > > >> > > >> The purpose of the INFO request is to carry application level > > >> information between SIP UAs. The application data > > associated with > > > an > > >> Info Package is carried as a payload in the message body of > > >> the INFO request.=20 > > >> > > >> An INFO request message body can contain a single=20 > body part, or=20 > > >> multiple > > >> body parts (multipart/mixed). > > >> > > >> Info Package specifications MUST describe the=20 > application level > > >> information associated with the Info Package. Message=20 > body parts > > >> MUST have a MIME type value defined. > > >> > > >> If a UA indicates that it is willing to receive a=20 > specific Info > > >> Package, it means that the UA also supports any > > associated message > > >> body MIME type associated with the Info Package. =20 > > However, the UA > > >> MUST still indicate support of those MIME types also in > > the Accept > > >> header field, according to the procedures in [RFC3261]. > > >> > > >> Some SIP extensions that are orthogonal to INFO MAY=20 > insert body > > > parts > > >> unrelated to the Info Package. UAs MUST conform to=20 > [RFC3261] as > > >> updated by body-handling [I-D.ietf-sip-body-handling]=20 > to support > > >> multipart MIME handling. > > >> > > >> Each message body part associated with an Info Package MUST > > >> contain a Content-Disposition header field with an > > 'Info-Package' > > >> value, in order to in an easy way distinguish payloads > > associated > > >> with the Info Package from other payloads.=20 > > >> > > >> If the message body only contains a single body part, > > the SIP level > > >=20 > > >> Content-Disposition header field > > >> contains an 'info-package' value. > > >> > > >> If the message body contains multiple body parts > > (multipart/mixed) > > >> the SIP level Content-Disposition header field > > >> does not need to include an 'info-package' value, since > > each body > > >> part associated with the Info Package will include > > >> a Content-Disposition header field for that specific=20 > body part. > > >> > > >> NOTE: To avoid corner cases with legacy INFO usage, the > > > Info-Package > > >> header field is used to indicate the Info Package name, > > rather than > > >> to use a Content-Disposition header field parameter=20 > in order to > > >> indicate the name." > > >> > > >> ------------- > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Wed Oct 21 04:38:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9A93A68F1 for ; Wed, 21 Oct 2009 04:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmjKk1Ev2p9h for ; Wed, 21 Oct 2009 04:38:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id F0B613A68C9 for ; Wed, 21 Oct 2009 04:38:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-22-4adef21021c4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2F.15.24026.012FEDA4; Wed, 21 Oct 2009 13:35:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:35:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 13:35:42 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAPA7FkA== References: From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 21 Oct 2009 11:35:44.0247 (UTC) FILETIME=[A0329870:01CA5242] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:38:18 -0000 =20 Hi John, =20 >>1. I think the document would benefit from having a=20 >>definition of Info=20 >>Package at some point early on. In section 1 we have "This document=20 >>defines a mechanism, using Info Packages, which provides the=20 >>possibility for UAs to indicate what INFO usages they=20 >>support, and to=20 >>define content syntax and semantics for the data transported in the=20 >>INFO messages.", but that describes the mechanism, rather=20 >>than defining >>Info package. As a starter, how about something like: >>"A specified usage of the SIP INFO method, detailing the format and=20 >>semantics of information transported." >=20 >Sounds ok. Need to think where to put the text. I rewrote the paragraph: "This document defines a mechanism, using Info Packages.=20 An Info Package defines the content and semantics of an INFO usage. The Info Package mechanism also provides a way for UAs to indicate for=20 which INFO usages they are willing to receive INFO requests. This document defines the usage of the SIP INFO method, new SIP header fields for the Info Package mechanism, and how to transport payload information associated=20 with an Info Package in INFO requests. =20 The mechanism is allows existing legacy INFO usages as defined in RFC 2976." Regards, Christer From christer.holmberg@ericsson.com Wed Oct 21 04:42:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7243A6A37 for ; Wed, 21 Oct 2009 04:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7ynZ2n1QQe6 for ; Wed, 21 Oct 2009 04:42:44 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3AF193A6A30 for ; Wed, 21 Oct 2009 04:42:43 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-25-4adef3bbab30 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C6.C7.08816.BB3FEDA4; Wed, 21 Oct 2009 13:42:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 13:42:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 13:42:15 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAAENTmAAIr50AA== References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 21 Oct 2009 11:42:17.0028 (UTC) FILETIME=[8A503840:01CA5243] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:42:45 -0000 =20 Hi, =20 >>>2. In several places in the document (e.g., Abstract,=20 >>>section 1), it talks about receiving Info Packages, but I think that is=20 >>>incorrect. Shouldn't it really be worded along the lines of receiving >>>information within the context of an Info Package? (c.f., RFC 3265, >>>where we don't receive event packages in NOTIFY >requests,=20 >>>we receive events). >>>=20 >>>I guess an alternative is to talk about "receiving information=20 >>>associated with an Info Package". It would be more words, though.. >>>[JRE] Yes, that would work, but I am open to suggestions to=20 >>>shorten it, as long as we don't resort to inaccurate formulations like=20 >>>we have at present. >>=20 >>Or, we could somewhere in the beginning of the document clarify that >>"receive Info Package" means to receive an INFO associated=20 >>with an Info Package, or something like that... >[JRE] If this would make the document more readable (in terms=20 >of avoiding long formulations in many places in the=20 >document), it would at least be an improvement on what we=20 >have at present. What about if we talked about "indicating for which Info Packages a UA is willing to receive INFO requests"? Then it is more clear that the user does not receive an Info Package, bur rather an INFO request associated with an Info Package. Regards, Christer From john.elwell@siemens-enterprise.com Wed Oct 21 05:48:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C553A6A4E for ; Wed, 21 Oct 2009 05:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tnd69SCX1XZT for ; Wed, 21 Oct 2009 05:48:04 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 0AAB73A6A4A for ; Wed, 21 Oct 2009 05:48:03 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCllLE002291; Wed, 21 Oct 2009 14:47:47 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCllAB025004; Wed, 21 Oct 2009 14:47:47 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 21 Oct 2009 14:47:46 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Wed, 21 Oct 2009 14:47:42 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAPA7FkAACBsIg Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2D1D@DEMCHP99E35MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Roach , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:48:05 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 21 October 2009 12:36 > To: Elwell, John; SIPCORE > Cc: Adam Roach; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: RE: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction >=20 > =20 > Hi John, > =20 > >>1. I think the document would benefit from having a=20 > >>definition of Info=20 > >>Package at some point early on. In section 1 we have "This document=20 > >>defines a mechanism, using Info Packages, which provides the=20 > >>possibility for UAs to indicate what INFO usages they=20 > >>support, and to=20 > >>define content syntax and semantics for the data transported in the=20 > >>INFO messages.", but that describes the mechanism, rather=20 > >>than defining > >>Info package. As a starter, how about something like: > >>"A specified usage of the SIP INFO method, detailing the format and=20 > >>semantics of information transported." > >=20 > >Sounds ok. Need to think where to put the text. >=20 > I rewrote the paragraph: >=20 > "This document defines a mechanism, using Info Packages.=20 > An Info Package defines the content and semantics of an INFO usage. > The Info Package mechanism also provides a way for UAs to=20 > indicate for=20 > which INFO usages they are willing to receive INFO requests. This > document defines the usage of the SIP INFO method, new SIP=20 > header fields > for the > Info Package mechanism, and how to transport payload information > associated=20 > with an Info Package in INFO requests. > =20 > The mechanism is allows existing legacy INFO usages as defined in RFC > 2976." [JRE] We have two different usages of the word "usage" in this paragraph. "= An INFO usage" near the start, which I think is intended to be a usage defi= ned by an Info Package, and "usage of the SIP INFO message" later, which is= what is defined in this document. We should at least avoid that. However, = I have a bigger concern about the style of section 1, which I will raise in= a new thread. John >=20 > Regards, >=20 > Christer > = From john.elwell@siemens-enterprise.com Wed Oct 21 05:50:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2C93A6955 for ; Wed, 21 Oct 2009 05:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwJe8GpMYdY1 for ; Wed, 21 Oct 2009 05:50:01 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id E2E263A6A4A for ; Wed, 21 Oct 2009 05:50:00 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCo7G9003606 for ; Wed, 21 Oct 2009 14:50:07 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCo6JK017047 for ; Wed, 21 Oct 2009 14:50:07 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 21 Oct 2009 14:50:06 +0200 From: "Elwell, John" To: SIPCORE Date: Wed, 21 Oct 2009 14:50:02 +0200 Thread-Topic: Style of section 1 in info-events Thread-Index: AcpSTQFTLWL/4JP/SFaGU9RvxSenuQ== Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:50:02 -0000 Section 1 says what RFC 2976 does, says what its drawbacks are, and then sa= ys that this document describes a mechanism that addresses those drawbacks.= It does not state that this document defines the INFO method. It even refe= rs back to RFC 2976 for the definition of the INFO method ("The purpose of = the INFO message [RFC2976] is.... "). Yet this document supposedly obsoletes RFC 2976. I would have expected the introduction to a document that obsoletes an earl= ier RFC to be self-standing and structured more like the following: - Introductory text very similar to what is in the obsoleted RFC, but modif= ied to mention anything that is significantly different. - A reference back to the obsoleted RFC, describing what has changed. In this particular case, the text of RFC 2976 is a rough starting point. It= even says, near the end, that the document does not specify specific uses,= so that is an ideal point to continue and talk about usages, Info-Packages= , and indicating supported usages. We could then continue by saying that the document obsoletes RFC 2976, whic= h did not define the Info-Package concept and explicit indications of which= usages are supported. John From john.elwell@siemens-enterprise.com Wed Oct 21 05:52:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB70F3A6A35 for ; Wed, 21 Oct 2009 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cftjpOZbAjFT for ; Wed, 21 Oct 2009 05:52:17 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id A9BA23A69D5 for ; Wed, 21 Oct 2009 05:52:16 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCq0I1020981; Wed, 21 Oct 2009 14:52:00 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LCq0g7001145; Wed, 21 Oct 2009 14:52:00 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Wed, 21 Oct 2009 14:51:59 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Wed, 21 Oct 2009 14:51:54 +0200 Thread-Topic: WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAAENTmAAIr50AAAChd1A Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2D22@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Adam Roach , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 12:52:17 -0000 Yes=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 21 October 2009 12:42 > To: Elwell, John; SIPCORE > Cc: Gonzalo Camarillo; Adam Roach;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: RE: WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > receive Info-Package wording >=20 > =20 > Hi, > =20 > >>>2. In several places in the document (e.g., Abstract,=20 > >>>section 1), it talks about receiving Info Packages, but I=20 > think that > is=20 > >>>incorrect. Shouldn't it really be worded along the lines=20 > of receiving > >>>information within the context of an Info Package? (c.f., RFC 3265, > >>>where we don't receive event packages in NOTIFY >requests,=20 > >>>we receive events). > >>>=20 > >>>I guess an alternative is to talk about "receiving information=20 > >>>associated with an Info Package". It would be more words, though.. > >>>[JRE] Yes, that would work, but I am open to suggestions to=20 > >>>shorten it, as long as we don't resort to inaccurate formulations > like=20 > >>>we have at present. > >>=20 > >>Or, we could somewhere in the beginning of the document clarify that > >>"receive Info Package" means to receive an INFO associated=20 > >>with an Info Package, or something like that... > >[JRE] If this would make the document more readable (in terms=20 > >of avoiding long formulations in many places in the=20 > >document), it would at least be an improvement on what we=20 > >have at present. >=20 > What about if we talked about "indicating for which Info Packages a UA > is willing to receive INFO requests"? >=20 > Then it is more clear that the user does not receive an Info Package, > bur rather an INFO request associated with an Info Package. >=20 > Regards, >=20 > Christer >=20 > = From pkyzivat@cisco.com Wed Oct 21 07:19:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22513A6935 for ; Wed, 21 Oct 2009 07:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.468 X-Spam-Level: X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fCxq3DRQ7fZ for ; Wed, 21 Oct 2009 07:19:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 72BB13A6930 for ; Wed, 21 Oct 2009 07:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4294; q=dns/txt; s=rtpiport02001; t=1256134803; x=1257344403; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2010:19:50=20-0400|Message-ID:=20<4ADF1886. 5020909@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20"Elwell,=20John"=20< john.elwell@siemens-enterprise.com>,=0D=0A=20=20=20=20=20 =20=20=20SIPCORE=20,=0D=0A=20=20=20=20 =20=20=20=20Gonzalo=20Camarillo=20,=0D=0A=20=20=20=20=20=20=20=20draft-ietf-sipcor e-info-events@tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20=20<7402509E63C5A145A 6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> =20<4ADDDA50.1050704@cisco.com>=20<7402509E63C5A145A6095D 46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net>=20=20<4ADE168F.7060303@cisco.com>=20=20<4ADE227C.5020500@cisco.com>=20<4ADE31D0.1000502@es tacado.net>=20; bh=8oVC99uVfvHK9yvYsaKo6j96rQrdOBLVfUmE3jPDQ9s=; b=VD4rz2J7OSnP/29vTV2Y0jO8ZOuL3HxcZ4SIsqy4njH8FBYbLw7jpjGz QBHoue3Mfjb9+pqT5+D3iWdYyKKka1cvW1Vu/52PdZ0LfOTTNazJ4npuS ZOIlh/tIyUFgyhZd6U4WsXgy04DSc6hdpnT3Lk5hpWEHPgKQYqdHKWy8A 0=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOi13kpAZnwM/2dsb2JhbADDQZhWhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208";a="64163607" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2009 14:19:50 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LEJoxa014882; Wed, 21 Oct 2009 14:19:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:19:50 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:19:50 -0400 Message-ID: <4ADF1886.5020909@cisco.com> Date: Wed, 21 Oct 2009 10:19:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <4ADE31D0.1000502@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 14:19:50.0102 (UTC) FILETIME=[8CC8D760:01CA5259] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:19:56 -0000 Christer Holmberg wrote: > Hi, > >>> The way that C-D works means that technically you *could* have >>> multiple parts with C-D of info-pkg. The question is >>> whether there is any value in making it legal. If so then somebody has > to >>> define what it means. Since we have multipart which already has lots > of ways to >>> group parts, why do we need to introduce yet another grouping >>> mechanism here? >> I agree with Paul -- the myriad MIME multipart types are >> pretty much infinitely flexible. I think the correct way to >> nail this down is to mandate that an INFO contains exactly >> one or zero parts with a C-D of info-pkg. While this does >> need to be flexible, I can't imagine any level of flexibility >> that MIME doesn't currently provide. >> >> Above all, we really don't want to make how INFO uses MIME >> any more complicated than necessary. > > I don't see what the problem is in allowing multiple body parts with C-D > 'info-package'. In most real-life cases I think there will be only one > 'info-package' body part in any case. Mechanically there is no problem. The problem is defining what it means and how it should be processed. Mechanically there is no problem with putting two body parts in an INVITE, both with C-D of "session" and C-T of application/sdp. But if you did that it would cause no end of grief. > 1. Assume that we have a multipart/mime which contains only I-P parts, > and define C-D 'info-package' for that multipart/mime. Does that > automatically give C-D 'info-package' to all body parts within that > multipart/mime? Or, will they be assigned whatever default value? No. Why does it matter? What does it mean if I send a letter, addressed to you, and it *contains* other letters addressed to Adam and John? If I include no instructions saying what I expect you to do with them, then you will have to guess. Or I could include instructions saying "in the event of my death, send these". Or I could include instructions saying "read these letters that I was thinking of sending, and let me know what you think. Then destroy them." Or ... I might have an Info Pkg that contains copies of old sip messages, which in turn might contain bodies with arbitrary C-D values. > 2. Assume a UA sends an INFO with multipart/mime, which contains a > number of body parts. Then someone wants to insert a non-I-P body part. > How can we ensure that "someone" won't insert that non-I-P body part > within the same multipart/mime which contains the I-P stuff? How can we > ensure that "someone" will move the existing multipart/mime body, with > the I-P stuff, into a second level multipart/mime? We should assume that they will do something reasonable, consistent with normal use of multipart in sip. If the existing multipart has a C-D of info-pkg, then they should not be inserting something arbitrary into it. (Imagine what would happen if the existing body was a multipart/alternative and someone decided to stick their unrelated stuff into it.) So in the case you describe they will have to: - create a multipart/mixed - insert the existing multipart into it as one part - insert their new part into it. If you are worried about this, then include text indicating that unrelated parts should not be inserted into a multipart with C-D of info-pkg. This out to be obvious, since the content of the info-pkg ought to be defined for the particular pkg type, and presumably won't include permitting these unrelated parts. But apparently it isn't obvious so documenting it would be a good thing. > So, I think there is no problem in allowing multiple body parts with C-D > 'info-package'. It causes no problem for the SIP stack, and the > application will deal with it. > > Please also remember that we only allow an INFO request to be associated > with a single Info Package, so one will always know that all body parts > with C-D 'info-package' are associated with the package indicated in the > Info-Package header. *If* this is allowed, then the specification for a particular info-pkg must specify if this is permitted and if so how it should be processed. That should be called out somewhere. Thanks, Paul From pkyzivat@cisco.com Wed Oct 21 07:44:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79FD3A6914 for ; Wed, 21 Oct 2009 07:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0b8zFoB0+A2 for ; Wed, 21 Oct 2009 07:44:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 11DD63A67F0 for ; Wed, 21 Oct 2009 07:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=11687; q=dns/txt; s=rtpiport02001; t=1256136267; x=1257345867; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2010:44:25=20-0400|Message-ID:=20<4ADF1E49. 5030804@cisco.com>|To:=20"Elwell,=20John"=20|CC:=20Christer=20Holmberg=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20"draft-ietf-sipcore-info-events@tools.ietf .org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<7402509E63C5A145A6095D46C179A5B7148B2BC4 @DEMCHP99E35MSX.ww902.siemens.net>|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP 99E35MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com >=20<7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35 MSX.ww902.siemens.net>=20=20<4ADE168F.70603 03@cisco.com>=20=20<4ADE227C.5020500@cisco. com>=20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99 E35MSX.ww902.siemens.net>; bh=f0l8rlKjMoLulGHe48EiUrklorwtxjxEnT+/SNRXFCk=; b=kk1b0y+59utl6wqcipVW9ILCZQWWWmeAxUHKCiwKGiI/Kqchp3Q220aq nzdfqUXSH6vZLJrGvqc/VQBEBPJLWyNL9YuKfR7eceslH+ADwMRm3FK4v +KOdib6J8c356o52lD8Rx32YW8RYdSxHXrLLC5MhRn/zrGedU85Q7U/YU U=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKG63kpAZnwM/2dsb2JhbADDQZhXhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208";a="64167649" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2009 14:44:26 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LEiQ7S000587; Wed, 21 Oct 2009 14:44:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:44:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:44:25 -0400 Message-ID: <4ADF1E49.5030804@cisco.com> Date: Wed, 21 Oct 2009 10:44:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 14:44:25.0643 (UTC) FILETIME=[FC4687B0:01CA525C] Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 14:44:19 -0000 Elwell, John wrote: > Christer, > > I tend to agree with Paul, and this is the text I would propose: Good text, with a couple of tweaks below. My main concern is that the I-P body part may be any kind of multipart, not just multipart/mixed. > For 7.6: > "The Info Package specification MUST define what type of > body part is associated with the Info Package, and MUST refer > to specifications where the syntax, semantics and MIME type of that > body part (and, if multipart/mixed, any child body parts) are described." > > For 4.3: > "The purpose of the INFO request is to carry application level information between SIP UAs. The application data associated with an Info Package is carried as a body part in the message body of the INFO request. This body part is identified by a MIME type, which can be multipart/mixed, in which case the body part has child body parts. In accordance with section 7.6, the Info Package specification defines the type of body part. In above, replace "multipart/mixed" with simple "multipart". Any kind of multipart could be applicable here. > An INFO request message body can contain just the body part associated with the Info Package, or this body part along with other body parts (not related to the Info Package but relating to other SIP extensions) in a message body of type multipart/mixed. > > If a UA indicates that it is willing to receive a specific Info Package, it means that the UA also supports the associated body part MIME type associated with that Info Package. However, the UA MUST still indicate support of that MIME type, and any child MIME types, in the Accept header field, according to the procedures in [RFC3261]. > > UAs MUST conform to [RFC3261], as updated by body-handling [I-D.ietf-sip-body-handling], to support multipart MIME handling. Body-handling is now RFC 5621. > The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package', in order easily to distinguish payloads associated with the Info Package from other payloads. If the message body only contains the single body part associated with the Info-Package, the SIP level Content-Disposition header field MUST contain value 'Info-Package'. If the message body is of type multipart/mixed, the child body part associated with the Info-Package MUST include a Content-Disposition header field with value 'Info-Package'. Child body parts of a multipart/mixed body part associated with the Info-Package do not require this Content-Disposition value. Some slight rewording suggestions: ... If the message body is of type multipart/mixed, * and the Content-Disposition is "render" or unspecified, the child body part associated with the Info-Package MUST include a Content-Disposition header field with value 'Info-Package'. Child body * parts of a multipart body part associated with the Info-Package do not * ^^^^^^^^^^ require this Content-Disposition value. In the above I added "and the Content-Disposition is "render" or unspecified". I wish we had specified a specific C-D for the top level multipart that contains unrelated body parts in a sip message. Somehow that got missed in body-handling, though it would have been an issue for backward compatibility. Thanks, Paul > NOTE: To avoid corner cases with legacy INFO usage, the Info-Package header field is used to indicate the Info Package name, rather than using a Content-Disposition header field parameter in order to indicate the name." > > How does this sound? > > John > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 October 2009 21:50 >> To: Christer Holmberg >> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; >> draft-ietf-sipcore-info-events@tools.ietf.org >> Subject: Re: [sipcore] WGLC comments >> (draft-ietf-sipcore-info-events-01) - John E's comments - >> non-I-P body parts in INFO? >> >> >> >> Christer Holmberg wrote: >>> Hi, >>> >>>> It sounds like we may have different conceptions of how body parts >>> might be strung together for this. >>>> If I read your text below correctly, then it would be >> possible for the >>> INFO message to have a multipart mixed body, where some >> body parts are >>> not part of the info package (authentication stuff, geoloc >>>> stuff), but where one *or more* other parts are considered >> part of the >>> info package. >>> >>> Section 4.3 talks about "SIP extensions that are orthogonal >> to INFO MAY >>> insert body parts unrelated to the Info Package". >>> >>> Personally, though, I doubt that someone would say "Hey, someone is >>> about the send an INFO, so I'll throw in my message body part there >>> too!". I think that any application who wants to send an >> INFO (no matter >>> whether it's legacy of I-P based, should trigger a >> dedicated INFO, and >>> not try to get a "free ride" by someone else... >> The way I envision this might happen would be because of some >> optional >> header inserted in the message that has a reference to a body >> part, via >> a cid: url. I guess INFO can't have Alert-Info, but if it could then >> that would be one example. >> >> Another example might be an AIB body. >> >> Most are pretty far fetched for INFO, but we should not exclude the >> possibility. >> >>>> It was my thinking that there will always be *one* body >> part that is >>> the root of all stuff that is associated with the info >> package. In the >>> simplest case this would be the whole body of the message, >>>> containing for example DTMF info. In a slightly more >> complicated case >>> it might be that same DTMF body, but as one body part in a >>> multipart/mixed, where the other body parts are for >> incidental purposes >>>> but not part of the info package. >>> Personally I agree with you, but the text has been there for a while >>> already. If people want to remove it, though, I am happy to do it. >> The way that C-D works means that technically you *could* >> have multiple >> parts with C-D of info-pkg. The question is whether there is >> any value >> in making it legal. If so then somebody has to define what it means. >> Since we have multipart which already has lots of ways to >> group parts, >> why do we need to introduce yet another grouping mechanism here? >> >>>> In cases where the info package itself needs more than one >> body part, >>> it would consist of a multipart containing all of its >> pieces. Then that >>> multipart would be just as above - either the only thing in >>>> the message, or else it would be a multipart within a >> multipart, along >>> with other incidental parts. >>> >>> Just to make sure: even if we say that all body parts must >> be associated >>> with the Info Package, do you agree that they ALL still >> shall have a C-D >>> with 'info-package'? Otherwise parsers may assign whatever >> the default >>> C-D value is for them, and we don't want that to happen... >> NO, I don't agree. >> >> These are nested structures. They may come from some other >> place and be >> formed and processed by non-sip code that knows nothing of info-pkg. >> Once you unwrap the first box, I think you should be allowed to have >> whatever you want inside. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>>> Your explanation sounds reasonable. I think it requires some >>>> clarification in both 7.6 and 4.3: >>>>> - in 7.6 it should talk about a body part, which may be multipart; >>>> 7.6 shall definitely be changed. It should say "body parts". >>>> >>>> "7.6. INFO Message Body >>>> >>>> The Info Package specification MUST define what type of >> message body >>>> parts, are associated with the Info Package, and MUST refer to >>>> specifications where the syntax, semantics and MIME type of each >>>> message body part is described." >>>> >>>> - The old text used to say "message bodies, if any", but I >> removed "if >>>> any" due to the change that the Info Package shall not assume on >>>> information being conveyed in SIP headers (see other e-mail). >>>> >>>> ------------- >>>> >>>>> - in 4.3 it should talk about labelling the Info-Package >> body part >>>>> with >>>> Content-Disposition: Info-Package, this being at the SIP >> level if it >>>> is the sole body part (i.e., the entire body of the SIP >>>>> message). >>>> Yes. Basically the text shall say that each message body part >>>> associated with the Info Package shall have a associated >> C-D header >>>> filed with an 'info-package' value. And, if there is only a single >>>> body part in a message the SIP level C-D header field contains the >>> 'info-package' >>>> value. >>>> >>>> Also, 4.3 talks about "message body payloads", but I will >> change to >>>> "message body parts" there, to be consistent with 7.6. >>>> >>>> NOTE: The new 4.3 text below may also contain changes I've already >>>> done based on other comments: >>>> >>>> "4.3. INFO Request Message Body >>>> >>>> The purpose of the INFO request is to carry application level >>>> information between SIP UAs. The application data >> associated with >>> an >>>> Info Package is carried as a payload in the message body of >>>> the INFO request. >>>> >>>> An INFO request message body can contain a single body part, or >>>> multiple >>>> body parts (multipart/mixed). >>>> >>>> Info Package specifications MUST describe the application level >>>> information associated with the Info Package. Message body parts >>>> MUST have a MIME type value defined. >>>> >>>> If a UA indicates that it is willing to receive a specific Info >>>> Package, it means that the UA also supports any >> associated message >>>> body MIME type associated with the Info Package. >> However, the UA >>>> MUST still indicate support of those MIME types also in >> the Accept >>>> header field, according to the procedures in [RFC3261]. >>>> >>>> Some SIP extensions that are orthogonal to INFO MAY insert body >>> parts >>>> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >>>> updated by body-handling [I-D.ietf-sip-body-handling] to support >>>> multipart MIME handling. >>>> >>>> Each message body part associated with an Info Package MUST >>>> contain a Content-Disposition header field with an >> 'Info-Package' >>>> value, in order to in an easy way distinguish payloads >> associated >>>> with the Info Package from other payloads. >>>> >>>> If the message body only contains a single body part, >> the SIP level >>>> Content-Disposition header field >>>> contains an 'info-package' value. >>>> >>>> If the message body contains multiple body parts >> (multipart/mixed) >>>> the SIP level Content-Disposition header field >>>> does not need to include an 'info-package' value, since >> each body >>>> part associated with the Info Package will include >>>> a Content-Disposition header field for that specific body part. >>>> >>>> NOTE: To avoid corner cases with legacy INFO usage, the >>> Info-Package >>>> header field is used to indicate the Info Package name, >> rather than >>>> to use a Content-Disposition header field parameter in order to >>>> indicate the name." >>>> >>>> ------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> From christer.holmberg@ericsson.com Wed Oct 21 11:32:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5660B3A685C for ; Wed, 21 Oct 2009 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCnVYrElmZoY for ; Wed, 21 Oct 2009 11:32:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9ACF13A67F7 for ; Wed, 21 Oct 2009 11:32:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-3c-4adf53bdf530 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9A.4A.04191.DB35FDA4; Wed, 21 Oct 2009 20:32:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:32:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 20:32:28 +0200 Message-ID: In-Reply-To: <4ADF1886.5020909@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSWZh5AhzCnUEMQ9ut/ZniC/OuWgAH9XwA References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <4ADE31D0.1000502@estacado.net> <4ADF1886.5020909@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 18:32:29.0560 (UTC) FILETIME=[D8868F80:01CA527C] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:32:27 -0000 Hi,=20 >>>>>The way that C-D works means that technically you *could* have=20 >>>>>multiple parts with C-D of info-pkg. The question is whether there=20 >>>>>is any value in making it legal. If so then somebody has >>>>>to define what it means. Since we have multipart which already has lots >>>>>of ways to group parts, why do we need to introduce yet another grouping=20 >>>>>mechanism here? >>>I agree with Paul -- the myriad MIME multipart types are pretty much=20 >>>infinitely flexible. I think the correct way to nail this down is to=20 >>>mandate that an INFO contains exactly one or zero parts with a C-D of >>>info-pkg. While this does need to be flexible, I can't imagine any=20 >>>level of flexibility that MIME doesn't currently provide. >>> >>>Above all, we really don't want to make how INFO uses MIME any more=20 >>>complicated than necessary. >>=20 >>I don't see what the problem is in allowing multiple body parts with=20 >>C-D 'info-package'. In most real-life cases I think there will be only >>one 'info-package' body part in any case. > >Mechanically there is no problem. The problem is defining what it means and how it should be processed. The Info Package specification defines what each body part means, and how it should be processes. That will have to be done even in the cases where all I-P body parts are inside a multipart. >Mechanically there is no problem with putting two body parts in an INVITE, both with C-D of "session" and C-T of application/sdp. But if you did that it would cause no end of grief. Not if you specified how to handle such cases, which is what an I-P specification is supposed to do.=20 And, you would end up with the same grief if you would put both the "session" application/sdp body parts inside a multipart. In addition, I think it is said somewhere that a message body must not contain mutliple C-T application/sdp, so it could be considered a protocol error. ------------- >>1. Assume that we have a multipart/mime which contains only I-P parts, >>and define C-D 'info-package' for that multipart/mime. Does that=20 >>automatically give C-D 'info-package' to all body parts within that=20 >>multipart/mime? Or, will they be assigned whatever default value? > >No. Why does it matter? It does matter. The spec says that all I-P body parts shall have C-D 'info-package', so the parser shall not assign some other C-D value to the I-P body parts. If they don't contain a C-D value, the parser may assign "render", which is the default, which could confuse the application... >What does it mean if I send a letter, addressed to you, and it *contains* other letters addressed to Adam and John? If I include no instructions saying what I expect you to do with them, then you will=20 >have to guess. Or I could include instructions saying "in the event of my death, send these". Or I could include instructions saying "read these letters that I was thinking of sending, and let me know=20 >what you think. Then destroy them." Or ... I am not sure I understand... Again, we say that I-P body parts shall have C-D 'info-package', so I don't think we should say it is ok for the parser to assign other C-D values to them... ------------- >I might have an Info Pkg that contains copies of old sip messages, which in turn might contain bodies with arbitrary C-D values. Sure, but then those C-D values are part of the payload data of that body - the C-D value of the body itself shall still be 'info-package'. ------------- >>2. Assume a UA sends an INFO with multipart/mime, which contains a=20 >>number of body parts. Then someone wants to insert a non-I-P body part. >>How can we ensure that "someone" won't insert that non-I-P body part=20 >>within the same multipart/mime which contains the I-P stuff? How can=20 >>we ensure that "someone" will move the existing multipart/mime body,=20 >>with the I-P stuff, into a second level multipart/mime? > >We should assume that they will do something reasonable, consistent with normal use of multipart in sip. What is reasonable, and where is it specified? ------------- >If the existing multipart has a C-D of info-pkg, then they should not be inserting something arbitrary into it. (Imagine what would happen if the existing body was a multipart/alternative and someone=20 >decided to stick their unrelated stuff into it.) I can agree in the case of multipart/alternative, and personally I think/agree it should be the same for all multiparts. But, unless it is specified for multipart/mixed I am not sure we can assume that everyone would have the same understanding. ------------- >So in the case you describe they will have to: >- create a multipart/mixed >- insert the existing multipart into it as one part >- insert their new part into it. > >If you are worried about this, then include text indicating that unrelated parts should not be inserted into a multipart with C-D of info-pkg. This out to be obvious, since the content of the info-pkg=20 >ought to be defined for the particular pkg type, and presumably won't include permitting these unrelated parts. But apparently it isn't obvious so documenting it would be a good thing. We can put whatever text in the document, and I agree we could say something about this. BUT, that is not the problem. The extra parts may be inserted by existing entities/applications which do not support the I-P mechanism. ------------- >>So, I think there is no problem in allowing multiple body parts with=20 >>C-D 'info-package'. It causes no problem for the SIP stack, and the=20 >>application will deal with it. >>=20 >>Please also remember that we only allow an INFO request to be=20 >>associated with a single Info Package, so one will always know that=20 >>all body parts with C-D 'info-package' are associated with the package >>indicated in the Info-Package header. > >*If* this is allowed, then the specification for a particular info-pkg must specify if this is permitted and if so how it should be processed.=20 >That should be called out somewhere. There is a chapter talking about body parts for a specific I-P. Maybe some extra text could be added there.=20 ------------- Regards, Christer From christer.holmberg@ericsson.com Wed Oct 21 11:43:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363143A698F for ; Wed, 21 Oct 2009 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5GTB+jCovLA for ; Wed, 21 Oct 2009 11:43:15 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A144D28C12B for ; Wed, 21 Oct 2009 11:43:14 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-7b-4adf56499bf3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 16.41.08816.9465FDA4; Wed, 21 Oct 2009 20:43:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:43:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 20:43:20 +0200 Message-ID: In-Reply-To: <4ADF1E49.5030804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSXQWZa6JumiweQuiHNDwkTBklDgAIAMkQ References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 21 Oct 2009 18:43:21.0528 (UTC) FILETIME=[5D20FB80:01CA527E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:43:17 -0000 Hi,=20 >>Christer, >>=20 >>I tend to agree with Paul, and this is the text I would propose: > >Good text, with a couple of tweaks below. My main concern is that the I-P body part may be any kind of multipart, not just multipart/mixed. > >For 7.6: >"The Info Package specification MUST define what type of body part is=20 >associated with the Info Package, and MUST refer to specifications=20 >where the syntax, semantics and MIME type of that body part (and, if=20 >multipart/mixed, any child body parts) are described." >=20 >For 4.3: >"The purpose of the INFO request is to carry application level information between SIP UAs. The application data associated with an Info Package is carried as a body part in the message body of the INFO=20 >request. This body part is identified by a MIME type, which can be multipart/mixed, in which case the body part has child body parts. In accordance with section 7.6, the Info Package specification=20 >defines the type of body part. > >In above, replace "multipart/mixed" with simple "multipart". Any kind of multipart could be applicable here. > >An INFO request message body can contain just the body part associated with the Info Package, or this body part along with other body parts (not related to the Info Package but relating to other SIP=20 >extensions) in a message body of type multipart/mixed. >=20 >If a UA indicates that it is willing to receive a specific Info Package, it means that the UA also supports the associated body part MIME type associated with that Info Package. However, the UA MUST still indicate support of that MIME type, and any child MIME types, in the Accept header field, according to the procedures in [RFC3261]. >=20 >UAs MUST conform to [RFC3261], as updated by body-handling [I-D.ietf-sip-body-handling], to support multipart MIME handling. > >Body-handling is now RFC 5621. I'll fix the reference. ---------------- > The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package', in order easily to distinguish payloads associated with the Info Package from=20 >other payloads. If the message body only contains the single body part associated with the Info-Package, the SIP level Content-Disposition header field MUST contain value 'Info-Package'. If the message=20 >body is of type multipart/mixed, the child body part associated with the Info-Package MUST include a Content-Disposition header field with value 'Info-Package'. Child body parts of a multipart/mixed body >part associated with the Info-Package do not require this Content-Disposition value. > >Some slight rewording suggestions: > > ... >" If the message body is of type multipart/mixed, >* and the Content-Disposition is "render" or unspecified, > the child body part associated with the Info-Package MUST include a > Content-Disposition header field with value 'Info-Package'. Child body >* parts of a multipart body part associated with the Info-Package do not >* ^^^^^^^^^^ > require this Content-Disposition value." I don't agree with that text. As I said earlier, RFC 5621 says that the C-D value of the "parent body part" (C-T multipart) is IRRELEVANT to the "child body parts" - they must explicitly be assigned individual C-T values, or they will be assigned a default value.=20 To use OOP language: a child body part does NOT inherit the C-D value of its parent :) So, therefor I don't think it really matters what the C-D value of the parent body part is, because it does not affect the child body parts. Regards, Christer In the above I added "and the Content-Disposition is "render" or unspecified". I wish we had specified a specific C-D for the top level multipart that contains unrelated body parts in a sip message. Somehow that got missed in body-handling, though it would have been an issue for backward compatibility. Thanks, Paul > NOTE: To avoid corner cases with legacy INFO usage, the Info-Package header field is used to indicate the Info Package name, rather than using a Content-Disposition header field parameter in order to indicate the name." >=20 > How does this sound? >=20 > John >=20 >=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 20 October 2009 21:50 >> To: Christer Holmberg >> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 >> draft-ietf-sipcore-info-events@tools.ietf.org >> Subject: Re: [sipcore] WGLC comments >> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P=20 >> body parts in INFO? >> >> >> >> Christer Holmberg wrote: >>> Hi, >>> >>>> It sounds like we may have different conceptions of how body parts >>> might be strung together for this. >>>> If I read your text below correctly, then it would be >> possible for the >>> INFO message to have a multipart mixed body, where some >> body parts are >>> not part of the info package (authentication stuff, geoloc >>>> stuff), but where one *or more* other parts are considered >> part of the >>> info package. >>> >>> Section 4.3 talks about "SIP extensions that are orthogonal >> to INFO MAY >>> insert body parts unrelated to the Info Package".=20 >>> >>> Personally, though, I doubt that someone would say "Hey, someone is=20 >>> about the send an INFO, so I'll throw in my message body part there=20 >>> too!". I think that any application who wants to send an >> INFO (no matter >>> whether it's legacy of I-P based, should trigger a >> dedicated INFO, and >>> not try to get a "free ride" by someone else... >> The way I envision this might happen would be because of some=20 >> optional header inserted in the message that has a reference to a=20 >> body part, via a cid: url. I guess INFO can't have Alert-Info, but if >> it could then that would be one example. >> >> Another example might be an AIB body. >> >> Most are pretty far fetched for INFO, but we should not exclude the=20 >> possibility. >> >>>> It was my thinking that there will always be *one* body >> part that is >>> the root of all stuff that is associated with the info >> package. In the >>> simplest case this would be the whole body of the message, >>>> containing for example DTMF info. In a slightly more >> complicated case >>> it might be that same DTMF body, but as one body part in a=20 >>> multipart/mixed, where the other body parts are for >> incidental purposes >>>> but not part of the info package. >>> Personally I agree with you, but the text has been there for a while >>> already. If people want to remove it, though, I am happy to do it. >> The way that C-D works means that technically you *could* have=20 >> multiple parts with C-D of info-pkg. The question is whether there is >> any value in making it legal. If so then somebody has to define what=20 >> it means. >> Since we have multipart which already has lots of ways to group=20 >> parts, why do we need to introduce yet another grouping mechanism=20 >> here? >> >>>> In cases where the info package itself needs more than one >> body part, >>> it would consist of a multipart containing all of its >> pieces. Then that >>> multipart would be just as above - either the only thing in >>>> the message, or else it would be a multipart within a >> multipart, along >>> with other incidental parts. >>> >>> Just to make sure: even if we say that all body parts must >> be associated >>> with the Info Package, do you agree that they ALL still >> shall have a C-D >>> with 'info-package'? Otherwise parsers may assign whatever >> the default >>> C-D value is for them, and we don't want that to happen... >> NO, I don't agree. >> >> These are nested structures. They may come from some other place and=20 >> be formed and processed by non-sip code that knows nothing of=20 >> info-pkg. >> Once you unwrap the first box, I think you should be allowed to have=20 >> whatever you want inside. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>>> Your explanation sounds reasonable. I think it requires some >>>> clarification in both 7.6 and 4.3: >>>>> - in 7.6 it should talk about a body part, which may be multipart; >>>> 7.6 shall definitely be changed. It should say "body parts". >>>> >>>> "7.6. INFO Message Body >>>> >>>> The Info Package specification MUST define what type of >> message body >>>> parts, are associated with the Info Package, and MUST refer to=20 >>>> specifications where the syntax, semantics and MIME type of each=20 >>>> message body part is described." >>>> >>>> - The old text used to say "message bodies, if any", but I >> removed "if >>>> any" due to the change that the Info Package shall not assume on=20 >>>> information being conveyed in SIP headers (see other e-mail). >>>> >>>> ------------- >>>> >>>>> - in 4.3 it should talk about labelling the Info-Package >> body part >>>>> with >>>> Content-Disposition: Info-Package, this being at the SIP >> level if it >>>> is the sole body part (i.e., the entire body of the SIP >>>>> message). >>>> Yes. Basically the text shall say that each message body part=20 >>>> associated with the Info Package shall have a associated >> C-D header >>>> filed with an 'info-package' value. And, if there is only a single=20 >>>> body part in a message the SIP level C-D header field contains the >>> 'info-package' >>>> value. >>>> >>>> Also, 4.3 talks about "message body payloads", but I will >> change to >>>> "message body parts" there, to be consistent with 7.6. >>>> >>>> NOTE: The new 4.3 text below may also contain changes I've already=20 >>>> done based on other comments: >>>> >>>> "4.3. INFO Request Message Body >>>> >>>> The purpose of the INFO request is to carry application level >>>> information between SIP UAs. The application data >> associated with >>> an >>>> Info Package is carried as a payload in the message body of >>>> the INFO request.=20 >>>> >>>> An INFO request message body can contain a single body part, or=20 >>>> multiple >>>> body parts (multipart/mixed). >>>> >>>> Info Package specifications MUST describe the application level >>>> information associated with the Info Package. Message body parts >>>> MUST have a MIME type value defined. >>>> >>>> If a UA indicates that it is willing to receive a specific Info >>>> Package, it means that the UA also supports any >> associated message >>>> body MIME type associated with the Info Package. =20 >> However, the UA >>>> MUST still indicate support of those MIME types also in >> the Accept >>>> header field, according to the procedures in [RFC3261]. >>>> >>>> Some SIP extensions that are orthogonal to INFO MAY insert body >>> parts >>>> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >>>> updated by body-handling [I-D.ietf-sip-body-handling] to support >>>> multipart MIME handling. >>>> >>>> Each message body part associated with an Info Package MUST >>>> contain a Content-Disposition header field with an >> 'Info-Package' >>>> value, in order to in an easy way distinguish payloads >> associated >>>> with the Info Package from other payloads.=20 >>>> >>>> If the message body only contains a single body part, >> the SIP level >>>> Content-Disposition header field >>>> contains an 'info-package' value. >>>> >>>> If the message body contains multiple body parts >> (multipart/mixed) >>>> the SIP level Content-Disposition header field >>>> does not need to include an 'info-package' value, since >> each body >>>> part associated with the Info Package will include >>>> a Content-Disposition header field for that specific body part. >>>> >>>> NOTE: To avoid corner cases with legacy INFO usage, the >>> Info-Package >>>> header field is used to indicate the Info Package name, >> rather than >>>> to use a Content-Disposition header field parameter in order to >>>> indicate the name." >>>> >>>> ------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> From christer.holmberg@ericsson.com Wed Oct 21 11:46:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B4F3A6A19 for ; Wed, 21 Oct 2009 11:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnEqURif++PY for ; Wed, 21 Oct 2009 11:46:18 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 25E4428C10D for ; Wed, 21 Oct 2009 11:45:35 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-3e-4adf56d7f7d7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D7.51.08816.7D65FDA4; Wed, 21 Oct 2009 20:45:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:45:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 20:45:42 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2D1D@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAPA7FkAACBsIgAA0t5PA= References: <7402509E63C5A145A6095D46C179A5B7148B2D1D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 21 Oct 2009 18:45:43.0274 (UTC) FILETIME=[B19DB4A0:01CA527E] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments - Introduction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:46:19 -0000 Hi,=20 >>>>1. I think the document would benefit from having a definition of=20 >>>>Info Package at some point early on. In section 1 we have "This=20 >>>>document defines a mechanism, using Info Packages, which provides=20 >>>>the possibility for UAs to indicate what INFO usages they support,=20 >>>>and to define content syntax and semantics for the data transported=20 >>>>in the INFO messages.", but that describes the mechanism, rather=20 >>>>than defining Info package. As a starter, how about something like: >>>>"A specified usage of the SIP INFO method, detailing the format and=20 >>>>semantics of information transported." >>>=20 >>>Sounds ok. Need to think where to put the text. >>=20 >>I rewrote the paragraph: >>=20 >>"This document defines a mechanism, using Info Packages.=20 >>An Info Package defines the content and semantics of an INFO usage. >>The Info Package mechanism also provides a way for UAs to indicate for >>which INFO usages they are willing to receive INFO requests. This=20 >>document defines the usage of the SIP INFO method, new SIP header=20 >>fields for the Info Package mechanism, and how to transport payload=20 >>information associated with an Info Package in INFO requests. >> =20 >>The mechanism is allows existing legacy INFO usages as defined in RFC 2976." >[JRE] We have two different usages of the word "usage" in this paragraph. "An INFO usage" near the start, which I think is intended to be a usage defined by an Info Package, and "usage of the SIP INFO=20 >message" later, which is what is defined in this document. We should at least avoid that. However, I have a bigger concern about the style of section 1, which I will raise in a new thread. I guess we could say "defines the cont and semnt of using the INFO method", and only use "usage" in the context of legacy. Regards, Christer From christer.holmberg@ericsson.com Wed Oct 21 12:26:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF603A690D for ; Wed, 21 Oct 2009 12:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT1aBv9fV-TC for ; Wed, 21 Oct 2009 12:26:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0952E3A67F5 for ; Wed, 21 Oct 2009 12:26:23 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-44-4adf606784b3 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id A6.6B.04191.7606FDA4; Wed, 21 Oct 2009 21:26:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 21:26:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 21:26:30 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSTQFTLWL/4JP/SFaGU9RvxSenuQAMlbqQ References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 21 Oct 2009 19:26:31.0384 (UTC) FILETIME=[64CDA580:01CA5284] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:26:25 -0000 Hi,=20 >Section 1 says what RFC 2976 does, says what its drawbacks are, and then says that this document describes a mechanism that addresses those drawbacks. It does not state that this document defines the=20 >INFO method. It even refers back to RFC 2976 for the definition of the INFO method ("The purpose of the INFO message [RFC2976] is.... "). > >Yet this document supposedly obsoletes RFC 2976. > >I would have expected the introduction to a document that obsoletes an earlier RFC to be self-standing and structured more like the following: >- Introductory text very similar to what is in the obsoleted RFC, but modified to mention anything that is significantly different. >- A reference back to the obsoleted RFC, describing what has changed. > >In this particular case, the text of RFC 2976 is a rough starting point. It even says, near the end, that the document does not specify specific uses, so that is an ideal point to continue and talk about=20 >usages, Info-Packages, and indicating supported usages. > >We could then continue by saying that the document obsoletes RFC 2976, which did not define the Info-Package concept and explicit indications of which usages are supported. I agree that we may refer/depend a little too much on RFC 2976 - and I think Robert commented on the same issue. It is probably some text which was useful during the justficiation phase, but should be changes. Basically we should only refer to 2976 when we talk about legacy INFO usage, and when we talk about the drawbacks of legacy INFO usage. Below is a re-write of the introduction, which I think addresses your issue.=20 (We could of course discuss whether 1.2 and 1.3 really should be in the introduction, or be moved to other places in the spec.) "1. Introduction 1.1 General This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC2976].=20 In addition, it defines an Info Package mechanism. An Info Package defines the content and semantics of the=20 information carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for UAs to indicate for=20 which types of applications and contexts they are willing to receive INFO requests. The document defines how the INFO method is used, new SIP header fields for the INFO method, and how to transport payload information associated with an Info Package using INFO requests.=20 =20 The purpose of the INFO message is to carry application level information between endpoints, using the SIP session signaling path. Note that the INFO method is not used to update characteristics of the SIP session, but to allow the applications which use the SIP session to exchange information. The Info Package mechanism does not define a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage. INFO messages cannot be sent as part of other dialog usages. If a UA supports the Info Package mechanism, it uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate a new set of Info Packages at any time during the lifetime of the invite dialog usage. A UA can use a "nil" value to indicate that it is not willing to receive any Info Packages at a certain moment, but that the UA still supports the Info Package mechanism. When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with the request. One particular INFO request can only be associated with a single Info Package. This document obosoletes [RFC2976]. However, for backward compability it allows to use INFO per [RFC2976], referred to as legacy INFO usage in the document. 1.2 Problems with leagcy INFO usage While legacy INFO usage [RFC2976] has been widely adopted for specific application use cases, such as ISUP and DTMF exchange, [RFC2976] does not not define a mechanisms for SIP UAs to indicate for which types of applications and contexts they support the INFO method.what usages of INFO. In addition, [RFC2976] does not provide a mechanism to explicitly indicate the type of application and context for which a specific INFO message is associated to. In some cases it can be determined by the INFO message body payload content, but not in a general way. Example: If the Content-Type is "image/jpeg", the MIME-attached content is a JPEG image. Still, there are many useful ways a UA can render an image. The image could be a caller-id picture, a contact icon, a photo for sharing, and so on. The sender does not know which image to send to the receiver if the receiver supports an image content type. Likewise, the receiver does not know the context of an image the client is sending if the receiver supports receiving more than one image content type. Due to the problems described above, legacy INFO usages often require static configuration about for what type of applications and contexts UAs support the INFO method,=20 and the way they handle application information transported in INFO messages. That has caused interoperability problems in the industry. Therefore,a need for a well defined and documented description of what the information sent in the INFO is used for has been identified. This situation is analogous to the context issue in Internet Mail [RFC3458]. 1.3 Relationship to subscription-based event Event Packages [RFC3265] perform the role of disambiguating the context of a message for subscription-based events. The Info Package mechanism provides similar functionality for application information exchange using invite dialog usages [RFC5057]. However, there is no formal relationship between the Info Package mechanism and the subscription-based event mechanism." Regards, Christer From john.elwell@siemens-enterprise.com Wed Oct 21 12:32:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9C43A6842 for ; Wed, 21 Oct 2009 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5rOr7cONDoj for ; Wed, 21 Oct 2009 12:32:40 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 8D5203A67F5 for ; Wed, 21 Oct 2009 12:32:39 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJWKBw002904; Wed, 21 Oct 2009 21:32:20 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJWK1b002737; Wed, 21 Oct 2009 21:32:20 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 21 Oct 2009 21:32:19 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Wed, 21 Oct 2009 21:32:15 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSXP5NKIdY5FsSToeGmTgwcdof2QAAfQIA Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> In-Reply-To: <4ADF1E49.5030804@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:32:41 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 21 October 2009 15:44 > To: Elwell, John > Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo=20 > Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body parts in INFO? >=20 >=20 >=20 > Elwell, John wrote: > > Christer, > >=20 > > I tend to agree with Paul, and this is the text I would propose: >=20 > Good text, with a couple of tweaks below. My main concern is that the=20 > I-P body part may be any kind of multipart, not just multipart/mixed. >=20 > > For 7.6: > > "The Info Package specification MUST define what type of=20 > > body part is associated with the Info Package, and MUST refer > > to specifications where the syntax, semantics and MIME type of that=20 > > body part (and, if multipart/mixed, any child body parts)=20 > are described."=20 > >=20 > > For 4.3: > > "The purpose of the INFO request is to carry application=20 > level information between SIP UAs. The application data=20 > associated with an Info Package is carried as a body part in=20 > the message body of the INFO request. This body part is=20 > identified by a MIME type, which can be multipart/mixed, in=20 > which case the body part has child body parts. In accordance=20 > with section 7.6, the Info Package specification defines the=20 > type of body part. >=20 > In above, replace "multipart/mixed" with simple "multipart".=20 > Any kind of=20 > multipart could be applicable here. [JRE] I wasn't sure. I am happy to make that change. >=20 > > An INFO request message body can contain just the body part=20 > associated with the Info Package, or this body part along=20 > with other body parts (not related to the Info Package but=20 > relating to other SIP extensions) in a message body of type=20 > multipart/mixed. > >=20 > > If a UA indicates that it is willing to receive a specific=20 > Info Package, it means that the UA also supports the=20 > associated body part MIME type associated with that Info=20 > Package. However, the UA MUST still indicate support of that=20 > MIME type, and any child MIME types, in the Accept header=20 > field, according to the procedures in [RFC3261]. > >=20 > > UAs MUST conform to [RFC3261], as updated by body-handling=20 > [I-D.ietf-sip-body-handling], to support multipart MIME handling. >=20 > Body-handling is now RFC 5621. >=20 > > The body part associated with the Info Package MUST contain=20 > a Content-Disposition header field with value 'Info-Package',=20 > in order easily to distinguish payloads associated with the=20 > Info Package from other payloads. If the message body only=20 > contains the single body part associated with the=20 > Info-Package, the SIP level Content-Disposition header field=20 > MUST contain value 'Info-Package'. If the message body is of=20 > type multipart/mixed, the child body part associated with the=20 > Info-Package MUST include a Content-Disposition header field=20 > with value 'Info-Package'. Child body parts of a=20 > multipart/mixed body part associated with the Info-Package do=20 > not require this Content-Disposition value. >=20 > Some slight rewording suggestions: >=20 > ... > If the message body is of type multipart/mixed, > * and the Content-Disposition is "render" or unspecified, > the child body part associated with the Info-Package MUST include a > Content-Disposition header field with value=20 > 'Info-Package'. Child body > * parts of a multipart body part associated with the=20 > Info-Package do not > * ^^^^^^^^^^ > require this Content-Disposition value. >=20 > In the above I added "and the Content-Disposition is "render" or=20 > unspecified".=20 [JRE] But wouldn't that then conflict with the first of my proposed sentenc= es? The first sentence says "The body part associated with the Info Package= MUST contain a Content-Disposition header field with value 'Info-Package'"= . Your modified second sentence then seems to contradict it by saying only = in certain circumstances does it need to do this. John > I wish we had specified a specific C-D for the=20 > top level=20 > multipart that contains unrelated body parts in a sip=20 > message. Somehow=20 > that got missed in body-handling, though it would have been=20 > an issue for=20 > backward compatibility. >=20 > Thanks, > Paul >=20 > > NOTE: To avoid corner cases with legacy INFO usage, the=20 > Info-Package header field is used to indicate the Info=20 > Package name, rather than using a Content-Disposition header=20 > field parameter in order to indicate the name." > >=20 > > How does this sound? > >=20 > > John > >=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > >> Sent: 20 October 2009 21:50 > >> To: Christer Holmberg > >> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 > >> draft-ietf-sipcore-info-events@tools.ietf.org > >> Subject: Re: [sipcore] WGLC comments=20 > >> (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > >> non-I-P body parts in INFO? > >> > >> > >> > >> Christer Holmberg wrote: > >>> Hi,=20 > >>> > >>>> It sounds like we may have different conceptions of how=20 > body parts > >>> might be strung together for this. > >>>> If I read your text below correctly, then it would be=20 > >> possible for the > >>> INFO message to have a multipart mixed body, where some=20 > >> body parts are > >>> not part of the info package (authentication stuff, geoloc=20 > >>>> stuff), but where one *or more* other parts are considered=20 > >> part of the > >>> info package. > >>> > >>> Section 4.3 talks about "SIP extensions that are orthogonal=20 > >> to INFO MAY > >>> insert body parts unrelated to the Info Package".=20 > >>> > >>> Personally, though, I doubt that someone would say "Hey,=20 > someone is > >>> about the send an INFO, so I'll throw in my message body=20 > part there > >>> too!". I think that any application who wants to send an=20 > >> INFO (no matter > >>> whether it's legacy of I-P based, should trigger a=20 > >> dedicated INFO, and > >>> not try to get a "free ride" by someone else... > >> The way I envision this might happen would be because of some=20 > >> optional=20 > >> header inserted in the message that has a reference to a body=20 > >> part, via=20 > >> a cid: url. I guess INFO can't have Alert-Info, but if it=20 > could then=20 > >> that would be one example. > >> > >> Another example might be an AIB body. > >> > >> Most are pretty far fetched for INFO, but we should not=20 > exclude the=20 > >> possibility. > >> > >>>> It was my thinking that there will always be *one* body=20 > >> part that is > >>> the root of all stuff that is associated with the info=20 > >> package. In the > >>> simplest case this would be the whole body of the message,=20 > >>>> containing for example DTMF info. In a slightly more=20 > >> complicated case > >>> it might be that same DTMF body, but as one body part in a > >>> multipart/mixed, where the other body parts are for=20 > >> incidental purposes=20 > >>>> but not part of the info package. > >>> Personally I agree with you, but the text has been there=20 > for a while > >>> already. If people want to remove it, though, I am happy to do it. > >> The way that C-D works means that technically you *could*=20 > >> have multiple=20 > >> parts with C-D of info-pkg. The question is whether there is=20 > >> any value=20 > >> in making it legal. If so then somebody has to define what=20 > it means.=20 > >> Since we have multipart which already has lots of ways to=20 > >> group parts,=20 > >> why do we need to introduce yet another grouping mechanism here? > >> > >>>> In cases where the info package itself needs more than one=20 > >> body part, > >>> it would consist of a multipart containing all of its=20 > >> pieces. Then that > >>> multipart would be just as above - either the only thing in=20 > >>>> the message, or else it would be a multipart within a=20 > >> multipart, along > >>> with other incidental parts. > >>> > >>> Just to make sure: even if we say that all body parts must=20 > >> be associated > >>> with the Info Package, do you agree that they ALL still=20 > >> shall have a C-D > >>> with 'info-package'? Otherwise parsers may assign whatever=20 > >> the default > >>> C-D value is for them, and we don't want that to happen... > >> NO, I don't agree. > >> > >> These are nested structures. They may come from some other=20 > >> place and be=20 > >> formed and processed by non-sip code that knows nothing of=20 > info-pkg.=20 > >> Once you unwrap the first box, I think you should be=20 > allowed to have=20 > >> whatever you want inside. > >> > >> Thanks, > >> Paul > >> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>> > >>> Christer Holmberg wrote: > >>>> Hi, > >>>> > >>>>> Your explanation sounds reasonable. I think it requires some > >>>> clarification in both 7.6 and 4.3: > >>>>> - in 7.6 it should talk about a body part, which may be=20 > multipart; > >>>> 7.6 shall definitely be changed. It should say "body parts". > >>>> > >>>> "7.6. INFO Message Body > >>>> > >>>> The Info Package specification MUST define what type of=20 > >> message body=20 > >>>> parts, are associated with the Info Package, and MUST refer to=20 > >>>> specifications where the syntax, semantics and MIME type of each=20 > >>>> message body part is described." > >>>> > >>>> - The old text used to say "message bodies, if any", but I=20 > >> removed "if > >>>> any" due to the change that the Info Package shall not assume on=20 > >>>> information being conveyed in SIP headers (see other e-mail). > >>>> > >>>> ------------- > >>>> > >>>>> - in 4.3 it should talk about labelling the Info-Package=20 > >> body part=20 > >>>>> with > >>>> Content-Disposition: Info-Package, this being at the SIP=20 > >> level if it=20 > >>>> is the sole body part (i.e., the entire body of the SIP > >>>>> message). > >>>> Yes. Basically the text shall say that each message body part=20 > >>>> associated with the Info Package shall have a associated=20 > >> C-D header=20 > >>>> filed with an 'info-package' value. And, if there is=20 > only a single=20 > >>>> body part in a message the SIP level C-D header field=20 > contains the > >>> 'info-package' > >>>> value. > >>>> > >>>> Also, 4.3 talks about "message body payloads", but I will=20 > >> change to=20 > >>>> "message body parts" there, to be consistent with 7.6. > >>>> > >>>> NOTE: The new 4.3 text below may also contain changes=20 > I've already=20 > >>>> done based on other comments: > >>>> > >>>> "4.3. INFO Request Message Body > >>>> > >>>> The purpose of the INFO request is to carry application level > >>>> information between SIP UAs. The application data=20 > >> associated with > >>> an > >>>> Info Package is carried as a payload in the message body of > >>>> the INFO request.=20 > >>>> > >>>> An INFO request message body can contain a single=20 > body part, or=20 > >>>> multiple > >>>> body parts (multipart/mixed). > >>>> > >>>> Info Package specifications MUST describe the=20 > application level > >>>> information associated with the Info Package. Message=20 > body parts > >>>> MUST have a MIME type value defined. > >>>> > >>>> If a UA indicates that it is willing to receive a=20 > specific Info > >>>> Package, it means that the UA also supports any=20 > >> associated message > >>>> body MIME type associated with the Info Package. =20 > >> However, the UA > >>>> MUST still indicate support of those MIME types also in=20 > >> the Accept > >>>> header field, according to the procedures in [RFC3261]. > >>>> > >>>> Some SIP extensions that are orthogonal to INFO MAY=20 > insert body > >>> parts > >>>> unrelated to the Info Package. UAs MUST conform to=20 > [RFC3261] as > >>>> updated by body-handling [I-D.ietf-sip-body-handling]=20 > to support > >>>> multipart MIME handling. > >>>> > >>>> Each message body part associated with an Info Package MUST > >>>> contain a Content-Disposition header field with an=20 > >> 'Info-Package' > >>>> value, in order to in an easy way distinguish payloads=20 > >> associated > >>>> with the Info Package from other payloads.=20 > >>>> > >>>> If the message body only contains a single body part,=20 > >> the SIP level > >>>> Content-Disposition header field > >>>> contains an 'info-package' value. > >>>> > >>>> If the message body contains multiple body parts=20 > >> (multipart/mixed)=20 > >>>> the SIP level Content-Disposition header field > >>>> does not need to include an 'info-package' value, since=20 > >> each body=20 > >>>> part associated with the Info Package will include > >>>> a Content-Disposition header field for that specific=20 > body part. > >>>> > >>>> NOTE: To avoid corner cases with legacy INFO usage, the > >>> Info-Package > >>>> header field is used to indicate the Info Package name,=20 > >> rather than > >>>> to use a Content-Disposition header field parameter=20 > in order to > >>>> indicate the name." > >>>> > >>>> ------------- > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > = From pkyzivat@cisco.com Wed Oct 21 12:41:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E8E3A69A4 for ; Wed, 21 Oct 2009 12:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.55 X-Spam-Level: X-Spam-Status: No, score=-8.55 tagged_above=-999 required=5 tests=[AWL=2.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S2iJzuccqA4 for ; Wed, 21 Oct 2009 12:41:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 225113A6842 for ; Wed, 21 Oct 2009 12:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=15198; q=dns/txt; s=amsiport01001; t=1256154091; x=1257363691; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2015:41:01=20-0400|Message-ID:=20<4ADF63CD. 5050707@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20draft-ietf-sipcore-info-events@tools.ietf. org|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20=20<4ADE227C.5020500@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20; bh=kd8mA2Wkm8fDBbJ1kUXOZeqgV7orZjRrhDQ6cAxnlZ8=; b=nu1tCjYwhbG5VfvnNj9ap4Rvyi6Dv5kH1u5v1b0Uxl8FWmE3wAzcYvFD uJFZ7sE5L93ddAiEC40aoCWY9/syvsciBGkKg4V/DyIQYjwt6JLOvlo1o CRMSIJGeHlUNtiF8q0JuTyGPyyG2HJh9C91O9+VW+diJmSD47E+pHmpEu A=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwAAKsA30qQ/uCWe2dsb2JhbACbJQEBFiQGp2KYY4QxBIJV X-IronPort-AV: E=Sophos;i="4.44,599,1249257600"; d="scan'208";a="52414579" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2009 19:41:29 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LJfTtV000593; Wed, 21 Oct 2009 19:41:29 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 21:41:29 +0200 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 21:41:29 +0200 Message-ID: <4ADF63CD.5050707@cisco.com> Date: Wed, 21 Oct 2009 15:41:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 19:41:29.0115 (UTC) FILETIME=[7BE486B0:01CA5286] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:41:25 -0000 Inline, down aways. Christer Holmberg wrote: > Hi, > >>> Christer, >>> >>> I tend to agree with Paul, and this is the text I would propose: >> Good text, with a couple of tweaks below. My main concern is that the > I-P body part may be any kind of multipart, not just multipart/mixed. >> For 7.6: >> "The Info Package specification MUST define what type of body part is >> associated with the Info Package, and MUST refer to specifications >> where the syntax, semantics and MIME type of that body part (and, if >> multipart/mixed, any child body parts) are described." >> >> For 4.3: >> "The purpose of the INFO request is to carry application level > information between SIP UAs. The application data associated with an > Info Package is carried as a body part in the message body of the INFO >> request. This body part is identified by a MIME type, which can be > multipart/mixed, in which case the body part has child body parts. In > accordance with section 7.6, the Info Package specification >> defines the type of body part. >> >> In above, replace "multipart/mixed" with simple "multipart". Any kind > of multipart could be applicable here. >> An INFO request message body can contain just the body part associated > with the Info Package, or this body part along with other body parts > (not related to the Info Package but relating to other SIP >> extensions) in a message body of type multipart/mixed. >> >> If a UA indicates that it is willing to receive a specific Info > Package, it means that the UA also supports the associated body part > MIME type associated with that Info Package. However, the UA MUST still > indicate support of that MIME type, and any child MIME types, in the > Accept header field, according to the procedures in [RFC3261]. >> UAs MUST conform to [RFC3261], as updated by body-handling > [I-D.ietf-sip-body-handling], to support multipart MIME handling. >> Body-handling is now RFC 5621. > > I'll fix the reference. > > ---------------- > >> The body part associated with the Info Package MUST contain a > Content-Disposition header field with value 'Info-Package', in order > easily to distinguish payloads associated with the Info Package from >> other payloads. If the message body only contains the single body part > associated with the Info-Package, the SIP level Content-Disposition > header field MUST contain value 'Info-Package'. If the message >> body is of type multipart/mixed, the child body part associated with > the Info-Package MUST include a Content-Disposition header field with > value 'Info-Package'. Child body parts of a multipart/mixed body >part > associated with the Info-Package do not require this Content-Disposition > value. >> Some slight rewording suggestions: >> >> ... >> " If the message body is of type multipart/mixed, >> * and the Content-Disposition is "render" or unspecified, >> the child body part associated with the Info-Package MUST include a >> Content-Disposition header field with value 'Info-Package'. Child > body >> * parts of a multipart body part associated with the Info-Package do > not >> * ^^^^^^^^^^ >> require this Content-Disposition value." > > I don't agree with that text. As I said earlier, RFC 5621 says that the > C-D value of the "parent body part" (C-T multipart) is IRRELEVANT to the > "child body parts" - they must explicitly be assigned individual C-T > values, or they will be assigned a default value. Of course the child body parts don't *inherit" the C-D value. But it doesn't matter. In this case it is the multipart itself that is the "payload" for the INFO message. Once it has been identified, and turned over to the application to process, *we don't care* what the C-D of the contained parts is. What C-D values are relevant within there must be documented as part of the specific info-pkg documentation. > To use OOP language: a child body part does NOT inherit the C-D value of > its parent :) > > So, therefor I don't think it really matters what the C-D value of the > parent body part is, because it does not affect the child body parts. *If* you have a top level multipart/mixed that isn't C-D info-pkg (and is in fact without a C-D or has one of "render") then that will contain incidental parts of varying relevance to the message. In that case, if more than one of those is of C-D info-pkg, and if we determine that is valid, then fine - those are each passed to the application. But if the whole body is of type C-D info-pkg, then it doesn't matter what C-T it is, or whether than is a multipart or not, it all goes to the application as the info package payload. Lets imagine for the moment that we are designing a new info package, and it happens to need two distinct clumps of data - e.g. a piece of simple text and an xml file. How should the info package spec specify that data be encapsulated within the message? There seem to be a few ways to do this: 1) there should be a multipart/mixed, with C-D of info-pkg, that consolidates all the data. Within that are two parts: - one with C-T text/plain - one with C-T text/xml (or whatever) Each may have C-D that is appropriate to its intended use by the application, or let it default to "render". (What render means to an info package is a good question.) 2) same as (1) except the outer wrapper is multipart/related, and as a result the C-D of the subordinate parts is likely less important. 3) the body of the message is of C-T multipart/mixed, and the C-D is "render" or unspecified. Within that are two or more parts. One of those has C-T text/plain and C-D info-pkg. Another of those has C-T text/xml (or whatever) and C-D of info-pkg. None of the other direct children parts of the top level multipart have C-D of info-pkg. I think that 1 and/or 2 are enough, and that there is no need to permit (3). I agree that (3) can work, but I just think that is unnecessarily confusing things. It does seem that there is a fundamental difference of opinion here that needs to be sorted out. Can some other people chime in here? Thanks, Paul > Regards, > > Christer > > > > > > In the above I added "and the Content-Disposition is "render" or > unspecified". I wish we had specified a specific C-D for the top level > multipart that contains unrelated body parts in a sip message. Somehow > that got missed in body-handling, though it would have been an issue for > backward compatibility. > > Thanks, > Paul > >> NOTE: To avoid corner cases with legacy INFO usage, the Info-Package > header field is used to indicate the Info Package name, rather than > using a Content-Disposition header field parameter in order to indicate > the name." >> How does this sound? >> >> John >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 20 October 2009 21:50 >>> To: Christer Holmberg >>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; >>> draft-ietf-sipcore-info-events@tools.ietf.org >>> Subject: Re: [sipcore] WGLC comments >>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P >>> body parts in INFO? >>> >>> >>> >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>>> It sounds like we may have different conceptions of how body parts >>>> might be strung together for this. >>>>> If I read your text below correctly, then it would be >>> possible for the >>>> INFO message to have a multipart mixed body, where some >>> body parts are >>>> not part of the info package (authentication stuff, geoloc >>>>> stuff), but where one *or more* other parts are considered >>> part of the >>>> info package. >>>> >>>> Section 4.3 talks about "SIP extensions that are orthogonal >>> to INFO MAY >>>> insert body parts unrelated to the Info Package". >>>> >>>> Personally, though, I doubt that someone would say "Hey, someone is >>>> about the send an INFO, so I'll throw in my message body part there >>>> too!". I think that any application who wants to send an >>> INFO (no matter >>>> whether it's legacy of I-P based, should trigger a >>> dedicated INFO, and >>>> not try to get a "free ride" by someone else... >>> The way I envision this might happen would be because of some >>> optional header inserted in the message that has a reference to a >>> body part, via a cid: url. I guess INFO can't have Alert-Info, but if > >>> it could then that would be one example. >>> >>> Another example might be an AIB body. >>> >>> Most are pretty far fetched for INFO, but we should not exclude the >>> possibility. >>> >>>>> It was my thinking that there will always be *one* body >>> part that is >>>> the root of all stuff that is associated with the info >>> package. In the >>>> simplest case this would be the whole body of the message, >>>>> containing for example DTMF info. In a slightly more >>> complicated case >>>> it might be that same DTMF body, but as one body part in a >>>> multipart/mixed, where the other body parts are for >>> incidental purposes >>>>> but not part of the info package. >>>> Personally I agree with you, but the text has been there for a while > >>>> already. If people want to remove it, though, I am happy to do it. >>> The way that C-D works means that technically you *could* have >>> multiple parts with C-D of info-pkg. The question is whether there is > >>> any value in making it legal. If so then somebody has to define what >>> it means. >>> Since we have multipart which already has lots of ways to group >>> parts, why do we need to introduce yet another grouping mechanism >>> here? >>> >>>>> In cases where the info package itself needs more than one >>> body part, >>>> it would consist of a multipart containing all of its >>> pieces. Then that >>>> multipart would be just as above - either the only thing in >>>>> the message, or else it would be a multipart within a >>> multipart, along >>>> with other incidental parts. >>>> >>>> Just to make sure: even if we say that all body parts must >>> be associated >>>> with the Info Package, do you agree that they ALL still >>> shall have a C-D >>>> with 'info-package'? Otherwise parsers may assign whatever >>> the default >>>> C-D value is for them, and we don't want that to happen... >>> NO, I don't agree. >>> >>> These are nested structures. They may come from some other place and >>> be formed and processed by non-sip code that knows nothing of >>> info-pkg. >>> Once you unwrap the first box, I think you should be allowed to have >>> whatever you want inside. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>> Your explanation sounds reasonable. I think it requires some >>>>> clarification in both 7.6 and 4.3: >>>>>> - in 7.6 it should talk about a body part, which may be multipart; >>>>> 7.6 shall definitely be changed. It should say "body parts". >>>>> >>>>> "7.6. INFO Message Body >>>>> >>>>> The Info Package specification MUST define what type of >>> message body >>>>> parts, are associated with the Info Package, and MUST refer to >>>>> specifications where the syntax, semantics and MIME type of each >>>>> message body part is described." >>>>> >>>>> - The old text used to say "message bodies, if any", but I >>> removed "if >>>>> any" due to the change that the Info Package shall not assume on >>>>> information being conveyed in SIP headers (see other e-mail). >>>>> >>>>> ------------- >>>>> >>>>>> - in 4.3 it should talk about labelling the Info-Package >>> body part >>>>>> with >>>>> Content-Disposition: Info-Package, this being at the SIP >>> level if it >>>>> is the sole body part (i.e., the entire body of the SIP >>>>>> message). >>>>> Yes. Basically the text shall say that each message body part >>>>> associated with the Info Package shall have a associated >>> C-D header >>>>> filed with an 'info-package' value. And, if there is only a single >>>>> body part in a message the SIP level C-D header field contains the >>>> 'info-package' >>>>> value. >>>>> >>>>> Also, 4.3 talks about "message body payloads", but I will >>> change to >>>>> "message body parts" there, to be consistent with 7.6. >>>>> >>>>> NOTE: The new 4.3 text below may also contain changes I've already >>>>> done based on other comments: >>>>> >>>>> "4.3. INFO Request Message Body >>>>> >>>>> The purpose of the INFO request is to carry application level >>>>> information between SIP UAs. The application data >>> associated with >>>> an >>>>> Info Package is carried as a payload in the message body of >>>>> the INFO request. >>>>> >>>>> An INFO request message body can contain a single body part, or >>>>> multiple >>>>> body parts (multipart/mixed). >>>>> >>>>> Info Package specifications MUST describe the application level >>>>> information associated with the Info Package. Message body parts >>>>> MUST have a MIME type value defined. >>>>> >>>>> If a UA indicates that it is willing to receive a specific Info >>>>> Package, it means that the UA also supports any >>> associated message >>>>> body MIME type associated with the Info Package. >>> However, the UA >>>>> MUST still indicate support of those MIME types also in >>> the Accept >>>>> header field, according to the procedures in [RFC3261]. >>>>> >>>>> Some SIP extensions that are orthogonal to INFO MAY insert body >>>> parts >>>>> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >>>>> updated by body-handling [I-D.ietf-sip-body-handling] to support >>>>> multipart MIME handling. >>>>> >>>>> Each message body part associated with an Info Package MUST >>>>> contain a Content-Disposition header field with an >>> 'Info-Package' >>>>> value, in order to in an easy way distinguish payloads >>> associated >>>>> with the Info Package from other payloads. >>>>> >>>>> If the message body only contains a single body part, >>> the SIP level >>>>> Content-Disposition header field >>>>> contains an 'info-package' value. >>>>> >>>>> If the message body contains multiple body parts >>> (multipart/mixed) >>>>> the SIP level Content-Disposition header field >>>>> does not need to include an 'info-package' value, since >>> each body >>>>> part associated with the Info Package will include >>>>> a Content-Disposition header field for that specific body part. >>>>> >>>>> NOTE: To avoid corner cases with legacy INFO usage, the >>>> Info-Package >>>>> header field is used to indicate the Info Package name, >>> rather than >>>>> to use a Content-Disposition header field parameter in order to >>>>> indicate the name." >>>>> >>>>> ------------- >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> > From john.elwell@siemens-enterprise.com Wed Oct 21 12:47:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B52793A6A19 for ; Wed, 21 Oct 2009 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.409 X-Spam-Level: X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nra-yfwlk7Cq for ; Wed, 21 Oct 2009 12:47:26 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 164083A69E7 for ; Wed, 21 Oct 2009 12:47:25 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJlWJ1012387; Wed, 21 Oct 2009 21:47:32 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJlWfQ024511; Wed, 21 Oct 2009 21:47:32 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Wed, 21 Oct 2009 21:47:31 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Wed, 21 Oct 2009 21:47:27 +0200 Thread-Topic: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSTQFTLWL/4JP/SFaGU9RvxSenuQAMlbqQAAGKYvA= Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E13@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:47:27 -0000 Christer, This seems a lot better. A few specific comments embedded. I would keep 1.2= and 1.3 here, unless there is an obvious alternative place for one or both= of them. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 21 October 2009 20:27 > To: Elwell, John; SIPCORE > Subject: WGLC (draft-ietf-sipcore-info-events) - Style of=20 > section 1 in info-events >=20 >=20 > Hi,=20 >=20 > >Section 1 says what RFC 2976 does, says what its drawbacks are, and > then says that this document describes a mechanism that=20 > addresses those > drawbacks. It does not state that this document defines the=20 > >INFO method. It even refers back to RFC 2976 for the=20 > definition of the > INFO method ("The purpose of the INFO message [RFC2976] is.... "). > > > >Yet this document supposedly obsoletes RFC 2976. > > > >I would have expected the introduction to a document that=20 > obsoletes an > earlier RFC to be self-standing and structured more like the=20 > following: > >- Introductory text very similar to what is in the obsoleted RFC, but > modified to mention anything that is significantly different. > >- A reference back to the obsoleted RFC, describing what has changed. > > > >In this particular case, the text of RFC 2976 is a rough starting > point. It even says, near the end, that the document does not specify > specific uses, so that is an ideal point to continue and talk about=20 > >usages, Info-Packages, and indicating supported usages. > > > >We could then continue by saying that the document obsoletes=20 > RFC 2976, > which did not define the Info-Package concept and explicit indications > of which usages are supported. >=20 > I agree that we may refer/depend a little too much on RFC 2976 - and I > think Robert commented on the same issue. It is probably some=20 > text which > was useful during the justficiation phase, but should be changes. >=20 > Basically we should only refer to 2976 when we talk about legacy INFO > usage, and when we talk about the drawbacks of legacy INFO usage. >=20 > Below is a re-write of the introduction, which I think addresses your > issue.=20 >=20 > (We could of course discuss whether 1.2 and 1.3 really should=20 > be in the > introduction, or be moved to other places in the spec.) >=20 > "1. Introduction >=20 > 1.1 General >=20 > This document defines a new method, INFO, for the Session=20 > Initiation > Protocol (SIP) [RFC2976].=20 > In addition, it defines an Info Package mechanism. An Info Package > defines the content and semantics of the=20 > information carried in an INFO message associated with the Info > Package. > The Info Package mechanism also provides a way for UAs to indicate > for=20 > which types of applications and contexts they are willing=20 > to receive > INFO requests. The > document defines how the INFO method is used, new SIP header fields > for the > INFO method, and how to transport payload information=20 > associated with > an Info Package > using INFO requests.=20 > =20 > The purpose of the INFO message is to carry application > level information between endpoints, using the SIP session=20 > signaling > path. Note that the INFO method is not used to update > characteristics of the SIP session, but to allow the applications > which use the SIP session to exchange information. [JRE] I think this ought to come earlier, after the very first sentence, be= fore we start talking about Info Packages. >=20 > The Info Package mechanism does not define a separate dialog usage. [JRE] I would prefer "Use of the INFO method does not constitute a separate= dialog usage". > INFO messages are always part of, and share the fate of, an invite > dialog usage. INFO messages cannot be sent as part of other dialog > usages. >=20 > If a UA supports the Info Package mechanism, it uses the Recv-Info [JRE] Any UA supporting this RFC must support the Info Package mechanism, s= o we can shorten this to "A UA uses the Recv-Info..." > header field, on a per-dialog basis, to indicate for which Info > Packages > it is willing to receive INFO requests. A UA can indicate=20 > a new set > of Info > Packages at any time during the lifetime of the invite=20 > dialog usage. [JRE] Perhaps being rather pedantic, but shouldn't we say "A UA can indicat= e an initial set of Info Packages during dialog establishment and can indic= ate a new set..."? > A UA can use a "nil" value to indicate that it is not willing to > receive any Info Packages at a certain moment, but that=20 > the UA still > supports the Info Package mechanism. >=20 > When a UA sends an INFO request, it uses the Info-Package header > field to indicate which Info Package is associated with=20 > the request. > One particular INFO > request can only be associated with a single Info Package. >=20 > This document obosoletes [RFC2976]. However, for backward=20 > compability > it allows > to use INFO per [RFC2976], referred to as legacy INFO usage in the > document. >=20 > 1.2 Problems with leagcy INFO usage >=20 > While legacy INFO usage [RFC2976] has been widely adopted for > specific > application use cases, such as ISUP and DTMF exchange,=20 > [RFC2976] does > not > not define a mechanisms for SIP UAs to indicate for which types of > applications and contexts they > support the INFO method.what usages of INFO. In addition, [RFC2976] [JRE] Change "mechanisms" to "mechanism". Also I think the words "what usag= es of INFO" should have been deleted. John > does not provide a mechanism to > explicitly indicate the type of application and context for which a > specific INFO message is associated to. > In some cases it can be determined by the INFO message body payload > content, but not in a general way. >=20 > Example: If the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. Still, there are many useful=20 > ways a UA can > render an image. The image could be a caller-id picture, a contact > icon, a photo for sharing, and so on. The sender does not=20 > know which > image to send to the receiver if the receiver supports an image > content type. Likewise, the receiver does not know the=20 > context of an > image the client is sending if the receiver supports receiving more > than one image content type. >=20 > Due to the problems described above, legacy INFO usages=20 > often require > static configuration about for what type of applications=20 > and contexts > UAs support the INFO method,=20 > and the way they handle application information transported in INFO > messages. > That has caused interoperability problems in the industry. > Therefore,a need for a well defined and > documented description of what the information sent in the INFO is > used for has been identified. This situation is analogous to the > context issue in > Internet Mail [RFC3458]. >=20 > 1.3 Relationship to subscription-based event >=20 > Event Packages [RFC3265] perform the role of disambiguating the > context of a message for subscription-based events. The=20 > Info Package > mechanism provides similar functionality for application=20 > information > exchange using invite dialog usages [RFC5057]. However, there is no > formal > relationship between the Info Package mechanism and the > subscription-based event > mechanism." >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > = From john.elwell@siemens-enterprise.com Wed Oct 21 12:56:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2833A67EC for ; Wed, 21 Oct 2009 12:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.992 X-Spam-Level: X-Spam-Status: No, score=-5.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnhrG4OD4lZM for ; Wed, 21 Oct 2009 12:56:13 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 434F33A687D for ; Wed, 21 Oct 2009 12:55:02 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJsflV012374; Wed, 21 Oct 2009 21:54:42 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9LJsfb9031549; Wed, 21 Oct 2009 21:54:41 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 21 Oct 2009 21:54:40 +0200 From: "Elwell, John" To: Paul Kyzivat , Christer Holmberg Date: Wed, 21 Oct 2009 21:54:35 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpShn0rOZbevWSGRQquNJLiglHR5wAAYHiA Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E16@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> In-Reply-To: <4ADF63CD.5050707@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo, Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:56:15 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 21 October 2009 20:41 > To: Christer Holmberg > Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments > (draft-ietf-sipcore-info-events-01) - John E's comments - > non-I-P body parts in INFO? > > Inline, down aways. > > Christer Holmberg wrote: > > Hi, > > > >>> Christer, > >>> > >>> I tend to agree with Paul, and this is the text I would propose: > >> Good text, with a couple of tweaks below. My main concern > is that the > > I-P body part may be any kind of multipart, not just > multipart/mixed. > >> For 7.6: > >> "The Info Package specification MUST define what type of > body part is > >> associated with the Info Package, and MUST refer to specifications > >> where the syntax, semantics and MIME type of that body > part (and, if > >> multipart/mixed, any child body parts) are described." > >> > >> For 4.3: > >> "The purpose of the INFO request is to carry application level > > information between SIP UAs. The application data associated with an > > Info Package is carried as a body part in the message body > of the INFO > >> request. This body part is identified by a MIME type, which can be > > multipart/mixed, in which case the body part has child body > parts. In > > accordance with section 7.6, the Info Package specification > >> defines the type of body part. > >> > >> In above, replace "multipart/mixed" with simple > "multipart". Any kind > > of multipart could be applicable here. > >> An INFO request message body can contain just the body > part associated > > with the Info Package, or this body part along with other body parts > > (not related to the Info Package but relating to other SIP > >> extensions) in a message body of type multipart/mixed. > >> > >> If a UA indicates that it is willing to receive a specific Info > > Package, it means that the UA also supports the associated body part > > MIME type associated with that Info Package. However, the > UA MUST still > > indicate support of that MIME type, and any child MIME types, in the > > Accept header field, according to the procedures in [RFC3261]. > >> UAs MUST conform to [RFC3261], as updated by body-handling > > [I-D.ietf-sip-body-handling], to support multipart MIME handling. > >> Body-handling is now RFC 5621. > > > > I'll fix the reference. > > > > ---------------- > > > >> The body part associated with the Info Package MUST contain a > > Content-Disposition header field with value 'Info-Package', in order > > easily to distinguish payloads associated with the Info > Package from > >> other payloads. If the message body only contains the > single body part > > associated with the Info-Package, the SIP level Content-Disposition > > header field MUST contain value 'Info-Package'. If the message > >> body is of type multipart/mixed, the child body part > associated with > > the Info-Package MUST include a Content-Disposition header > field with > > value 'Info-Package'. Child body parts of a multipart/mixed > body >part > > associated with the Info-Package do not require this > Content-Disposition > > value. > >> Some slight rewording suggestions: > >> > >> ... > >> " If the message body is of type multipart/mixed, > >> * and the Content-Disposition is "render" or unspecified, > >> the child body part associated with the Info-Package > MUST include a > >> Content-Disposition header field with value 'Info-Package'. Child > > body > >> * parts of a multipart body part associated with the > Info-Package do > > not > >> * ^^^^^^^^^^ > >> require this Content-Disposition value." > > > > I don't agree with that text. As I said earlier, RFC 5621 > says that the > > C-D value of the "parent body part" (C-T multipart) is > IRRELEVANT to the > > "child body parts" - they must explicitly be assigned individual C-T > > values, or they will be assigned a default value. > > Of course the child body parts don't *inherit" the C-D value. > But it doesn't matter. In this case it is the multipart > itself that is > the "payload" for the INFO message. Once it has been identified, and > turned over to the application to process, *we don't care* > what the C-D > of the contained parts is. > > What C-D values are relevant within there must be documented > as part of > the specific info-pkg documentation. > > > To use OOP language: a child body part does NOT inherit the > C-D value of > > its parent :) > > > > So, therefor I don't think it really matters what the C-D > value of the > > parent body part is, because it does not affect the child > body parts. > > *If* you have a top level multipart/mixed that isn't C-D > info-pkg (and > is in fact without a C-D or has one of "render") then that > will contain > incidental parts of varying relevance to the message. In that > case, if > more than one of those is of C-D info-pkg, and if we > determine that is > valid, then fine - those are each passed to the application. > > But if the whole body is of type C-D info-pkg, then it doesn't matter > what C-T it is, or whether than is a multipart or not, it all goes to > the application as the info package payload. > > Lets imagine for the moment that we are designing a new info package, > and it happens to need two distinct clumps of data - e.g. a piece of > simple text and an xml file. How should the info package spec specify > that data be encapsulated within the message? There seem to be a few > ways to do this: > > 1) there should be a multipart/mixed, with C-D of info-pkg, > that consolidates all the data. > Within that are two parts: > - one with C-T text/plain > - one with C-T text/xml (or whatever) > Each may have C-D that is appropriate to its intended use > by the application, or let it default to "render". > (What render means to an info package is a good question.) > > 2) same as (1) except the outer wrapper is multipart/related, > and as a result the C-D of the subordinate parts is likely > less important. > > 3) the body of the message is of C-T multipart/mixed, and the > C-D is "render" or unspecified. > Within that are two or more parts. > One of those has C-T text/plain and C-D info-pkg. > Another of those has C-T text/xml (or whatever) and > C-D of info-pkg. > None of the other direct children parts of the top level > multipart have C-D of info-pkg. > > I think that 1 and/or 2 are enough, and that there is no need > to permit > (3). I agree that (3) can work, but I just think that is > unnecessarily > confusing things. [JRE] I agree that (3) is an unnecessary complication. It is hard to imagin= e a situation that can't be accomplished by (1) or (2) (or a single part bo= dy, of course). In the interests of interoperability, limit the options whe= re reasonable. John > > It does seem that there is a fundamental difference of > opinion here that > needs to be sorted out. Can some other people chime in here? > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > > > > > > > In the above I added "and the Content-Disposition is "render" or > > unspecified". I wish we had specified a specific C-D for > the top level > > multipart that contains unrelated body parts in a sip > message. Somehow > > that got missed in body-handling, though it would have been > an issue for > > backward compatibility. > > > > Thanks, > > Paul > > > >> NOTE: To avoid corner cases with legacy INFO usage, the > Info-Package > > header field is used to indicate the Info Package name, rather than > > using a Content-Disposition header field parameter in order > to indicate > > the name." > >> How does this sound? > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 20 October 2009 21:50 > >>> To: Christer Holmberg > >>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; > >>> draft-ietf-sipcore-info-events@tools.ietf.org > >>> Subject: Re: [sipcore] WGLC comments > >>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P > >>> body parts in INFO? > >>> > >>> > >>> > >>> Christer Holmberg wrote: > >>>> Hi, > >>>> > >>>>> It sounds like we may have different conceptions of how > body parts > >>>> might be strung together for this. > >>>>> If I read your text below correctly, then it would be > >>> possible for the > >>>> INFO message to have a multipart mixed body, where some > >>> body parts are > >>>> not part of the info package (authentication stuff, geoloc > >>>>> stuff), but where one *or more* other parts are considered > >>> part of the > >>>> info package. > >>>> > >>>> Section 4.3 talks about "SIP extensions that are orthogonal > >>> to INFO MAY > >>>> insert body parts unrelated to the Info Package". > >>>> > >>>> Personally, though, I doubt that someone would say "Hey, > someone is > >>>> about the send an INFO, so I'll throw in my message body > part there > >>>> too!". I think that any application who wants to send an > >>> INFO (no matter > >>>> whether it's legacy of I-P based, should trigger a > >>> dedicated INFO, and > >>>> not try to get a "free ride" by someone else... > >>> The way I envision this might happen would be because of some > >>> optional header inserted in the message that has a reference to a > >>> body part, via a cid: url. I guess INFO can't have > Alert-Info, but if > > > >>> it could then that would be one example. > >>> > >>> Another example might be an AIB body. > >>> > >>> Most are pretty far fetched for INFO, but we should not > exclude the > >>> possibility. > >>> > >>>>> It was my thinking that there will always be *one* body > >>> part that is > >>>> the root of all stuff that is associated with the info > >>> package. In the > >>>> simplest case this would be the whole body of the message, > >>>>> containing for example DTMF info. In a slightly more > >>> complicated case > >>>> it might be that same DTMF body, but as one body part in a > >>>> multipart/mixed, where the other body parts are for > >>> incidental purposes > >>>>> but not part of the info package. > >>>> Personally I agree with you, but the text has been there > for a while > > > >>>> already. If people want to remove it, though, I am happy > to do it. > >>> The way that C-D works means that technically you *could* have > >>> multiple parts with C-D of info-pkg. The question is > whether there is > > > >>> any value in making it legal. If so then somebody has to > define what > >>> it means. > >>> Since we have multipart which already has lots of ways to group > >>> parts, why do we need to introduce yet another grouping mechanism > >>> here? > >>> > >>>>> In cases where the info package itself needs more than one > >>> body part, > >>>> it would consist of a multipart containing all of its > >>> pieces. Then that > >>>> multipart would be just as above - either the only thing in > >>>>> the message, or else it would be a multipart within a > >>> multipart, along > >>>> with other incidental parts. > >>>> > >>>> Just to make sure: even if we say that all body parts must > >>> be associated > >>>> with the Info Package, do you agree that they ALL still > >>> shall have a C-D > >>>> with 'info-package'? Otherwise parsers may assign whatever > >>> the default > >>>> C-D value is for them, and we don't want that to happen... > >>> NO, I don't agree. > >>> > >>> These are nested structures. They may come from some > other place and > >>> be formed and processed by non-sip code that knows nothing of > >>> info-pkg. > >>> Once you unwrap the first box, I think you should be > allowed to have > >>> whatever you want inside. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Christer Holmberg wrote: > >>>>> Hi, > >>>>> > >>>>>> Your explanation sounds reasonable. I think it requires some > >>>>> clarification in both 7.6 and 4.3: > >>>>>> - in 7.6 it should talk about a body part, which may > be multipart; > >>>>> 7.6 shall definitely be changed. It should say "body parts". > >>>>> > >>>>> "7.6. INFO Message Body > >>>>> > >>>>> The Info Package specification MUST define what type of > >>> message body > >>>>> parts, are associated with the Info Package, and MUST refer to > >>>>> specifications where the syntax, semantics and MIME > type of each > >>>>> message body part is described." > >>>>> > >>>>> - The old text used to say "message bodies, if any", but I > >>> removed "if > >>>>> any" due to the change that the Info Package shall not > assume on > >>>>> information being conveyed in SIP headers (see other e-mail). > >>>>> > >>>>> ------------- > >>>>> > >>>>>> - in 4.3 it should talk about labelling the Info-Package > >>> body part > >>>>>> with > >>>>> Content-Disposition: Info-Package, this being at the SIP > >>> level if it > >>>>> is the sole body part (i.e., the entire body of the SIP > >>>>>> message). > >>>>> Yes. Basically the text shall say that each message body part > >>>>> associated with the Info Package shall have a associated > >>> C-D header > >>>>> filed with an 'info-package' value. And, if there is > only a single > >>>>> body part in a message the SIP level C-D header field > contains the > >>>> 'info-package' > >>>>> value. > >>>>> > >>>>> Also, 4.3 talks about "message body payloads", but I will > >>> change to > >>>>> "message body parts" there, to be consistent with 7.6. > >>>>> > >>>>> NOTE: The new 4.3 text below may also contain changes > I've already > >>>>> done based on other comments: > >>>>> > >>>>> "4.3. INFO Request Message Body > >>>>> > >>>>> The purpose of the INFO request is to carry application level > >>>>> information between SIP UAs. The application data > >>> associated with > >>>> an > >>>>> Info Package is carried as a payload in the message body of > >>>>> the INFO request. > >>>>> > >>>>> An INFO request message body can contain a single > body part, or > >>>>> multiple > >>>>> body parts (multipart/mixed). > >>>>> > >>>>> Info Package specifications MUST describe the > application level > >>>>> information associated with the Info Package. > Message body parts > >>>>> MUST have a MIME type value defined. > >>>>> > >>>>> If a UA indicates that it is willing to receive a > specific Info > >>>>> Package, it means that the UA also supports any > >>> associated message > >>>>> body MIME type associated with the Info Package. > >>> However, the UA > >>>>> MUST still indicate support of those MIME types also in > >>> the Accept > >>>>> header field, according to the procedures in [RFC3261]. > >>>>> > >>>>> Some SIP extensions that are orthogonal to INFO MAY > insert body > >>>> parts > >>>>> unrelated to the Info Package. UAs MUST conform to > [RFC3261] as > >>>>> updated by body-handling > [I-D.ietf-sip-body-handling] to support > >>>>> multipart MIME handling. > >>>>> > >>>>> Each message body part associated with an Info Package MUST > >>>>> contain a Content-Disposition header field with an > >>> 'Info-Package' > >>>>> value, in order to in an easy way distinguish payloads > >>> associated > >>>>> with the Info Package from other payloads. > >>>>> > >>>>> If the message body only contains a single body part, > >>> the SIP level > >>>>> Content-Disposition header field > >>>>> contains an 'info-package' value. > >>>>> > >>>>> If the message body contains multiple body parts > >>> (multipart/mixed) > >>>>> the SIP level Content-Disposition header field > >>>>> does not need to include an 'info-package' value, since > >>> each body > >>>>> part associated with the Info Package will include > >>>>> a Content-Disposition header field for that specific > body part. > >>>>> > >>>>> NOTE: To avoid corner cases with legacy INFO usage, the > >>>> Info-Package > >>>>> header field is used to indicate the Info Package name, > >>> rather than > >>>>> to use a Content-Disposition header field parameter > in order to > >>>>> indicate the name." > >>>>> > >>>>> ------------- > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> > > > From christer.holmberg@ericsson.com Wed Oct 21 13:14:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388F23A68D0 for ; Wed, 21 Oct 2009 13:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oufDIMLbA5E for ; Wed, 21 Oct 2009 13:14:20 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 710B73A687D for ; Wed, 21 Oct 2009 13:14:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-37-4adf6ba2cf2f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 03.C5.24026.2AB6FDA4; Wed, 21 Oct 2009 22:14:26 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 22:14:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 22:14:25 +0200 Message-ID: In-Reply-To: <4ADF63CD.5050707@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpShn8eeBQAIf+xTEepEvk40ZqfKAAANYBw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 20:14:26.0154 (UTC) FILETIME=[164CBCA0:01CA528B] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:14:22 -0000 Hi,=20 >>>The body part associated with the Info Package MUST contain a >>>Content-Disposition header field with value 'Info-Package', in order=20 >>>easily to distinguish payloads associated with the Info Package from >>>other payloads. If the message body only contains the single body=20 >>>part associated with the Info-Package, the SIP level Content-Disposition=20 >>>header field MUST contain value 'Info-Package'. If the message >>>body is of type multipart/mixed, the child body part associated with >>>the Info-Package MUST include a Content-Disposition header field with >>>value 'Info-Package'. Child body parts of a multipart/mixed body >part=20 >>>associated with the Info-Package do not require this Content-Disposition value. >>>Some slight rewording suggestions: >>> >>> ... >>> " If the message body is of type multipart/mixed, >>> * and the Content-Disposition is "render" or unspecified, >>> the child body part associated with the Info-Package MUST include a >>> Content-Disposition header field with value 'Info-Package'. Child body >>> * parts of a multipart body part associated with the Info-Package do >>> not >>> * ^^^^^^^^^^ >>> require this Content-Disposition value." >>=20 >>I don't agree with that text. As I said earlier, RFC 5621 says that=20 >>the C-D value of the "parent body part" (C-T multipart) is IRRELEVANT=20 >>to the "child body parts" - they must explicitly be assigned=20 >>individual C-T values, or they will be assigned a default value. > >Of course the child body parts don't *inherit" the C-D value. >But it doesn't matter. In this case it is the multipart itself that is the "payload" for the INFO message. Once it has been identified, and turned over to the application to process, *we don't care* what=20 >the C-D of the contained parts is. I don't agree. Eventhough I do hear what you are saying, in my opinion "We don't care" goes against what we tried to fix with RFC 5621, and could potentially cause problems. An Info-Package body part shall have C-D 'info-package', and I don't like that fact that we should allow "any value" to be assigned to a body part just because it is transported within a multipart. There is really no harm, and very little message overhead, in adding C-D 'info-package' for each body part. I think it is a "hack" by not doing it - even if it would work well. >What C-D values are relevant within there must be documented as part of the specific info-pkg documentation. Body parts associated with Info Packages must have C-D 'info-package' - nothing else. ----------- >>To use OOP language: a child body part does NOT inherit the C-D value of its parent :) >>=20 >>So, therefor I don't think it really matters what the C-D value of the >>parent body part is, because it does not affect the child body parts. > >*If* you have a top level multipart/mixed that isn't C-D info-pkg (and is in fact without a C-D or has one of "render") then that will contain incidental parts of varying relevance to the message. In=20 >that case, if more than one of those is of C-D info-pkg, and if we determine that is valid, then fine - those are each passed to the application. Agree. ----------- >But if the whole body is of type C-D info-pkg, then it doesn't matter what C-T it is, or whether than is a multipart or not, it all goes to the application as the info package payload. That may be true, but I still think it is wrong to send the wrong C-D values to the application - no matter if it cares about them or not. It is not specified in RFC 5621, and I have never heard about another usage which act like that. ----------- >Lets imagine for the moment that we are designing a new info package, and it happens to need two distinct clumps of data - e.g. a piece of simple text and an xml file. How should the info package spec=20 >specify that data be encapsulated within the message? There seem to be a few ways to do this: > >1) there should be a multipart/mixed, with C-D of info-pkg, > that consolidates all the data. > Within that are two parts: > - one with C-T text/plain > - one with C-T text/xml (or whatever) > Each may have C-D that is appropriate to its intended use > by the application, or let it default to "render". > (What render means to an info package is a good question.) If they are associated with the Info-Package, each body part should have C-D 'info-pkg'. The I-P specification then says whether the application use them for some rendering, or whatever. As far as the SIP protocol is concerned, the body parts simply contain something beloning to the I-P. ----------- >2) same as (1) except the outer wrapper is multipart/related, > and as a result the C-D of the subordinate parts is likely > less important. > >3) the body of the message is of C-T multipart/mixed, and the > C-D is "render" or unspecified. > Within that are two or more parts. > One of those has C-T text/plain and C-D info-pkg. > Another of those has C-T text/xml (or whatever) and > C-D of info-pkg. > None of the other direct children parts of the top level > multipart have C-D of info-pkg. > >I think that 1 and/or 2 are enough, and that there is no need to permit (3). I agree that (3) can work, but I just think that is unnecessarily confusing things. I think the less confusing thing is to assign each body part a proper C-D value :) (I am not even sure what C-D for a multipart really means, since the children will override it anyway (either explicitly or implicitly) but I guess I will have to look it up.) Regards, Christer >It does seem that there is a fundamental difference of opinion here that needs to be sorted out. Can some other people chime in here? >=20 >=20 >=20 >=20 > In the above I added "and the Content-Disposition is "render" or=20 > unspecified". I wish we had specified a specific C-D for the top level > multipart that contains unrelated body parts in a sip message. Somehow > that got missed in body-handling, though it would have been an issue=20 > for backward compatibility. >=20 > Thanks, > Paul >=20 >> NOTE: To avoid corner cases with legacy INFO usage, the Info-Package > header field is used to indicate the Info Package name, rather than=20 > using a Content-Disposition header field parameter in order to=20 > indicate the name." >> How does this sound? >> >> John >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: 20 October 2009 21:50 >>> To: Christer Holmberg >>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 >>> draft-ietf-sipcore-info-events@tools.ietf.org >>> Subject: Re: [sipcore] WGLC comments >>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P=20 >>> body parts in INFO? >>> >>> >>> >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>>> It sounds like we may have different conceptions of how body parts >>>> might be strung together for this. >>>>> If I read your text below correctly, then it would be >>> possible for the >>>> INFO message to have a multipart mixed body, where some >>> body parts are >>>> not part of the info package (authentication stuff, geoloc >>>>> stuff), but where one *or more* other parts are considered >>> part of the >>>> info package. >>>> >>>> Section 4.3 talks about "SIP extensions that are orthogonal >>> to INFO MAY >>>> insert body parts unrelated to the Info Package".=20 >>>> >>>> Personally, though, I doubt that someone would say "Hey, someone is >>>> about the send an INFO, so I'll throw in my message body part there >>>> too!". I think that any application who wants to send an >>> INFO (no matter >>>> whether it's legacy of I-P based, should trigger a >>> dedicated INFO, and >>>> not try to get a "free ride" by someone else... >>> The way I envision this might happen would be because of some=20 >>> optional header inserted in the message that has a reference to a=20 >>> body part, via a cid: url. I guess INFO can't have Alert-Info, but=20 >>> if >=20 >>> it could then that would be one example. >>> >>> Another example might be an AIB body. >>> >>> Most are pretty far fetched for INFO, but we should not exclude the=20 >>> possibility. >>> >>>>> It was my thinking that there will always be *one* body >>> part that is >>>> the root of all stuff that is associated with the info >>> package. In the >>>> simplest case this would be the whole body of the message, >>>>> containing for example DTMF info. In a slightly more >>> complicated case >>>> it might be that same DTMF body, but as one body part in a=20 >>>> multipart/mixed, where the other body parts are for >>> incidental purposes >>>>> but not part of the info package. >>>> Personally I agree with you, but the text has been there for a=20 >>>> while >=20 >>>> already. If people want to remove it, though, I am happy to do it. >>> The way that C-D works means that technically you *could* have=20 >>> multiple parts with C-D of info-pkg. The question is whether there=20 >>> is >=20 >>> any value in making it legal. If so then somebody has to define what >>> it means. >>> Since we have multipart which already has lots of ways to group=20 >>> parts, why do we need to introduce yet another grouping mechanism=20 >>> here? >>> >>>>> In cases where the info package itself needs more than one >>> body part, >>>> it would consist of a multipart containing all of its >>> pieces. Then that >>>> multipart would be just as above - either the only thing in >>>>> the message, or else it would be a multipart within a >>> multipart, along >>>> with other incidental parts. >>>> >>>> Just to make sure: even if we say that all body parts must >>> be associated >>>> with the Info Package, do you agree that they ALL still >>> shall have a C-D >>>> with 'info-package'? Otherwise parsers may assign whatever >>> the default >>>> C-D value is for them, and we don't want that to happen... >>> NO, I don't agree. >>> >>> These are nested structures. They may come from some other place and >>> be formed and processed by non-sip code that knows nothing of=20 >>> info-pkg. >>> Once you unwrap the first box, I think you should be allowed to have >>> whatever you want inside. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>> Your explanation sounds reasonable. I think it requires some >>>>> clarification in both 7.6 and 4.3: >>>>>> - in 7.6 it should talk about a body part, which may be=20 >>>>>> multipart; >>>>> 7.6 shall definitely be changed. It should say "body parts". >>>>> >>>>> "7.6. INFO Message Body >>>>> >>>>> The Info Package specification MUST define what type of >>> message body >>>>> parts, are associated with the Info Package, and MUST refer to=20 >>>>> specifications where the syntax, semantics and MIME type of each=20 >>>>> message body part is described." >>>>> >>>>> - The old text used to say "message bodies, if any", but I >>> removed "if >>>>> any" due to the change that the Info Package shall not assume on=20 >>>>> information being conveyed in SIP headers (see other e-mail). >>>>> >>>>> ------------- >>>>> >>>>>> - in 4.3 it should talk about labelling the Info-Package >>> body part >>>>>> with >>>>> Content-Disposition: Info-Package, this being at the SIP >>> level if it >>>>> is the sole body part (i.e., the entire body of the SIP >>>>>> message). >>>>> Yes. Basically the text shall say that each message body part=20 >>>>> associated with the Info Package shall have a associated >>> C-D header >>>>> filed with an 'info-package' value. And, if there is only a single >>>>> body part in a message the SIP level C-D header field contains the >>>> 'info-package' >>>>> value. >>>>> >>>>> Also, 4.3 talks about "message body payloads", but I will >>> change to >>>>> "message body parts" there, to be consistent with 7.6. >>>>> >>>>> NOTE: The new 4.3 text below may also contain changes I've already >>>>> done based on other comments: >>>>> >>>>> "4.3. INFO Request Message Body >>>>> >>>>> The purpose of the INFO request is to carry application level >>>>> information between SIP UAs. The application data >>> associated with >>>> an >>>>> Info Package is carried as a payload in the message body of >>>>> the INFO request.=20 >>>>> >>>>> An INFO request message body can contain a single body part, or >>>>> multiple >>>>> body parts (multipart/mixed). >>>>> >>>>> Info Package specifications MUST describe the application level >>>>> information associated with the Info Package. Message body parts >>>>> MUST have a MIME type value defined. >>>>> >>>>> If a UA indicates that it is willing to receive a specific Info >>>>> Package, it means that the UA also supports any >>> associated message >>>>> body MIME type associated with the Info Package. =20 >>> However, the UA >>>>> MUST still indicate support of those MIME types also in >>> the Accept >>>>> header field, according to the procedures in [RFC3261]. >>>>> >>>>> Some SIP extensions that are orthogonal to INFO MAY insert body >>>> parts >>>>> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >>>>> updated by body-handling [I-D.ietf-sip-body-handling] to support >>>>> multipart MIME handling. >>>>> >>>>> Each message body part associated with an Info Package MUST >>>>> contain a Content-Disposition header field with an >>> 'Info-Package' >>>>> value, in order to in an easy way distinguish payloads >>> associated >>>>> with the Info Package from other payloads.=20 >>>>> >>>>> If the message body only contains a single body part, >>> the SIP level >>>>> Content-Disposition header field >>>>> contains an 'info-package' value. >>>>> >>>>> If the message body contains multiple body parts >>> (multipart/mixed) >>>>> the SIP level Content-Disposition header field >>>>> does not need to include an 'info-package' value, since >>> each body >>>>> part associated with the Info Package will include >>>>> a Content-Disposition header field for that specific body part. >>>>> >>>>> NOTE: To avoid corner cases with legacy INFO usage, the >>>> Info-Package >>>>> header field is used to indicate the Info Package name, >>> rather than >>>>> to use a Content-Disposition header field parameter in order to >>>>> indicate the name." >>>>> >>>>> ------------- >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >=20 From christer.holmberg@ericsson.com Wed Oct 21 13:23:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82CA3A67EC for ; Wed, 21 Oct 2009 13:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.619 X-Spam-Level: X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfpi0W1W5-BQ for ; Wed, 21 Oct 2009 13:23:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A84AB28C113 for ; Wed, 21 Oct 2009 13:23:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ab-4adf6daeb49f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6E.6C.04191.EAD6FDA4; Wed, 21 Oct 2009 22:23:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 22:23:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 22:23:10 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E13@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSTQFTLWL/4JP/SFaGU9RvxSenuQAMlbqQAAGKYvAAAXRRgA== References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2E13@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "SIPCORE" X-OriginalArrivalTime: 21 Oct 2009 20:23:10.0703 (UTC) FILETIME=[4EF48FF0:01CA528C] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:23:05 -0000 Hi, In general I am ok with your comments, so I will implement them. One thing, though, regarding your comment saying:=20 "[JRE] Perhaps being rather pedantic, but shouldn't we say "A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set..."?" I don't think the UA needs to indicate anything during dialog establishment - it can indicate the initial set also during the dialog. Well, it does need to include Recv-Info header field during dialog establishment, but the header value could be 'nil'. But, it's just editorial, so I'll try to come up with something. Regarding 1.2, the check-out-other-alternatives-before-you-define-an-I-P of course already describes subscription-based events, so I am not sure we need the text at all. But, I am ok with keeping it in the introduction. Regarding 1.3, I was thinking that it could be added to the Legacy INFO usage section later in the document, and the introduction could simply refer to it. But, I have no strong feelings on that. Regards, Christer -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 21. lokakuuta 2009 22:47 To: Christer Holmberg; SIPCORE Subject: RE: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Christer, This seems a lot better. A few specific comments embedded. I would keep 1.2 and 1.3 here, unless there is an obvious alternative place for one or both of them. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 21 October 2009 20:27 > To: Elwell, John; SIPCORE > Subject: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in > info-events >=20 >=20 > Hi, >=20 > >Section 1 says what RFC 2976 does, says what its drawbacks are, and > then says that this document describes a mechanism that addresses=20 > those drawbacks. It does not state that this document defines the > >INFO method. It even refers back to RFC 2976 for the > definition of the > INFO method ("The purpose of the INFO message [RFC2976] is.... "). > > > >Yet this document supposedly obsoletes RFC 2976. > > > >I would have expected the introduction to a document that > obsoletes an > earlier RFC to be self-standing and structured more like the > following: > >- Introductory text very similar to what is in the obsoleted RFC, but > modified to mention anything that is significantly different. > >- A reference back to the obsoleted RFC, describing what has changed. > > > >In this particular case, the text of RFC 2976 is a rough starting > point. It even says, near the end, that the document does not specify=20 > specific uses, so that is an ideal point to continue and talk about > >usages, Info-Packages, and indicating supported usages. > > > >We could then continue by saying that the document obsoletes > RFC 2976, > which did not define the Info-Package concept and explicit indications > of which usages are supported. >=20 > I agree that we may refer/depend a little too much on RFC 2976 - and I > think Robert commented on the same issue. It is probably some text=20 > which was useful during the justficiation phase, but should be=20 > changes. >=20 > Basically we should only refer to 2976 when we talk about legacy INFO=20 > usage, and when we talk about the drawbacks of legacy INFO usage. >=20 > Below is a re-write of the introduction, which I think addresses your=20 > issue. >=20 > (We could of course discuss whether 1.2 and 1.3 really should be in=20 > the introduction, or be moved to other places in the spec.) >=20 > "1. Introduction >=20 > 1.1 General >=20 > This document defines a new method, INFO, for the Session=20 > Initiation Protocol (SIP) [RFC2976]. > In addition, it defines an Info Package mechanism. An Info Package=20 > defines the content and semantics of the > information carried in an INFO message associated with the Info=20 > Package. > The Info Package mechanism also provides a way for UAs to indicate=20 > for > which types of applications and contexts they are willing to=20 > receive INFO requests. The > document defines how the INFO method is used, new SIP header fields > for the > INFO method, and how to transport payload information associated=20 > with an Info Package > using INFO requests.=20 > =20 > The purpose of the INFO message is to carry application > level information between endpoints, using the SIP session=20 > signaling > path. Note that the INFO method is not used to update > characteristics of the SIP session, but to allow the applications > which use the SIP session to exchange information. [JRE] I think this ought to come earlier, after the very first sentence, before we start talking about Info Packages. >=20 > The Info Package mechanism does not define a separate dialog usage. [JRE] I would prefer "Use of the INFO method does not constitute a separate dialog usage". > INFO messages are always part of, and share the fate of, an invite > dialog usage. INFO messages cannot be sent as part of other dialog > usages. >=20 > If a UA supports the Info Package mechanism, it uses the Recv-Info [JRE] Any UA supporting this RFC must support the Info Package mechanism, so we can shorten this to "A UA uses the Recv-Info..." > header field, on a per-dialog basis, to indicate for which Info=20 > Packages > it is willing to receive INFO requests. A UA can indicate a new=20 > set of Info > Packages at any time during the lifetime of the invite dialog=20 > usage. [JRE] Perhaps being rather pedantic, but shouldn't we say "A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set..."? > A UA can use a "nil" value to indicate that it is not willing to > receive any Info Packages at a certain moment, but that=20 > the UA still > supports the Info Package mechanism. >=20 > When a UA sends an INFO request, it uses the Info-Package header > field to indicate which Info Package is associated with=20 > the request. > One particular INFO > request can only be associated with a single Info Package. >=20 > This document obosoletes [RFC2976]. However, for backward=20 > compability > it allows > to use INFO per [RFC2976], referred to as legacy INFO usage in the > document. >=20 > 1.2 Problems with leagcy INFO usage >=20 > While legacy INFO usage [RFC2976] has been widely adopted for > specific > application use cases, such as ISUP and DTMF exchange,=20 > [RFC2976] does > not > not define a mechanisms for SIP UAs to indicate for which types of > applications and contexts they > support the INFO method.what usages of INFO. In addition, [RFC2976] [JRE] Change "mechanisms" to "mechanism". Also I think the words "what usages of INFO" should have been deleted. John > does not provide a mechanism to > explicitly indicate the type of application and context for which a > specific INFO message is associated to. > In some cases it can be determined by the INFO message body payload > content, but not in a general way. >=20 > Example: If the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. Still, there are many useful=20 > ways a UA can > render an image. The image could be a caller-id picture, a contact > icon, a photo for sharing, and so on. The sender does not=20 > know which > image to send to the receiver if the receiver supports an image > content type. Likewise, the receiver does not know the=20 > context of an > image the client is sending if the receiver supports receiving more > than one image content type. >=20 > Due to the problems described above, legacy INFO usages=20 > often require > static configuration about for what type of applications=20 > and contexts > UAs support the INFO method,=20 > and the way they handle application information transported in INFO > messages. > That has caused interoperability problems in the industry. > Therefore,a need for a well defined and > documented description of what the information sent in the INFO is > used for has been identified. This situation is analogous to the > context issue in > Internet Mail [RFC3458]. >=20 > 1.3 Relationship to subscription-based event >=20 > Event Packages [RFC3265] perform the role of disambiguating the > context of a message for subscription-based events. The=20 > Info Package > mechanism provides similar functionality for application=20 > information > exchange using invite dialog usages [RFC5057]. However, there is no > formal > relationship between the Info Package mechanism and the > subscription-based event > mechanism." >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 From christer.holmberg@ericsson.com Wed Oct 21 13:43:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5311B28C137 for ; Wed, 21 Oct 2009 13:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDPEQaRDJ5KG for ; Wed, 21 Oct 2009 13:42:59 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EF70828C158 for ; Wed, 21 Oct 2009 13:42:58 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-e2-4adf725a94a2 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 3E.83.08816.A527FDA4; Wed, 21 Oct 2009 22:43:06 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 22:42:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 22:42:34 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E16@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpShn0rOZbevWSGRQquNJLiglHR5wAAYHiAAAFzMKA= References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E16@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 21 Oct 2009 20:42:35.0868 (UTC) FILETIME=[0572A1C0:01CA528F] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:43:01 -0000 Hi,=20 >> Lets imagine for the moment that we are designing a new info package, >> and it happens to need two distinct clumps of data - e.g. a piece of=20 >> simple text and an xml file. How should the info package spec specify >> that data be encapsulated within the message? There seem to be a few=20 >> ways to do this: >> >> 1) there should be a multipart/mixed, with C-D of info-pkg, >> that consolidates all the data. >> Within that are two parts: >> - one with C-T text/plain >> - one with C-T text/xml (or whatever) >> Each may have C-D that is appropriate to its intended use >> by the application, or let it default to "render". >> (What render means to an info package is a good question.) >> >> 2) same as (1) except the outer wrapper is multipart/related, >> and as a result the C-D of the subordinate parts is likely >> less important. >> >> 3) the body of the message is of C-T multipart/mixed, and the >> C-D is "render" or unspecified. >> Within that are two or more parts. >> One of those has C-T text/plain and C-D info-pkg. >> Another of those has C-T text/xml (or whatever) and >> C-D of info-pkg. >> None of the other direct children parts of the top level >> multipart have C-D of info-pkg. >> >> I think that 1 and/or 2 are enough, and that there is no need to=20 >> permit (3). I agree that (3) can work, but I just think that is=20 >> unnecessarily confusing things. >[JRE] I agree that (3) is an unnecessary complication. It is hard to imagine a situation that can't be accomplished by (1) or (2) (or a single part body, of course). In the interests of interoperability,=20 >limit the options where reasonable. Maybe I don't get it, but I really think you are making things complicated, for no reason, and will require extra if-then-else kind of text. The Info-Package mechanism was supposed to be simple. I'm afraid this would just make people continue to use legacy INFO... In my opinon is is much easier to, in the base spec, simply say that each body part (no matter where they are located, and no matter what C-D value their parent may have) associated with an I-P must have C-D 'info-package'. Why does that not work???=20 THEN, IF a specific Info Package requries body parts to be "collected" inside multiparts etc, that specific Info Package specification should say so. For example, if an Info Package can be used to send alternative-whatever-data, the specification for that I-P should say that the body parts must be children of a multipart/alternative parent. Etc etc etc. Regards, Christer > > It does seem that there is a fundamental difference of opinion here=20 > that needs to be sorted out. Can some other people chime in here? > > Thanks, > Paul > > > Regards, > > > > Christer > > > > > > > > > > > > In the above I added "and the Content-Disposition is "render" or=20 > > unspecified". I wish we had specified a specific C-D for > the top level > > multipart that contains unrelated body parts in a sip > message. Somehow > > that got missed in body-handling, though it would have been > an issue for > > backward compatibility. > > > > Thanks, > > Paul > > > >> NOTE: To avoid corner cases with legacy INFO usage, the > Info-Package > > header field is used to indicate the Info Package name, rather than=20 > > using a Content-Disposition header field parameter in order > to indicate > > the name." > >> How does this sound? > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: 20 October 2009 21:50 > >>> To: Christer Holmberg > >>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo;=20 > >>> draft-ietf-sipcore-info-events@tools.ietf.org > >>> Subject: Re: [sipcore] WGLC comments > >>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P=20 > >>> body parts in INFO? > >>> > >>> > >>> > >>> Christer Holmberg wrote: > >>>> Hi, > >>>> > >>>>> It sounds like we may have different conceptions of how > body parts > >>>> might be strung together for this. > >>>>> If I read your text below correctly, then it would be > >>> possible for the > >>>> INFO message to have a multipart mixed body, where some > >>> body parts are > >>>> not part of the info package (authentication stuff, geoloc > >>>>> stuff), but where one *or more* other parts are considered > >>> part of the > >>>> info package. > >>>> > >>>> Section 4.3 talks about "SIP extensions that are orthogonal > >>> to INFO MAY > >>>> insert body parts unrelated to the Info Package". > >>>> > >>>> Personally, though, I doubt that someone would say "Hey, > someone is > >>>> about the send an INFO, so I'll throw in my message body > part there > >>>> too!". I think that any application who wants to send an > >>> INFO (no matter > >>>> whether it's legacy of I-P based, should trigger a > >>> dedicated INFO, and > >>>> not try to get a "free ride" by someone else... > >>> The way I envision this might happen would be because of some=20 > >>> optional header inserted in the message that has a reference to a=20 > >>> body part, via a cid: url. I guess INFO can't have > Alert-Info, but if > > > >>> it could then that would be one example. > >>> > >>> Another example might be an AIB body. > >>> > >>> Most are pretty far fetched for INFO, but we should not > exclude the > >>> possibility. > >>> > >>>>> It was my thinking that there will always be *one* body > >>> part that is > >>>> the root of all stuff that is associated with the info > >>> package. In the > >>>> simplest case this would be the whole body of the message, > >>>>> containing for example DTMF info. In a slightly more > >>> complicated case > >>>> it might be that same DTMF body, but as one body part in a=20 > >>>> multipart/mixed, where the other body parts are for > >>> incidental purposes > >>>>> but not part of the info package. > >>>> Personally I agree with you, but the text has been there > for a while > > > >>>> already. If people want to remove it, though, I am happy > to do it. > >>> The way that C-D works means that technically you *could* have=20 > >>> multiple parts with C-D of info-pkg. The question is > whether there is > > > >>> any value in making it legal. If so then somebody has to > define what > >>> it means. > >>> Since we have multipart which already has lots of ways to group=20 > >>> parts, why do we need to introduce yet another grouping mechanism=20 > >>> here? > >>> > >>>>> In cases where the info package itself needs more than one > >>> body part, > >>>> it would consist of a multipart containing all of its > >>> pieces. Then that > >>>> multipart would be just as above - either the only thing in > >>>>> the message, or else it would be a multipart within a > >>> multipart, along > >>>> with other incidental parts. > >>>> > >>>> Just to make sure: even if we say that all body parts must > >>> be associated > >>>> with the Info Package, do you agree that they ALL still > >>> shall have a C-D > >>>> with 'info-package'? Otherwise parsers may assign whatever > >>> the default > >>>> C-D value is for them, and we don't want that to happen... > >>> NO, I don't agree. > >>> > >>> These are nested structures. They may come from some > other place and > >>> be formed and processed by non-sip code that knows nothing of=20 > >>> info-pkg. > >>> Once you unwrap the first box, I think you should be > allowed to have > >>> whatever you want inside. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Christer Holmberg wrote: > >>>>> Hi, > >>>>> > >>>>>> Your explanation sounds reasonable. I think it requires some > >>>>> clarification in both 7.6 and 4.3: > >>>>>> - in 7.6 it should talk about a body part, which may > be multipart; > >>>>> 7.6 shall definitely be changed. It should say "body parts". > >>>>> > >>>>> "7.6. INFO Message Body > >>>>> > >>>>> The Info Package specification MUST define what type of > >>> message body > >>>>> parts, are associated with the Info Package, and MUST refer to=20 > >>>>> specifications where the syntax, semantics and MIME > type of each > >>>>> message body part is described." > >>>>> > >>>>> - The old text used to say "message bodies, if any", but I > >>> removed "if > >>>>> any" due to the change that the Info Package shall not > assume on > >>>>> information being conveyed in SIP headers (see other e-mail). > >>>>> > >>>>> ------------- > >>>>> > >>>>>> - in 4.3 it should talk about labelling the Info-Package > >>> body part > >>>>>> with > >>>>> Content-Disposition: Info-Package, this being at the SIP > >>> level if it > >>>>> is the sole body part (i.e., the entire body of the SIP > >>>>>> message). > >>>>> Yes. Basically the text shall say that each message body part=20 > >>>>> associated with the Info Package shall have a associated > >>> C-D header > >>>>> filed with an 'info-package' value. And, if there is > only a single > >>>>> body part in a message the SIP level C-D header field > contains the > >>>> 'info-package' > >>>>> value. > >>>>> > >>>>> Also, 4.3 talks about "message body payloads", but I will > >>> change to > >>>>> "message body parts" there, to be consistent with 7.6. > >>>>> > >>>>> NOTE: The new 4.3 text below may also contain changes > I've already > >>>>> done based on other comments: > >>>>> > >>>>> "4.3. INFO Request Message Body > >>>>> > >>>>> The purpose of the INFO request is to carry application level > >>>>> information between SIP UAs. The application data > >>> associated with > >>>> an > >>>>> Info Package is carried as a payload in the message body of > >>>>> the INFO request. > >>>>> > >>>>> An INFO request message body can contain a single > body part, or > >>>>> multiple > >>>>> body parts (multipart/mixed). > >>>>> > >>>>> Info Package specifications MUST describe the > application level > >>>>> information associated with the Info Package. > Message body parts > >>>>> MUST have a MIME type value defined. > >>>>> > >>>>> If a UA indicates that it is willing to receive a > specific Info > >>>>> Package, it means that the UA also supports any > >>> associated message > >>>>> body MIME type associated with the Info Package. > >>> However, the UA > >>>>> MUST still indicate support of those MIME types also in > >>> the Accept > >>>>> header field, according to the procedures in [RFC3261]. > >>>>> > >>>>> Some SIP extensions that are orthogonal to INFO MAY > insert body > >>>> parts > >>>>> unrelated to the Info Package. UAs MUST conform to > [RFC3261] as > >>>>> updated by body-handling > [I-D.ietf-sip-body-handling] to support > >>>>> multipart MIME handling. > >>>>> > >>>>> Each message body part associated with an Info Package MUST > >>>>> contain a Content-Disposition header field with an > >>> 'Info-Package' > >>>>> value, in order to in an easy way distinguish payloads > >>> associated > >>>>> with the Info Package from other payloads. > >>>>> > >>>>> If the message body only contains a single body part, > >>> the SIP level > >>>>> Content-Disposition header field > >>>>> contains an 'info-package' value. > >>>>> > >>>>> If the message body contains multiple body parts > >>> (multipart/mixed) > >>>>> the SIP level Content-Disposition header field > >>>>> does not need to include an 'info-package' value, since > >>> each body > >>>>> part associated with the Info Package will include > >>>>> a Content-Disposition header field for that specific > body part. > >>>>> > >>>>> NOTE: To avoid corner cases with legacy INFO usage, the > >>>> Info-Package > >>>>> header field is used to indicate the Info Package name, > >>> rather than > >>>>> to use a Content-Disposition header field parameter > in order to > >>>>> indicate the name." > >>>>> > >>>>> ------------- > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> > >>>>> > >>>>> > > > From pkyzivat@cisco.com Wed Oct 21 16:31:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC9828C0DF for ; Wed, 21 Oct 2009 16:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.66 X-Spam-Level: X-Spam-Status: No, score=-6.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1+At-JNwm-8 for ; Wed, 21 Oct 2009 16:31:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64C8D3A687E for ; Wed, 21 Oct 2009 16:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2590; q=dns/txt; s=sjiport06001; t=1256167909; x=1257377509; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2019:31:51=20-0400|Message-ID:=20<4ADF99E7. 4000103@cisco.com>|To:=20"Elwell,=20John"=20|CC:=20Christer=20Holmberg=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20"draft-ietf-sipcore-info-events@tools.ietf .org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<7402509E63C5A145A6095D46C179A5B7148B2E0F @DEMCHP99E35MSX.ww902.siemens.net>|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP 99E35MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com >=20<7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35 MSX.ww902.siemens.net>=20=20<4ADE168F.70603 03@cisco.com>=20=20<4ADE227C.5020500@cisco. com>=20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99 E35MSX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35M SX.ww902.siemens.net>; bh=T0RS0eBSMC+t+/mFllS1r9tZhxqcsAZ8Y96ERL8D0Cc=; b=shCmx8r8Mem5BmYY6l6Ckya3CZM7YOTuGhCG8I99x+/zWF//IhNr7mys vw2vN0nzoBsY76NJS8iysy1eE4Gr06sqaOWdP6zO0CEtkuI0HC9RDLs8H 3Bhoc83o7CU28c0ajgXsfF3iKFEi+cYtGJrYzoVAG8O7NMiGp2Ifq5mvo A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAo330pAZnwM/2dsb2JhbADCK5hWhDME X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208";a="414739055" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2009 23:31:48 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LNVmII024908; Wed, 21 Oct 2009 23:31:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 19:31:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 19:31:48 -0400 Message-ID: <4ADF99E7.4000103@cisco.com> Date: Wed, 21 Oct 2009 19:31:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 23:31:48.0027 (UTC) FILETIME=[A89B28B0:01CA52A6] Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 23:31:41 -0000 Elwell, John wrote: > > >> -----Original Message----- [snip] >>> The body part associated with the Info Package MUST contain >> a Content-Disposition header field with value 'Info-Package', >> in order easily to distinguish payloads associated with the >> Info Package from other payloads. If the message body only >> contains the single body part associated with the >> Info-Package, the SIP level Content-Disposition header field >> MUST contain value 'Info-Package'. If the message body is of >> type multipart/mixed, the child body part associated with the >> Info-Package MUST include a Content-Disposition header field >> with value 'Info-Package'. Child body parts of a >> multipart/mixed body part associated with the Info-Package do >> not require this Content-Disposition value. >> >> Some slight rewording suggestions: >> >> ... >> If the message body is of type multipart/mixed, >> * and the Content-Disposition is "render" or unspecified, >> the child body part associated with the Info-Package MUST include a >> Content-Disposition header field with value >> 'Info-Package'. Child body >> * parts of a multipart body part associated with the >> Info-Package do not >> * ^^^^^^^^^^ >> require this Content-Disposition value. >> >> In the above I added "and the Content-Disposition is "render" or >> unspecified". > [JRE] But wouldn't that then conflict with the first of my proposed sentences? The first sentence says "The body part associated with the Info Package MUST contain a Content-Disposition header field with value 'Info-Package'". Your modified second sentence then seems to contradict it by saying only in certain circumstances does it need to do this. I think we are probably just not envisioning the same use case. This is entangled with the debate I am having with Christer elsewhere. I'll try a picture: ==== INFO message headers ====== | INFO ... | C-D: info-pkg | C-T: multipart/whatever | (other headers) | ==== INFO body start =========== | ==== Part 1 headers ========== | | C-T: text/plain | | C-D: foo | | | ==== Part 1 body start ======= | | some text | ==== Part 1 end ============== | ==== Part 2 headers ========== | | C-T: application/bar | | C-D: baz | | | ==== Part 2 body start ======= | | (application/baz stuff) | ==== Part 2 end ============== ==== INFO end ================== This is what my text was trying to describe. And I don't think it is in conflict with your text in the beginning of the paragraph. Thanks, Paul From pkyzivat@cisco.com Wed Oct 21 16:40:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D593A698C for ; Wed, 21 Oct 2009 16:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.657 X-Spam-Level: X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6GXgDu9vzRY for ; Wed, 21 Oct 2009 16:40:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 77AB93A6805 for ; Wed, 21 Oct 2009 16:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=16229; q=dns/txt; s=sjiport01001; t=1256168441; x=1257378041; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2019:40:44=20-0400|Message-ID:=20<4ADF9BFC. 50007@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20=20S IPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Camarill o=20,=0D=0A=20=20=20=20 =20=20=20=20draft-ietf-sipcore-info-events@tools.ietf.org |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20=20<4ADE227C.5020500@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20=20<4ADF63CD.5050707@cisco.com>=20; bh=ueXlnbj+KWc0fi3MBflNzIiWJHbxD08Qf1o2jQdcjNU=; b=ViIMts7kLqOWlNuPV9NNGAn4R+63yXphLwqgOE4O0yl7R8rE/Dlro5ok df7WGp3/EGUIyyG4J5G6UqMYPE4MFjsPbSlzlCN2NNlpRUvlzkqBo7yPB PSk0HDC6ULk9Q7SnzWA6z+C6eglJ72aSTLahw+YPiU13ubQp/punMQpTy M=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOo430qrR7Ht/2dsb2JhbADCL5hXhDMEglY X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208";a="259537656" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2009 23:40:41 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9LNefmx018788; Wed, 21 Oct 2009 23:40:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 19:40:40 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 19:40:39 -0400 Message-ID: <4ADF9BFC.50007@cisco.com> Date: Wed, 21 Oct 2009 19:40:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2009 23:40:39.0912 (UTC) FILETIME=[E5A25E80:01CA52A7] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 23:40:34 -0000 Christer Holmberg wrote: > Hi, > >>>> The body part associated with the Info Package MUST contain a >>>> Content-Disposition header field with value 'Info-Package', in order >>>> easily to distinguish payloads associated with the Info Package from >>>> other payloads. If the message body only contains the single body >>>> part associated with the Info-Package, the SIP level > Content-Disposition >>>> header field MUST contain value 'Info-Package'. If the message >>>> body is of type multipart/mixed, the child body part associated with >>>> the Info-Package MUST include a Content-Disposition header field with > >>>> value 'Info-Package'. Child body parts of a multipart/mixed body >> part >>>> associated with the Info-Package do not require this > Content-Disposition value. >>>> Some slight rewording suggestions: >>>> >>>> ... >>>> " If the message body is of type multipart/mixed, >>>> * and the Content-Disposition is "render" or unspecified, >>>> the child body part associated with the Info-Package MUST include > a >>>> Content-Disposition header field with value 'Info-Package'. Child > body >>>> * parts of a multipart body part associated with the Info-Package do >>>> not >>>> * ^^^^^^^^^^ >>>> require this Content-Disposition value." >>> I don't agree with that text. As I said earlier, RFC 5621 says that >>> the C-D value of the "parent body part" (C-T multipart) is IRRELEVANT >>> to the "child body parts" - they must explicitly be assigned >>> individual C-T values, or they will be assigned a default value. >> Of course the child body parts don't *inherit" the C-D value. >> But it doesn't matter. In this case it is the multipart itself that is > the "payload" for the INFO message. Once it has been identified, and > turned over to the application to process, *we don't care* what >> the C-D of the contained parts is. > > I don't agree. Eventhough I do hear what you are saying, in my opinion > "We don't care" goes against what we tried to fix with RFC 5621, and > could potentially cause problems. An Info-Package body part shall have > C-D 'info-package', and I don't like that fact that we should allow "any > value" to be assigned to a body part just because it is transported > within a multipart. IMO its not about overhead, its about layering. Consider multiparts used in email, such as for attachments. The attachments are often understood by pieces of software independent of the email system. Similarly here. There will be something that receives the info package body - that knows that is what it is. But if it has chosen to use multipart to consolidate a number of things into it, those might come from, and be consumed by independent software. (Considering that INFO has been used for tunneling stuff for other protocols, its really easy to imagine that.) The subordinate C-D values may be needed to interpret that stuff. I think we don't have enough people in this discussion. The two of us are just not going to agree. I'd like to hear from Adam who has had a lot of insight into multipart in the past, and from Gonzallo, who wrote the body handling draft. Thanks, Paul > There is really no harm, and very little message overhead, in adding C-D > 'info-package' for each body part. I think it is a "hack" by not doing > it - even if it would work well. > >> What C-D values are relevant within there must be documented as part of > the specific info-pkg documentation. > > Body parts associated with Info Packages must have C-D 'info-package' - > nothing else. > > ----------- > >>> To use OOP language: a child body part does NOT inherit the C-D value > of its parent :) >>> So, therefor I don't think it really matters what the C-D value of the > >>> parent body part is, because it does not affect the child body parts. >> *If* you have a top level multipart/mixed that isn't C-D info-pkg (and > is in fact without a C-D or has one of "render") then that will contain > incidental parts of varying relevance to the message. In >> that case, if more than one of those is of C-D info-pkg, and if we > determine that is valid, then fine - those are each passed to the > application. > > Agree. > > ----------- > >> But if the whole body is of type C-D info-pkg, then it doesn't matter > what C-T it is, or whether than is a multipart or not, it all goes to > the application as the info package payload. > > That may be true, but I still think it is wrong to send the wrong C-D > values to the application - no matter if it cares about them or not. It > is not specified in RFC 5621, and I have never heard about another usage > which act like that. > > ----------- > >> Lets imagine for the moment that we are designing a new info package, > and it happens to need two distinct clumps of data - e.g. a piece of > simple text and an xml file. How should the info package spec >> specify that data be encapsulated within the message? There seem to be > a few ways to do this: >> 1) there should be a multipart/mixed, with C-D of info-pkg, >> that consolidates all the data. >> Within that are two parts: >> - one with C-T text/plain >> - one with C-T text/xml (or whatever) >> Each may have C-D that is appropriate to its intended use >> by the application, or let it default to "render". >> (What render means to an info package is a good question.) > > If they are associated with the Info-Package, each body part should have > C-D 'info-pkg'. The I-P specification then says whether the application > use them for some rendering, or whatever. As far as the SIP protocol is > concerned, the body parts simply contain something beloning to the I-P. > > ----------- > >> 2) same as (1) except the outer wrapper is multipart/related, >> and as a result the C-D of the subordinate parts is likely >> less important. >> >> 3) the body of the message is of C-T multipart/mixed, and the >> C-D is "render" or unspecified. >> Within that are two or more parts. >> One of those has C-T text/plain and C-D info-pkg. >> Another of those has C-T text/xml (or whatever) and >> C-D of info-pkg. >> None of the other direct children parts of the top level >> multipart have C-D of info-pkg. >> >> I think that 1 and/or 2 are enough, and that there is no need to permit > (3). I agree that (3) can work, but I just think that is unnecessarily > confusing things. > > I think the less confusing thing is to assign each body part a proper > C-D value :) > > (I am not even sure what C-D for a multipart really means, since the > children will override it anyway (either explicitly or implicitly) but I > guess I will have to look it up.) > > Regards, > > Christer > > > > > >> It does seem that there is a fundamental difference of opinion here > that needs to be sorted out. Can some other people chime in here? > > > > > > > > > >> >> >> >> In the above I added "and the Content-Disposition is "render" or >> unspecified". I wish we had specified a specific C-D for the top level > >> multipart that contains unrelated body parts in a sip message. Somehow > >> that got missed in body-handling, though it would have been an issue >> for backward compatibility. >> >> Thanks, >> Paul >> >>> NOTE: To avoid corner cases with legacy INFO usage, the Info-Package >> header field is used to indicate the Info Package name, rather than >> using a Content-Disposition header field parameter in order to >> indicate the name." >>> How does this sound? >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 20 October 2009 21:50 >>>> To: Christer Holmberg >>>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; >>>> draft-ietf-sipcore-info-events@tools.ietf.org >>>> Subject: Re: [sipcore] WGLC comments >>>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P >>>> body parts in INFO? >>>> >>>> >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>>> It sounds like we may have different conceptions of how body parts >>>>> might be strung together for this. >>>>>> If I read your text below correctly, then it would be >>>> possible for the >>>>> INFO message to have a multipart mixed body, where some >>>> body parts are >>>>> not part of the info package (authentication stuff, geoloc >>>>>> stuff), but where one *or more* other parts are considered >>>> part of the >>>>> info package. >>>>> >>>>> Section 4.3 talks about "SIP extensions that are orthogonal >>>> to INFO MAY >>>>> insert body parts unrelated to the Info Package". >>>>> >>>>> Personally, though, I doubt that someone would say "Hey, someone is > >>>>> about the send an INFO, so I'll throw in my message body part there > >>>>> too!". I think that any application who wants to send an >>>> INFO (no matter >>>>> whether it's legacy of I-P based, should trigger a >>>> dedicated INFO, and >>>>> not try to get a "free ride" by someone else... >>>> The way I envision this might happen would be because of some >>>> optional header inserted in the message that has a reference to a >>>> body part, via a cid: url. I guess INFO can't have Alert-Info, but >>>> if >>>> it could then that would be one example. >>>> >>>> Another example might be an AIB body. >>>> >>>> Most are pretty far fetched for INFO, but we should not exclude the >>>> possibility. >>>> >>>>>> It was my thinking that there will always be *one* body >>>> part that is >>>>> the root of all stuff that is associated with the info >>>> package. In the >>>>> simplest case this would be the whole body of the message, >>>>>> containing for example DTMF info. In a slightly more >>>> complicated case >>>>> it might be that same DTMF body, but as one body part in a >>>>> multipart/mixed, where the other body parts are for >>>> incidental purposes >>>>>> but not part of the info package. >>>>> Personally I agree with you, but the text has been there for a >>>>> while >>>>> already. If people want to remove it, though, I am happy to do it. >>>> The way that C-D works means that technically you *could* have >>>> multiple parts with C-D of info-pkg. The question is whether there >>>> is >>>> any value in making it legal. If so then somebody has to define what > >>>> it means. >>>> Since we have multipart which already has lots of ways to group >>>> parts, why do we need to introduce yet another grouping mechanism >>>> here? >>>> >>>>>> In cases where the info package itself needs more than one >>>> body part, >>>>> it would consist of a multipart containing all of its >>>> pieces. Then that >>>>> multipart would be just as above - either the only thing in >>>>>> the message, or else it would be a multipart within a >>>> multipart, along >>>>> with other incidental parts. >>>>> >>>>> Just to make sure: even if we say that all body parts must >>>> be associated >>>>> with the Info Package, do you agree that they ALL still >>>> shall have a C-D >>>>> with 'info-package'? Otherwise parsers may assign whatever >>>> the default >>>>> C-D value is for them, and we don't want that to happen... >>>> NO, I don't agree. >>>> >>>> These are nested structures. They may come from some other place and > >>>> be formed and processed by non-sip code that knows nothing of >>>> info-pkg. >>>> Once you unwrap the first box, I think you should be allowed to have > >>>> whatever you want inside. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>>> Your explanation sounds reasonable. I think it requires some >>>>>> clarification in both 7.6 and 4.3: >>>>>>> - in 7.6 it should talk about a body part, which may be >>>>>>> multipart; >>>>>> 7.6 shall definitely be changed. It should say "body parts". >>>>>> >>>>>> "7.6. INFO Message Body >>>>>> >>>>>> The Info Package specification MUST define what type of >>>> message body >>>>>> parts, are associated with the Info Package, and MUST refer to >>>>>> specifications where the syntax, semantics and MIME type of each >>>>>> message body part is described." >>>>>> >>>>>> - The old text used to say "message bodies, if any", but I >>>> removed "if >>>>>> any" due to the change that the Info Package shall not assume on >>>>>> information being conveyed in SIP headers (see other e-mail). >>>>>> >>>>>> ------------- >>>>>> >>>>>>> - in 4.3 it should talk about labelling the Info-Package >>>> body part >>>>>>> with >>>>>> Content-Disposition: Info-Package, this being at the SIP >>>> level if it >>>>>> is the sole body part (i.e., the entire body of the SIP >>>>>>> message). >>>>>> Yes. Basically the text shall say that each message body part >>>>>> associated with the Info Package shall have a associated >>>> C-D header >>>>>> filed with an 'info-package' value. And, if there is only a single > >>>>>> body part in a message the SIP level C-D header field contains the >>>>> 'info-package' >>>>>> value. >>>>>> >>>>>> Also, 4.3 talks about "message body payloads", but I will >>>> change to >>>>>> "message body parts" there, to be consistent with 7.6. >>>>>> >>>>>> NOTE: The new 4.3 text below may also contain changes I've already > >>>>>> done based on other comments: >>>>>> >>>>>> "4.3. INFO Request Message Body >>>>>> >>>>>> The purpose of the INFO request is to carry application level >>>>>> information between SIP UAs. The application data >>>> associated with >>>>> an >>>>>> Info Package is carried as a payload in the message body of >>>>>> the INFO request. >>>>>> >>>>>> An INFO request message body can contain a single body part, or > >>>>>> multiple >>>>>> body parts (multipart/mixed). >>>>>> >>>>>> Info Package specifications MUST describe the application level >>>>>> information associated with the Info Package. Message body > parts >>>>>> MUST have a MIME type value defined. >>>>>> >>>>>> If a UA indicates that it is willing to receive a specific Info >>>>>> Package, it means that the UA also supports any >>>> associated message >>>>>> body MIME type associated with the Info Package. >>>> However, the UA >>>>>> MUST still indicate support of those MIME types also in >>>> the Accept >>>>>> header field, according to the procedures in [RFC3261]. >>>>>> >>>>>> Some SIP extensions that are orthogonal to INFO MAY insert body >>>>> parts >>>>>> unrelated to the Info Package. UAs MUST conform to [RFC3261] as >>>>>> updated by body-handling [I-D.ietf-sip-body-handling] to > support >>>>>> multipart MIME handling. >>>>>> >>>>>> Each message body part associated with an Info Package MUST >>>>>> contain a Content-Disposition header field with an >>>> 'Info-Package' >>>>>> value, in order to in an easy way distinguish payloads >>>> associated >>>>>> with the Info Package from other payloads. >>>>>> >>>>>> If the message body only contains a single body part, >>>> the SIP level >>>>>> Content-Disposition header field >>>>>> contains an 'info-package' value. >>>>>> >>>>>> If the message body contains multiple body parts >>>> (multipart/mixed) >>>>>> the SIP level Content-Disposition header field >>>>>> does not need to include an 'info-package' value, since >>>> each body >>>>>> part associated with the Info Package will include >>>>>> a Content-Disposition header field for that specific body part. >>>>>> >>>>>> NOTE: To avoid corner cases with legacy INFO usage, the >>>>> Info-Package >>>>>> header field is used to indicate the Info Package name, >>>> rather than >>>>>> to use a Content-Disposition header field parameter in order to >>>>>> indicate the name." >>>>>> >>>>>> ------------- >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> > From pkyzivat@cisco.com Wed Oct 21 17:00:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120A128C122 for ; Wed, 21 Oct 2009 17:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.654 X-Spam-Level: X-Spam-Status: No, score=-6.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T28UKBgJ9FXb for ; Wed, 21 Oct 2009 17:00:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7A3C93A635F for ; Wed, 21 Oct 2009 17:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=13417; q=dns/txt; s=rtpiport01001; t=1256169633; x=1257379233; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Wed,=2021 =20Oct=202009=2020:00:30=20-0400|Message-ID:=20<4ADFA09E. 8010808@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20draft-ietf-sipcore-info-events@tools.ietf. org|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20=20<4ADE227C.5020500@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20=20<4ADF63CD.5050707@cisco.com>=20<7402509E63 C5A145A6095D46C179A5B7148B2E16@DEMCHP99E35MSX.ww902.sieme ns.net>=20; bh=yf4h6j7njCFqpsUhAcTKGdI0rvzQ3+q58Hzc/AAg63o=; b=iY/XzXvMsifsX2SjvRzocNEZSFMqe4wKhf69VOmnohrF4QId97v5ujAp KbHVa2LyVj7dZ9F5UOl+yakgwkVoFzLU5Gy5zxgdl+bWiH2BvRtigHr+p VFPKRDURRRe8vyh+mXUo0cJ/ZAz+nz6BU4RQaP7WvB/I4O4q4X7801YnZ 4=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJs930pAZnwN/2dsb2JhbADCL5hShDME X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208";a="64218270" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 00:00:31 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9M00Vt1003164; Thu, 22 Oct 2009 00:00:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:00:31 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:00:31 -0400 Message-ID: <4ADFA09E.8010808@cisco.com> Date: Wed, 21 Oct 2009 20:00:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E16@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 00:00:31.0209 (UTC) FILETIME=[ABB3DD90:01CA52AA] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 00:00:48 -0000 Christer Holmberg wrote: > Hi, > >>> Lets imagine for the moment that we are designing a new info package, > >>> and it happens to need two distinct clumps of data - e.g. a piece of >>> simple text and an xml file. How should the info package spec specify > >>> that data be encapsulated within the message? There seem to be a few >>> ways to do this: >>> >>> 1) there should be a multipart/mixed, with C-D of info-pkg, >>> that consolidates all the data. >>> Within that are two parts: >>> - one with C-T text/plain >>> - one with C-T text/xml (or whatever) >>> Each may have C-D that is appropriate to its intended use >>> by the application, or let it default to "render". >>> (What render means to an info package is a good question.) >>> >>> 2) same as (1) except the outer wrapper is multipart/related, >>> and as a result the C-D of the subordinate parts is likely >>> less important. >>> >>> 3) the body of the message is of C-T multipart/mixed, and the >>> C-D is "render" or unspecified. >>> Within that are two or more parts. >>> One of those has C-T text/plain and C-D info-pkg. >>> Another of those has C-T text/xml (or whatever) and >>> C-D of info-pkg. >>> None of the other direct children parts of the top level >>> multipart have C-D of info-pkg. >>> >>> I think that 1 and/or 2 are enough, and that there is no need to >>> permit (3). I agree that (3) can work, but I just think that is >>> unnecessarily confusing things. >> [JRE] I agree that (3) is an unnecessary complication. It is hard to > imagine a situation that can't be accomplished by (1) or (2) (or a > single part body, of course). In the interests of interoperability, >> limit the options where reasonable. > > Maybe I don't get it, but I really think you are making things > complicated, for no reason, and will require extra if-then-else kind of > text. The Info-Package mechanism was supposed to be simple. I'm afraid > this would just make people continue to use legacy INFO... > > In my opinon is is much easier to, in the base spec, simply say that > each body part (no matter where they are located, and no matter what C-D > value their parent may have) associated with an I-P must have C-D > 'info-package'. Why does that not work??? Lets consider an extreme case: |---B1 | | |---C1 A-|---B2-| | |---C2 | | |---D1 |---B3-| |---D2 In the above, - A is the body of an INFO message. Its multipart/mixed. - B1 is one part of A, it is not multipart - B2 and B3 are also parts of A. They are multipart/mixed. - C1 and C2 are parts of B2. - D1 and D2 are parts of B3. What you seem to say above is that it would make sense to have C2, B3, D1, and D2 be C-D info-package, while the others are something else. In that case it is very hard to imagine how C1 could have any role at all. The only way what you say seems workable is if it is a rule once you have a part with C-D of info-package then *all* subordinate parts of that must also have C-D of info-package. But why would you do that? Thanks, Paul > THEN, IF a specific Info Package requries body parts to be "collected" > inside multiparts etc, that specific Info Package specification should > say so. For example, if an Info Package can be used to send > alternative-whatever-data, the specification for that I-P should say > that the body parts must be children of a multipart/alternative parent. > Etc etc etc. > > Regards, > > Christer > > > > > > >> It does seem that there is a fundamental difference of opinion here >> that needs to be sorted out. Can some other people chime in here? >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> In the above I added "and the Content-Disposition is "render" or >>> unspecified". I wish we had specified a specific C-D for >> the top level >>> multipart that contains unrelated body parts in a sip >> message. Somehow >>> that got missed in body-handling, though it would have been >> an issue for >>> backward compatibility. >>> >>> Thanks, >>> Paul >>> >>>> NOTE: To avoid corner cases with legacy INFO usage, the >> Info-Package >>> header field is used to indicate the Info Package name, rather than >>> using a Content-Disposition header field parameter in order >> to indicate >>> the name." >>>> How does this sound? >>>> >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: 20 October 2009 21:50 >>>>> To: Christer Holmberg >>>>> Cc: Elwell, John; SIPCORE; Adam Roach; Gonzalo Camarillo; >>>>> draft-ietf-sipcore-info-events@tools.ietf.org >>>>> Subject: Re: [sipcore] WGLC comments >>>>> (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P >>>>> body parts in INFO? >>>>> >>>>> >>>>> >>>>> Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>>> It sounds like we may have different conceptions of how >> body parts >>>>>> might be strung together for this. >>>>>>> If I read your text below correctly, then it would be >>>>> possible for the >>>>>> INFO message to have a multipart mixed body, where some >>>>> body parts are >>>>>> not part of the info package (authentication stuff, geoloc >>>>>>> stuff), but where one *or more* other parts are considered >>>>> part of the >>>>>> info package. >>>>>> >>>>>> Section 4.3 talks about "SIP extensions that are orthogonal >>>>> to INFO MAY >>>>>> insert body parts unrelated to the Info Package". >>>>>> >>>>>> Personally, though, I doubt that someone would say "Hey, >> someone is >>>>>> about the send an INFO, so I'll throw in my message body >> part there >>>>>> too!". I think that any application who wants to send an >>>>> INFO (no matter >>>>>> whether it's legacy of I-P based, should trigger a >>>>> dedicated INFO, and >>>>>> not try to get a "free ride" by someone else... >>>>> The way I envision this might happen would be because of some >>>>> optional header inserted in the message that has a reference to a >>>>> body part, via a cid: url. I guess INFO can't have >> Alert-Info, but if >>>>> it could then that would be one example. >>>>> >>>>> Another example might be an AIB body. >>>>> >>>>> Most are pretty far fetched for INFO, but we should not >> exclude the >>>>> possibility. >>>>> >>>>>>> It was my thinking that there will always be *one* body >>>>> part that is >>>>>> the root of all stuff that is associated with the info >>>>> package. In the >>>>>> simplest case this would be the whole body of the message, >>>>>>> containing for example DTMF info. In a slightly more >>>>> complicated case >>>>>> it might be that same DTMF body, but as one body part in a >>>>>> multipart/mixed, where the other body parts are for >>>>> incidental purposes >>>>>>> but not part of the info package. >>>>>> Personally I agree with you, but the text has been there >> for a while >>>>>> already. If people want to remove it, though, I am happy >> to do it. >>>>> The way that C-D works means that technically you *could* have >>>>> multiple parts with C-D of info-pkg. The question is >> whether there is >>>>> any value in making it legal. If so then somebody has to >> define what >>>>> it means. >>>>> Since we have multipart which already has lots of ways to group >>>>> parts, why do we need to introduce yet another grouping mechanism >>>>> here? >>>>> >>>>>>> In cases where the info package itself needs more than one >>>>> body part, >>>>>> it would consist of a multipart containing all of its >>>>> pieces. Then that >>>>>> multipart would be just as above - either the only thing in >>>>>>> the message, or else it would be a multipart within a >>>>> multipart, along >>>>>> with other incidental parts. >>>>>> >>>>>> Just to make sure: even if we say that all body parts must >>>>> be associated >>>>>> with the Info Package, do you agree that they ALL still >>>>> shall have a C-D >>>>>> with 'info-package'? Otherwise parsers may assign whatever >>>>> the default >>>>>> C-D value is for them, and we don't want that to happen... >>>>> NO, I don't agree. >>>>> >>>>> These are nested structures. They may come from some >> other place and >>>>> be formed and processed by non-sip code that knows nothing of >>>>> info-pkg. >>>>> Once you unwrap the first box, I think you should be >> allowed to have >>>>> whatever you want inside. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>>> Your explanation sounds reasonable. I think it requires some >>>>>>> clarification in both 7.6 and 4.3: >>>>>>>> - in 7.6 it should talk about a body part, which may >> be multipart; >>>>>>> 7.6 shall definitely be changed. It should say "body parts". >>>>>>> >>>>>>> "7.6. INFO Message Body >>>>>>> >>>>>>> The Info Package specification MUST define what type of >>>>> message body >>>>>>> parts, are associated with the Info Package, and MUST refer to >>>>>>> specifications where the syntax, semantics and MIME >> type of each >>>>>>> message body part is described." >>>>>>> >>>>>>> - The old text used to say "message bodies, if any", but I >>>>> removed "if >>>>>>> any" due to the change that the Info Package shall not >> assume on >>>>>>> information being conveyed in SIP headers (see other e-mail). >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> - in 4.3 it should talk about labelling the Info-Package >>>>> body part >>>>>>>> with >>>>>>> Content-Disposition: Info-Package, this being at the SIP >>>>> level if it >>>>>>> is the sole body part (i.e., the entire body of the SIP >>>>>>>> message). >>>>>>> Yes. Basically the text shall say that each message body part >>>>>>> associated with the Info Package shall have a associated >>>>> C-D header >>>>>>> filed with an 'info-package' value. And, if there is >> only a single >>>>>>> body part in a message the SIP level C-D header field >> contains the >>>>>> 'info-package' >>>>>>> value. >>>>>>> >>>>>>> Also, 4.3 talks about "message body payloads", but I will >>>>> change to >>>>>>> "message body parts" there, to be consistent with 7.6. >>>>>>> >>>>>>> NOTE: The new 4.3 text below may also contain changes >> I've already >>>>>>> done based on other comments: >>>>>>> >>>>>>> "4.3. INFO Request Message Body >>>>>>> >>>>>>> The purpose of the INFO request is to carry application level >>>>>>> information between SIP UAs. The application data >>>>> associated with >>>>>> an >>>>>>> Info Package is carried as a payload in the message body of >>>>>>> the INFO request. >>>>>>> >>>>>>> An INFO request message body can contain a single >> body part, or >>>>>>> multiple >>>>>>> body parts (multipart/mixed). >>>>>>> >>>>>>> Info Package specifications MUST describe the >> application level >>>>>>> information associated with the Info Package. >> Message body parts >>>>>>> MUST have a MIME type value defined. >>>>>>> >>>>>>> If a UA indicates that it is willing to receive a >> specific Info >>>>>>> Package, it means that the UA also supports any >>>>> associated message >>>>>>> body MIME type associated with the Info Package. >>>>> However, the UA >>>>>>> MUST still indicate support of those MIME types also in >>>>> the Accept >>>>>>> header field, according to the procedures in [RFC3261]. >>>>>>> >>>>>>> Some SIP extensions that are orthogonal to INFO MAY >> insert body >>>>>> parts >>>>>>> unrelated to the Info Package. UAs MUST conform to >> [RFC3261] as >>>>>>> updated by body-handling >> [I-D.ietf-sip-body-handling] to support >>>>>>> multipart MIME handling. >>>>>>> >>>>>>> Each message body part associated with an Info Package MUST >>>>>>> contain a Content-Disposition header field with an >>>>> 'Info-Package' >>>>>>> value, in order to in an easy way distinguish payloads >>>>> associated >>>>>>> with the Info Package from other payloads. >>>>>>> >>>>>>> If the message body only contains a single body part, >>>>> the SIP level >>>>>>> Content-Disposition header field >>>>>>> contains an 'info-package' value. >>>>>>> >>>>>>> If the message body contains multiple body parts >>>>> (multipart/mixed) >>>>>>> the SIP level Content-Disposition header field >>>>>>> does not need to include an 'info-package' value, since >>>>> each body >>>>>>> part associated with the Info Package will include >>>>>>> a Content-Disposition header field for that specific >> body part. >>>>>>> NOTE: To avoid corner cases with legacy INFO usage, the >>>>>> Info-Package >>>>>>> header field is used to indicate the Info Package name, >>>>> rather than >>>>>>> to use a Content-Disposition header field parameter >> in order to >>>>>>> indicate the name." >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> > From pkyzivat@cisco.com Wed Oct 21 17:13:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1503A681A for ; Wed, 21 Oct 2009 17:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MORTL5nJgTV for ; Wed, 21 Oct 2009 17:13:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC3783A66B4 for ; Wed, 21 Oct 2009 17:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7658; q=dns/txt; s=rtpiport01001; t=1256170447; x=1257380047; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20(draft-ietf-sipcore-info-even ts)=20-=20Style=20of=20section=0D=0A=201=20in=20info-even ts|Date:=20Wed,=2021=20Oct=202009=2020:14:06=20-0400 |Message-ID:=20<4ADFA3CE.4010300@cisco.com>|To:=20Christe r=20Holmberg=20|CC:=20"El well,=20John"=20,=0D =0A=20=20=20=20=20=20=20=20SIPCORE=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20<7402509E63C 5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemen s.net>=20; bh=O80RQVYOf7/HsycYksLyLPyutSjWMPk63EVMod2ywTs=; b=Zgd7CH9ALeTZVJNHyVP6r6CnSL+EK4015bs63RbJktU9wT2i32Pnra5c t1Xj5tBAalCx1yXBLqDhxo1Ym/+riRoweTAHzVTJbC9EmbRKmrPJdELJ0 VtfwSTCkSENgSFogkrR0rC8BY6swTyo2ka4+Dg6pR0CLsPFMmHkg9zeuL M=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB5B30pAZnwM/2dsb2JhbADCJZhNhDME X-IronPort-AV: E=Sophos;i="4.44,600,1249257600"; d="scan'208";a="64220570" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 00:14:06 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9M0E6wK017134; Thu, 22 Oct 2009 00:14:06 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:14:06 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 20:14:05 -0400 Message-ID: <4ADFA3CE.4010300@cisco.com> Date: Wed, 21 Oct 2009 20:14:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 00:14:05.0907 (UTC) FILETIME=[914CEA30:01CA52AC] Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 00:13:59 -0000 This is good. Some specific suggestions below. Thanks, Paul Christer Holmberg wrote: > Hi, > >> Section 1 says what RFC 2976 does, says what its drawbacks are, and > then says that this document describes a mechanism that addresses those > drawbacks. It does not state that this document defines the >> INFO method. It even refers back to RFC 2976 for the definition of the > INFO method ("The purpose of the INFO message [RFC2976] is.... "). >> Yet this document supposedly obsoletes RFC 2976. >> >> I would have expected the introduction to a document that obsoletes an > earlier RFC to be self-standing and structured more like the following: >> - Introductory text very similar to what is in the obsoleted RFC, but > modified to mention anything that is significantly different. >> - A reference back to the obsoleted RFC, describing what has changed. >> >> In this particular case, the text of RFC 2976 is a rough starting > point. It even says, near the end, that the document does not specify > specific uses, so that is an ideal point to continue and talk about >> usages, Info-Packages, and indicating supported usages. >> >> We could then continue by saying that the document obsoletes RFC 2976, > which did not define the Info-Package concept and explicit indications > of which usages are supported. > > I agree that we may refer/depend a little too much on RFC 2976 - and I > think Robert commented on the same issue. It is probably some text which > was useful during the justficiation phase, but should be changes. > > Basically we should only refer to 2976 when we talk about legacy INFO > usage, and when we talk about the drawbacks of legacy INFO usage. IMO it should only be referenced informatively, not normatively. And as such it should not be necessary to reference it *at all* to build an implementation that supports legacy behavior. > Below is a re-write of the introduction, which I think addresses your > issue. > > (We could of course discuss whether 1.2 and 1.3 really should be in the > introduction, or be moved to other places in the spec.) > > "1. Introduction > > 1.1 General > > This document defines a new method, INFO, for the Session Initiation > Protocol (SIP) [RFC2976]. Why the rfc ref there? *THIS* document is the new definition of the INFO method. > In addition, it defines an Info Package mechanism. An Info Package > defines the content and semantics of the > information carried in an INFO message associated with the Info > Package. > The Info Package mechanism also provides a way for UAs to indicate > for > which types of applications and contexts they are willing to receive > INFO requests. The > document defines how the INFO method is used, new SIP header fields > for the > INFO method, and how to transport payload information associated with > an Info Package > using INFO requests. > > The purpose of the INFO message is to carry application > level information between endpoints, using the SIP session signaling > path. Note that the INFO method is not used to update > characteristics of the SIP session, but to allow the applications > which use the SIP session to exchange information. > > The Info Package mechanism does not define a separate dialog usage. > INFO messages are always part of, and share the fate of, an invite > dialog usage. INFO messages cannot be sent as part of other dialog > usages. > > If a UA supports the Info Package mechanism, it uses the Recv-Info > header field, on a per-dialog basis, to indicate for which Info > Packages > it is willing to receive INFO requests. A UA can indicate a new set > of Info > Packages at any time during the lifetime of the invite dialog usage. > A UA can use a "nil" value to indicate that it is not willing to > receive any Info Packages at a certain moment, but that the UA still > supports the Info Package mechanism. > > When a UA sends an INFO request, it uses the Info-Package header > field to indicate which Info Package is associated with the request. > One particular INFO > request can only be associated with a single Info Package. > > This document obosoletes [RFC2976]. However, for backward compability > it allows > to use INFO per [RFC2976], referred to as legacy INFO usage in the > document. However, for backward compatibility it specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC2976. > 1.2 Problems with leagcy INFO usage > > While legacy INFO usage [RFC2976] has been widely adopted for > specific > application use cases, such as ISUP and DTMF exchange, [RFC2976] does > not > not define a mechanisms for SIP UAs to indicate for which types of > applications and contexts they > support the INFO method.what usages of INFO. In addition, [RFC2976] > does not provide a mechanism to > explicitly indicate the type of application and context for which a > specific INFO message is associated to. I'm ok with the above, except that I think it should always refer to RFC2976 in the past tense, since it is obsoleted by this document. I.e. While legacy INFO usage [RFC2976] was widely adopted for specific application use cases, such as ISUP and DTMF exchange, [RFC2976] did not define a mechanism for SIP UAs to indicate which types of applications and contexts support the INFO method. In addition, [RFC2976] did not provide a mechanism to explicitly indicate the type of application and context for which a specific INFO message is associated. > In some cases it can be determined by the INFO message body payload > content, but not in a general way. > > Example: If the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. Still, there are many useful ways a UA can > render an image. The image could be a caller-id picture, a contact > icon, a photo for sharing, and so on. The sender does not know which > image to send to the receiver if the receiver supports an image > content type. Likewise, the receiver does not know the context of an > image the client is sending if the receiver supports receiving more > than one image content type. > > Due to the problems described above, legacy INFO usages often require > static configuration about for what type of applications and contexts > UAs support the INFO method, > and the way they handle application information transported in INFO > messages. > That has caused interoperability problems in the industry. > Therefore,a need for a well defined and > documented description of what the information sent in the INFO is > used for has been identified. This situation is analogous to the > context issue in > Internet Mail [RFC3458]. > > 1.3 Relationship to subscription-based event > > Event Packages [RFC3265] perform the role of disambiguating the > context of a message for subscription-based events. The Info Package > mechanism provides similar functionality for application information > exchange using invite dialog usages [RFC5057]. However, there is no > formal > relationship between the Info Package mechanism and the > subscription-based event > mechanism." > > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Oct 21 21:50:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590B03A696F for ; Wed, 21 Oct 2009 21:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JECKoScvutBl for ; Wed, 21 Oct 2009 21:50:48 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0A34C3A689D for ; Wed, 21 Oct 2009 21:50:47 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-7b-4adfe4af6738 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1A.42.24026.FA4EFDA4; Thu, 22 Oct 2009 06:50:55 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 06:49:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 06:49:43 +0200 Message-ID: In-Reply-To: <4ADF99E7.4000103@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSpqvGK+Hi2M7xTz6YLVzneref6QAK7urA References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 22 Oct 2009 04:49:44.0699 (UTC) FILETIME=[13304CB0:01CA52D3] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 04:50:49 -0000 Hi,=20 >>[JRE] But wouldn't that then conflict with the first of my=20 >>proposed sentences? The first sentence says "The body part=20 >>associated with the Info Package MUST contain a=20 >>Content-Disposition header field with value 'Info-Package'".=20 >>Your modified second sentence then seems to contradict it by=20 >>saying only in certain circumstances does it need to do this. >=20 >I think we are probably just not envisioning the same use case. >This is entangled with the debate I am having with Christer elsewhere. >I'll try a picture: >=20 >=3D=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D >| INFO ... >| C-D: info-pkg >| C-T: multipart/whatever >| (other headers) >| >=3D=3D=3D=3D INFO body start =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D=3D Part 1 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| | C-T: text/plain >| | C-D: foo >| | >| =3D=3D=3D=3D Part 1 body start =3D=3D=3D=3D=3D=3D=3D >| | some text >| =3D=3D=3D=3D Part 1 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D=3D Part 2 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| | C-T: application/bar >| | C-D: baz >| | >| =3D=3D=3D=3D Part 2 body start =3D=3D=3D=3D=3D=3D=3D >| | (application/baz stuff) >| =3D=3D=3D=3D Part 2 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >This is what my text was trying to describe. And I don't=20 >think it is in conflict with your text in the beginning of the paragraph. You are using different C-D values for the body parts associated with the Info Package. But, again, a body part associated with an Info Package shall have value 'info-package'. And, in your example above, assuming that Part 2 would NOT be part of the Info Package, HOW do you indicate that Part 1 (C-D: foo) is associated with the Info Package?=20 Regards, Christer From christer.holmberg@ericsson.com Wed Oct 21 21:59:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F0B28C0EE for ; Wed, 21 Oct 2009 21:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AWTeaL5u3W6 for ; Wed, 21 Oct 2009 21:59:03 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6053D3A689D for ; Wed, 21 Oct 2009 21:59:03 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-fd-4adfe69faf58 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 93.0F.08816.F96EFDA4; Thu, 22 Oct 2009 06:59:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 06:58:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 06:58:37 +0200 Message-ID: In-Reply-To: <4ADF9BFC.50007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSp+kb7Q4K1yLTToWRZnOH6cPaHAAK0CjQ References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 04:58:38.0350 (UTC) FILETIME=[5144FAE0:01CA52D4] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 04:59:04 -0000 Hi,=20 >IMO its not about overhead, its about layering. >Consider multiparts used in email, such as for attachments.=20 >The attachments are often understood by pieces of software=20 >independent of the email system. Yes, but where is it said that it doesn't matter what C-D value they have, since they were part of the e-mail? And, in an e-mail you don't include body parts which are not associated with the e-mail, which can happen with INFO. >Similarly here. There will be something that receives the=20 >info package body - that knows that is what it is. But if it=20 >has chosen to use multipart to consolidate a number of things=20 >into it, those might come from, and be consumed by=20 >independent software. (Considering that INFO has been used=20 >for tunneling stuff for other protocols, its really easy to=20 >imagine that.) An INFO can only contain body parts associated with ONE SINGLE Info-Package. If different parts are to end up in different software that is the task of the application associated with Info-Package. The whole idea is that the information is transparent to the SIP stack. The SIP stack only needs to know to which application to forward the body parts with C-D: info-package. =20 >The subordinate C-D values may be needed to interpret that stuff. Not by the SIP stack. If the body part is associated with the Info-Package, the application will handle it. >I think we don't have enough people in this discussion. The=20 >two of us are just not going to agree. I'd like to hear from=20 >Adam who has had a lot of insight into multipart in the past,=20 >and from Gonzallo, who wrote the body handling draft. Gonzalo is the one who pointed out the text in the body-handling RFC to me, but I guess he could give his opinion on the list also. Regards, Christer From christer.holmberg@ericsson.com Wed Oct 21 22:27:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244D33A69C0 for ; Wed, 21 Oct 2009 22:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdEAouyaj5-O for ; Wed, 21 Oct 2009 22:27:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0B38D3A68BF for ; Wed, 21 Oct 2009 22:27:12 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-e0-4adfed38e678 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7F.A3.24026.83DEFDA4; Thu, 22 Oct 2009 07:27:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 07:27:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 07:27:19 +0200 Message-ID: In-Reply-To: <4ADFA3CE.4010300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BA References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 05:27:20.0539 (UTC) FILETIME=[53C62AB0:01CA52D8] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 05:27:16 -0000 Hi,=20 >>Basically we should only refer to 2976 when we talk about legacy INFO=20 >>usage, and when we talk about the drawbacks of legacy INFO usage. >=20 >IMO it should only be referenced informatively, not=20 >normatively. And as such it should not be necessary to=20 >reference it *at all* to build an implementation that=20 >supports legacy behavior. I have removed lots of references to 2976. It is now only used when talking about legacy INFO usage. >>This document defines a new method, INFO, for the Session=20 >>Initiation Protocol (SIP) [RFC2976]. >=20 >Why the rfc ref there? *THIS* document is the new definition of the INFO method. It should be [RFC3261]. >>When a UA sends an INFO request, it uses the Info-Package header >>field to indicate which Info Package is associated with=20 >>the request. One particular INFO request can only be associated with a single Info Package. >>=20 >>This document obosoletes [RFC2976]. However, for backward compability it allows >>to use INFO per [RFC2976], referred to as legacy INFO usage in the document. >=20 >However, for backward compatibility it specifies a "legacy"=20 >mode of usage of the INFO method that is compatible with the=20 >usage previously defined in RFC2976. Looks ok. >>1.2 Problems with leagcy INFO usage >>=20 >>While legacy INFO usage [RFC2976] has been widely adopted for=20 >>specific application use cases, such as ISUP and DTMF exchange, [RFC2976]=20 >>does not not define a mechanisms for SIP UAs to indicate for=20 >>which types of applications and contexts they >>support the INFO method.what usages of INFO. In addition, [RFC2976]=20 >>does not provide a mechanism to explicitly indicate the type of application and context=20 >>for which a specific INFO message is associated to. >=20 >I'm ok with the above, except that I think it should always refer to >RFC2976 in the past tense, since it is obsoleted by this=20 >document. I agree. However, I would still prefer to say "has been widely adopted", rather than "was adopted". "was" sounds like it was done at some point, but not anymore :) -------------------------------------- New try :) I have tried to implement both Paul's and John's comments. "1. Introduction =20 1.1 General =20 This document defines a new method, INFO, for the Session=20 Initiation Protocol (SIP) [RFC3261]. The purpose of the INFO message is to carry application level information between endpoints, using the SIP session=20 signaling path. Note that the INFO method is not used to update characteristics of the SIP session, but to allow the applications which use the SIP session to exchange information (which may update the state of those applications). In addition, this document also defines an Info Package mechanism. An=20 Info Package defines the content and semantics of the iformation carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for UAs to indicate=20 for which types of applications and contexts they are willing to receive INFO requests. The document defines how the INFO method is used, new SIP header fields=20 for the INFO method, and how to transport payload information associated with an Info Package using INFO requests.=20 =20 Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of,=20 an invite dialog usage. INFO messages cannot be sent as part of=20 other dialog usages. =20 A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info=20 Packages it is willing to receive INFO requests. A UA can indicate an initial set of Info Packages during dialog=20 establishment and can indicate a new set during the lifetime of the invite dialog usage.=20 A UA can use a "nil" header field value to indicate that it is not willing to receive INFO requests associated with any Info Packages at a certain moment, but that=20 the UA still supports the Info Package mechanism. =20 When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with=20 the request. One particular INFO request can only be associated with a single Info Package. =20 This document obosoletes [RFC2976]. However, for backward compatibility it specifies a "legacy"=20 mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976],=20 referred to as "legacy INFO Usage" in this document. =20 1.2 Problems with leagcy INFO usage =20 While legacy INFO usage [RFC2976] has been widely adopted for specific application use cases, such as ISUP and DTMF exchange, [RFC2976] did not define a mechanism for SIP UAs to indicate which types of applications and contexts support the INFO method. In addition, [RFC2976] did not provide a mechanism to explicitly indicate the type of application and context for which a specific INFO message is associated.=20 Example: If the Content-Type is "image/jpeg", the MIME-attached content is a JPEG image. Still, there are many useful=20 ways a UA can render an image. The image could be a caller-id=20 picture, a contact icon, a photo for sharing, and so on. The sender does not=20 know which image to send to the receiver if the receiver supports an image content type. Likewise, the receiver does not know the context of an image the client is sending if the receiver supports=20 receiving more than one image content type. =20 Due to the problems described above, legacy INFO usages often require static configuration about for what type of applications and contexts UAs support the INFO method, and the way they handle application information=20 transported in INFO messages. That has caused interoperability problems in the industry. Therefore,a need for a well defined and documented description of what the information sent in=20 the INFO is used for has been identified. This situation is analogous to the context issue in Internet Mail [RFC3458]. =20 1.3 Relationship to subscription-based event =20 Event Packages [RFC3265] perform the role of disambiguating the context of a message for subscription-based events. The=20 Info Package mechanism provides similar functionality for application=20 information exchange using invite dialog usages [RFC5057]. However,=20 there is no formal relationship between the Info Package mechanism and the subscription-based event mechanism." Regards, Christer From john.elwell@siemens-enterprise.com Wed Oct 21 23:11:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BC73A676A for ; Wed, 21 Oct 2009 23:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.414 X-Spam-Level: X-Spam-Status: No, score=-5.414 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUKDxpwQ+Jfm for ; Wed, 21 Oct 2009 23:11:49 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 256423A67DB for ; Wed, 21 Oct 2009 23:11:48 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6Bu8B015572; Thu, 22 Oct 2009 08:11:56 +0200 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6BtCR025893; Thu, 22 Oct 2009 08:11:55 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Thu, 22 Oct 2009 08:11:55 +0200 From: "Elwell, John" To: Christer Holmberg , SIPCORE Date: Thu, 22 Oct 2009 08:11:52 +0200 Thread-Topic: WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSTQFTLWL/4JP/SFaGU9RvxSenuQAMlbqQAAGKYvAAAXRRgAAUsA6Q Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E1C@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2E13@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 06:11:51 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 21 October 2009 21:23 > To: Elwell, John; SIPCORE > Subject: RE: WGLC (draft-ietf-sipcore-info-events) - Style of=20 > section 1 in info-events >=20 >=20 > Hi, >=20 > In general I am ok with your comments, so I will implement them. >=20 > One thing, though, regarding your comment saying:=20 >=20 > "[JRE] Perhaps being rather pedantic, but shouldn't we say "A UA can > indicate an initial set of Info Packages during dialog=20 > establishment and > can indicate a new set..."?" >=20 > I don't think the UA needs to indicate anything during dialog > establishment - it can indicate the initial set also during=20 > the dialog. > Well, it does need to include Recv-Info header field during dialog > establishment, but the header value could be 'nil'. [JRE] Agreed my words don't quite capture everything. But what was missing = originally was any mention of a possibility of doing it during dialog estab= lishment. Basically we need to say that a UA can indicate an initial set of= Info Packages during dialog establishment or mid-dialog, and can also indi= cate a revised set mid-dialog. >=20 > But, it's just editorial, so I'll try to come up with something. >=20 > Regarding 1.2, the=20 > check-out-other-alternatives-before-you-define-an-I-P > of course already describes subscription-based events, so I=20 > am not sure > we need the text at all. But, I am ok with keeping it in the > introduction. >=20 > Regarding 1.3, I was thinking that it could be added to the=20 > Legacy INFO > usage section later in the document, and the introduction could simply > refer to it. But, I have no strong feelings on that. [JRE] Since I don't particularly like long Intro sections, then if you can = remove or find better homes for these sub-sections, go ahead. Of course, if= there is no 1.2 or 1.3, we shouldn't have a 1.1. John >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: 21. lokakuuta 2009 22:47 > To: Christer Holmberg; SIPCORE > Subject: RE: WGLC (draft-ietf-sipcore-info-events) - Style of=20 > section 1 > in info-events >=20 > Christer, >=20 > This seems a lot better. A few specific comments embedded. I=20 > would keep > 1.2 and 1.3 here, unless there is an obvious alternative place for one > or both of them. >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 21 October 2009 20:27 > > To: Elwell, John; SIPCORE > > Subject: WGLC (draft-ietf-sipcore-info-events) - Style of=20 > section 1 in >=20 > > info-events > >=20 > >=20 > > Hi, > >=20 > > >Section 1 says what RFC 2976 does, says what its drawbacks are, and > > then says that this document describes a mechanism that addresses=20 > > those drawbacks. It does not state that this document defines the > > >INFO method. It even refers back to RFC 2976 for the > > definition of the > > INFO method ("The purpose of the INFO message [RFC2976] is.... "). > > > > > >Yet this document supposedly obsoletes RFC 2976. > > > > > >I would have expected the introduction to a document that > > obsoletes an > > earlier RFC to be self-standing and structured more like the > > following: > > >- Introductory text very similar to what is in the=20 > obsoleted RFC, but > > modified to mention anything that is significantly different. > > >- A reference back to the obsoleted RFC, describing what=20 > has changed. > > > > > >In this particular case, the text of RFC 2976 is a rough starting > > point. It even says, near the end, that the document does=20 > not specify=20 > > specific uses, so that is an ideal point to continue and talk about > > >usages, Info-Packages, and indicating supported usages. > > > > > >We could then continue by saying that the document obsoletes > > RFC 2976, > > which did not define the Info-Package concept and explicit=20 > indications >=20 > > of which usages are supported. > >=20 > > I agree that we may refer/depend a little too much on RFC=20 > 2976 - and I >=20 > > think Robert commented on the same issue. It is probably some text=20 > > which was useful during the justficiation phase, but should be=20 > > changes. > >=20 > > Basically we should only refer to 2976 when we talk about=20 > legacy INFO=20 > > usage, and when we talk about the drawbacks of legacy INFO usage. > >=20 > > Below is a re-write of the introduction, which I think=20 > addresses your=20 > > issue. > >=20 > > (We could of course discuss whether 1.2 and 1.3 really should be in=20 > > the introduction, or be moved to other places in the spec.) > >=20 > > "1. Introduction > >=20 > > 1.1 General > >=20 > > This document defines a new method, INFO, for the Session=20 > > Initiation Protocol (SIP) [RFC2976]. > > In addition, it defines an Info Package mechanism. An=20 > Info Package=20 > > defines the content and semantics of the > > information carried in an INFO message associated with the Info=20 > > Package. > > The Info Package mechanism also provides a way for UAs=20 > to indicate=20 > > for > > which types of applications and contexts they are willing to=20 > > receive INFO requests. The > > document defines how the INFO method is used, new SIP=20 > header fields >=20 > > for the > > INFO method, and how to transport payload information associated=20 > > with an Info Package > > using INFO requests.=20 > > =20 > > The purpose of the INFO message is to carry application > > level information between endpoints, using the SIP session=20 > > signaling > > path. Note that the INFO method is not used to update > > characteristics of the SIP session, but to allow the applications > > which use the SIP session to exchange information. > [JRE] I think this ought to come earlier, after the very=20 > first sentence, > before we start talking about Info Packages. >=20 > >=20 > > The Info Package mechanism does not define a separate=20 > dialog usage. > [JRE] I would prefer "Use of the INFO method does not constitute a > separate dialog usage". >=20 > > INFO messages are always part of, and share the fate of,=20 > an invite > > dialog usage. INFO messages cannot be sent as part of=20 > other dialog > > usages. > >=20 > > If a UA supports the Info Package mechanism, it uses the=20 > Recv-Info > [JRE] Any UA supporting this RFC must support the Info Package > mechanism, so we can shorten this to "A UA uses the Recv-Info..." >=20 > > header field, on a per-dialog basis, to indicate for which Info=20 > > Packages > > it is willing to receive INFO requests. A UA can indicate a new=20 > > set of Info > > Packages at any time during the lifetime of the invite dialog=20 > > usage. > [JRE] Perhaps being rather pedantic, but shouldn't we say "A UA can > indicate an initial set of Info Packages during dialog=20 > establishment and > can indicate a new set..."? >=20 > > A UA can use a "nil" value to indicate that it is not willing to > > receive any Info Packages at a certain moment, but that=20 > > the UA still > > supports the Info Package mechanism. > >=20 > > When a UA sends an INFO request, it uses the Info-Package header > > field to indicate which Info Package is associated with=20 > > the request. > > One particular INFO > > request can only be associated with a single Info Package. > >=20 > > This document obosoletes [RFC2976]. However, for backward=20 > > compability > > it allows > > to use INFO per [RFC2976], referred to as legacy INFO=20 > usage in the > > document. > >=20 > > 1.2 Problems with leagcy INFO usage > >=20 > > While legacy INFO usage [RFC2976] has been widely adopted for > > specific > > application use cases, such as ISUP and DTMF exchange,=20 > > [RFC2976] does > > not > > not define a mechanisms for SIP UAs to indicate for=20 > which types of > > applications and contexts they > > support the INFO method.what usages of INFO. In=20 > addition, [RFC2976] > [JRE] Change "mechanisms" to "mechanism". Also I think the words "what > usages of INFO" should have been deleted. >=20 > John >=20 >=20 >=20 > > does not provide a mechanism to > > explicitly indicate the type of application and context=20 > for which a > > specific INFO message is associated to. > > In some cases it can be determined by the INFO message=20 > body payload > > content, but not in a general way. > >=20 > > Example: If the Content-Type is "image/jpeg", the MIME-attached > > content is a JPEG image. Still, there are many useful=20 > > ways a UA can > > render an image. The image could be a caller-id=20 > picture, a contact > > icon, a photo for sharing, and so on. The sender does not=20 > > know which > > image to send to the receiver if the receiver supports an image > > content type. Likewise, the receiver does not know the=20 > > context of an > > image the client is sending if the receiver supports=20 > receiving more > > than one image content type. > >=20 > > Due to the problems described above, legacy INFO usages=20 > > often require > > static configuration about for what type of applications=20 > > and contexts > > UAs support the INFO method,=20 > > and the way they handle application information=20 > transported in INFO > > messages. > > That has caused interoperability problems in the industry. > > Therefore,a need for a well defined and > > documented description of what the information sent in=20 > the INFO is > > used for has been identified. This situation is analogous to the > > context issue in > > Internet Mail [RFC3458]. > >=20 > > 1.3 Relationship to subscription-based event > >=20 > > Event Packages [RFC3265] perform the role of disambiguating the > > context of a message for subscription-based events. The=20 > > Info Package > > mechanism provides similar functionality for application=20 > > information > > exchange using invite dialog usages [RFC5057]. However,=20 > there is no > > formal > > relationship between the Info Package mechanism and the > > subscription-based event > > mechanism." > >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > = From john.elwell@siemens-enterprise.com Wed Oct 21 23:30:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95FC3A6893 for ; Wed, 21 Oct 2009 23:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xycaUTVfHPuM for ; Wed, 21 Oct 2009 23:30:10 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 43C653A6807 for ; Wed, 21 Oct 2009 23:30:09 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6UEWP028878; Thu, 22 Oct 2009 08:30:14 +0200 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6UEoA002655; Thu, 22 Oct 2009 08:30:14 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 22 Oct 2009 08:30:14 +0200 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat Date: Thu, 22 Oct 2009 08:30:11 +0200 Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BAAAJoJMA= Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 06:30:12 -0000 Christer, Looking good. Just a couple of nits below.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 22 October 2009 06:27 > To: Paul Kyzivat > Cc: Elwell, John; SIPCORE > Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events)=20 > - Style of section 1 in info-events >=20 >=20 > Hi,=20 >=20 > >>Basically we should only refer to 2976 when we talk about=20 > legacy INFO=20 > >>usage, and when we talk about the drawbacks of legacy INFO usage. > >=20 > >IMO it should only be referenced informatively, not=20 > >normatively. And as such it should not be necessary to=20 > >reference it *at all* to build an implementation that=20 > >supports legacy behavior. >=20 > I have removed lots of references to 2976. It is now only used when > talking about legacy INFO usage. >=20 > >>This document defines a new method, INFO, for the Session=20 > >>Initiation Protocol (SIP) [RFC2976]. > >=20 > >Why the rfc ref there? *THIS* document is the new definition of the > INFO method. >=20 > It should be [RFC3261]. >=20 > >>When a UA sends an INFO request, it uses the Info-Package header > >>field to indicate which Info Package is associated with=20 > >>the request. One particular INFO request can only be=20 > associated with a > single Info Package. > >>=20 > >>This document obosoletes [RFC2976]. However, for backward=20 > compability > it allows > >>to use INFO per [RFC2976], referred to as legacy INFO usage in the > document. > >=20 > >However, for backward compatibility it specifies a "legacy"=20 > >mode of usage of the INFO method that is compatible with the=20 > >usage previously defined in RFC2976. >=20 > Looks ok. >=20 > >>1.2 Problems with leagcy INFO usage > >>=20 > >>While legacy INFO usage [RFC2976] has been widely adopted for=20 > >>specific application use cases, such as ISUP and DTMF exchange, > [RFC2976]=20 > >>does not not define a mechanisms for SIP UAs to indicate for=20 > >>which types of applications and contexts they > >>support the INFO method.what usages of INFO. In addition, [RFC2976]=20 > >>does not provide a mechanism to explicitly indicate the type of > application and context=20 > >>for which a specific INFO message is associated to. > >=20 > >I'm ok with the above, except that I think it should always refer to > >RFC2976 in the past tense, since it is obsoleted by this=20 > >document. >=20 > I agree. However, I would still prefer to say "has been=20 > widely adopted", > rather than "was adopted". >=20 > "was" sounds like it was done at some point, but not anymore :) >=20 > -------------------------------------- >=20 > New try :) I have tried to implement both Paul's and John's comments. >=20 > "1. Introduction > =20 > 1.1 General > =20 > This document defines a new method, INFO, for the Session=20 > Initiation Protocol (SIP) [RFC3261]. >=20 > The purpose of the INFO message is to carry application > level information between endpoints, using the SIP session=20 > signaling path. Note that the INFO method is not used to update > characteristics of the SIP session, but to allow the applications > which use the SIP session to exchange information (which may > update the state of those applications). >=20 > In addition, this document also defines an Info Package mechanism. An=20 > Info Package defines the content and semantics of the > iformation carried in an INFO message associated with the=20 > Info Package. [JRE] I would change "associated with the INFO package" (which is a little = bit circular) to "for a particular usage". > The Info Package mechanism also provides a way for UAs to indicate=20 > for which types of applications and contexts they are willing=20 > to receive > INFO requests. The > document defines how the INFO method is used, new SIP header fields=20 > for the INFO method, and how to transport payload information=20 > associated with an Info Package using INFO requests.=20 [JRE] Change "The document" to "This document". And since the sentence is n= ot specifically talking about the Info Package mechanism, it should be prec= eded by a paragraph break. John > =20 > Use of the INFO method does not constitute a separate dialog usage. > INFO messages are always part of, and share the fate of,=20 > an invite dialog usage. INFO messages cannot be sent as part of=20 > other dialog usages. > =20 > A UA uses the Recv-Info header field, on a per-dialog basis,=20 > to indicate > for which Info=20 > Packages it is willing to receive INFO requests. A UA can indicate an > initial set of Info Packages during dialog=20 > establishment and can indicate a new set during the lifetime of the > invite dialog usage.=20 >=20 > A UA can use a "nil" header field value to indicate that it is not > willing to > receive INFO requests associated with any Info Packages at a certain > moment, but that=20 > the UA still supports the Info Package mechanism. > =20 > When a UA sends an INFO request, it uses the Info-Package header > field to indicate which Info Package is associated with=20 > the request. One particular INFO request can only be associated with a > single Info Package. > =20 > This document obosoletes [RFC2976]. However, for backward=20 > compatibility > it specifies a "legacy"=20 > mode of usage of the INFO method that is compatible with the usage > previously defined in [RFC2976],=20 > referred to as "legacy INFO Usage" in this document. > =20 > 1.2 Problems with leagcy INFO usage > =20 > While legacy INFO usage [RFC2976] has been widely adopted for specific > application use cases, such as ISUP and DTMF exchange, [RFC2976] did > not define a mechanism for SIP UAs to indicate which types of > applications and contexts support the INFO method. In addition, > [RFC2976] did not provide a mechanism to explicitly indicate the type > of application and context for which a specific INFO message is > associated.=20 >=20 > Example: If the Content-Type is "image/jpeg", the MIME-attached > content is a JPEG image. Still, there are many useful=20 > ways a UA can render an image. The image could be a caller-id=20 > picture, a contact icon, a photo for sharing, and so on. The sender > does not=20 > know which image to send to the receiver if the receiver supports an > image > content type. Likewise, the receiver does not know the context of an > image the client is sending if the receiver supports=20 > receiving more than one image content type. > =20 > Due to the problems described above, legacy INFO usages often require > static configuration about for what type of applications and contexts > UAs support the INFO method, and the way they handle application > information=20 > transported in INFO messages. > That has caused interoperability problems in the industry. > Therefore,a need for a well defined and documented description of what > the information sent in=20 > the INFO is used for has been identified. This situation is=20 > analogous to > the > context issue in Internet Mail [RFC3458]. > =20 > 1.3 Relationship to subscription-based event > =20 > Event Packages [RFC3265] perform the role of disambiguating the > context of a message for subscription-based events. The=20 > Info Package mechanism provides similar functionality for application=20 > information exchange using invite dialog usages [RFC5057]. However,=20 > there is no formal relationship between the Info Package mechanism and > the > subscription-based event mechanism." >=20 > Regards, >=20 > Christer >=20 > = From john.elwell@siemens-enterprise.com Wed Oct 21 23:42:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A7128C11A for ; Wed, 21 Oct 2009 23:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH3XjkRSDSxY for ; Wed, 21 Oct 2009 23:42:42 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id B387028C0DB for ; Wed, 21 Oct 2009 23:42:41 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6gNp3008572; Thu, 22 Oct 2009 08:42:23 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M6gNjx013615; Thu, 22 Oct 2009 08:42:23 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Thu, 22 Oct 2009 08:42:22 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Thu, 22 Oct 2009 08:42:21 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpSpqrYymsifG3cT0moa8xKCbCt/QAO03iQ Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E1F@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> In-Reply-To: <4ADF99E7.4000103@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 06:42:43 -0000 Paul, Yes, we were talking at cross purposes, and I realise now there was some am= biguity in my original text proposal. Anyway, let's get the big issue betwe= en you and Christer resolved before we go back to word smithing. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 22 October 2009 00:32 > To: Elwell, John > Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo=20 > Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body parts in INFO? >=20 >=20 >=20 > Elwell, John wrote: > > =20 > >=20 > >> -----Original Message----- > [snip] > >>> The body part associated with the Info Package MUST contain=20 > >> a Content-Disposition header field with value 'Info-Package',=20 > >> in order easily to distinguish payloads associated with the=20 > >> Info Package from other payloads. If the message body only=20 > >> contains the single body part associated with the=20 > >> Info-Package, the SIP level Content-Disposition header field=20 > >> MUST contain value 'Info-Package'. If the message body is of=20 > >> type multipart/mixed, the child body part associated with the=20 > >> Info-Package MUST include a Content-Disposition header field=20 > >> with value 'Info-Package'. Child body parts of a=20 > >> multipart/mixed body part associated with the Info-Package do=20 > >> not require this Content-Disposition value. > >> > >> Some slight rewording suggestions: > >> > >> ... > >> If the message body is of type multipart/mixed, > >> * and the Content-Disposition is "render" or unspecified, > >> the child body part associated with the Info-Package=20 > MUST include a > >> Content-Disposition header field with value=20 > >> 'Info-Package'. Child body > >> * parts of a multipart body part associated with the=20 > >> Info-Package do not > >> * ^^^^^^^^^^ > >> require this Content-Disposition value. > >> > >> In the above I added "and the Content-Disposition is "render" or=20 > >> unspecified".=20 > > [JRE] But wouldn't that then conflict with the first of my=20 > proposed sentences? The first sentence says "The body part=20 > associated with the Info Package MUST contain a=20 > Content-Disposition header field with value 'Info-Package'".=20 > Your modified second sentence then seems to contradict it by=20 > saying only in certain circumstances does it need to do this. >=20 > I think we are probably just not envisioning the same use case. > This is entangled with the debate I am having with Christer elsewhere. > I'll try a picture: >=20 > =3D=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D > | INFO ... > | C-D: info-pkg > | C-T: multipart/whatever > | (other headers) > | > =3D=3D=3D=3D INFO body start =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | =3D=3D=3D=3D Part 1 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | C-T: text/plain > | | C-D: foo > | | > | =3D=3D=3D=3D Part 1 body start =3D=3D=3D=3D=3D=3D=3D > | | some text > | =3D=3D=3D=3D Part 1 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | =3D=3D=3D=3D Part 2 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | | C-T: application/bar > | | C-D: baz > | | > | =3D=3D=3D=3D Part 2 body start =3D=3D=3D=3D=3D=3D=3D > | | (application/baz stuff) > | =3D=3D=3D=3D Part 2 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D INFO end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > This is what my text was trying to describe. And I don't=20 > think it is in=20 > conflict with your text in the beginning of the paragraph. >=20 > Thanks, > Paul > = From christer.holmberg@ericsson.com Thu Oct 22 00:18:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F374F3A68E8 for ; Thu, 22 Oct 2009 00:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZhq2IZkABbM for ; Thu, 22 Oct 2009 00:18:13 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF2313A67D4 for ; Thu, 22 Oct 2009 00:18:12 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-85-4ae0071bacb7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FE.1B.24026.A1700EA4; Thu, 22 Oct 2009 09:17:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:17:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 09:17:45 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BAAAJoJMAAAdLOkA== References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 07:17:46.0261 (UTC) FILETIME=[C1031C50:01CA52E7] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:18:14 -0000 Hi,=20 >>In addition, this document also defines an Info Package mechanism. An=20 >>Info Package defines the content and semantics of the information=20 >>carried in an INFO message associated with the Info Package. >[JRE] I would change "associated with the INFO package"=20 >(which is a little bit circular) to "for a particular usage". I think the "associated with" wording is used elsewhere in the document also, so I would prefer to keep it. And, I thought we wanted go get rid of the "usage" wording with INFO, unless We talk about legacy INFO usage. I will implement the rest of you comments. Regards, Christer From john.elwell@siemens-enterprise.com Thu Oct 22 00:28:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AD73A6893 for ; Thu, 22 Oct 2009 00:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2i6GvVsMVQR for ; Thu, 22 Oct 2009 00:28:45 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 78C5B3A67D4 for ; Thu, 22 Oct 2009 00:28:44 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M7Sn0w029545; Thu, 22 Oct 2009 09:28:49 +0200 Received: from DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9M7SnE5031143; Thu, 22 Oct 2009 09:28:49 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Thu, 22 Oct 2009 09:28:49 +0200 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat Date: Thu, 22 Oct 2009 09:28:47 +0200 Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BAAAJoJMAAAdLOkAAAMaVg Message-ID: <7402509E63C5A145A6095D46C179A5B7148B2E29@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:28:46 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 22 October 2009 08:18 > To: Elwell, John; Paul Kyzivat > Cc: SIPCORE > Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events)=20 > - Style of section 1 in info-events >=20 >=20 > Hi,=20 >=20 > >>In addition, this document also defines an Info Package=20 > mechanism. An=20 > >>Info Package defines the content and semantics of the information=20 > >>carried in an INFO message associated with the Info Package. > >[JRE] I would change "associated with the INFO package"=20 > >(which is a little bit circular) to "for a particular usage". >=20 > I think the "associated with" wording is used elsewhere in=20 > the document > also, so I would prefer to keep it. [JRE] I still think your text proposal is circular: "Info package defines .= ...associated with the Info Package". The was the main point of my comment.= Perhaps circular is a little unfair. However, I do think it is worth sayin= g that the data is for a particular purpose (i.e., for some usage or applic= ation) - the Info Package is only a means to an end. If you want to keep "a= ssociated with" and don't want to use the word "usage", I would say "...ass= ociated with a given application". >=20 > And, I thought we wanted go get rid of the "usage" wording with INFO, > unless > We talk about legacy INFO usage. [JRE] That was not the point I was making earlier. I am comfortable with an= Info package defining a usage, but there was some text somewhere that used= usage in some other context, and that was what I was concerned about. I think we are getting to the point where we need a new draft, which presum= ably you intend to do before the cut-off (despite the hard time Paul and I = are giving you). John >=20 > I will implement the rest of you comments. >=20 > Regards, >=20 > Christer >=20 > = From christer.holmberg@ericsson.com Thu Oct 22 00:33:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148513A6905 for ; Thu, 22 Oct 2009 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOYG4IEIhkmG for ; Thu, 22 Oct 2009 00:33:38 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id CFBC93A681D for ; Thu, 22 Oct 2009 00:33:36 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-b5-4ae00ad90970 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 34.B7.08816.9DA00EA4; Thu, 22 Oct 2009 09:33:45 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:33:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 09:33:43 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E29@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BAAAJoJMAAAdLOkAAAMaVgAABtRYA= References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2E29@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 07:33:45.0154 (UTC) FILETIME=[FC8E9220:01CA52E9] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 07:33:39 -0000 Hi, Yes, my intention is to submit a new draft very soon - maybe already today. Regards, Christer > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: 22. lokakuuta 2009 10:29 > To: Christer Holmberg; Paul Kyzivat > Cc: SIPCORE > Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events)=20 > - Style of section 1 in info-events >=20 > =20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: 22 October 2009 08:18 > > To: Elwell, John; Paul Kyzivat > > Cc: SIPCORE > > Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events) > > - Style of section 1 in info-events > >=20 > >=20 > > Hi, > >=20 > > >>In addition, this document also defines an Info Package > > mechanism. An > > >>Info Package defines the content and semantics of the information=20 > > >>carried in an INFO message associated with the Info Package. > > >[JRE] I would change "associated with the INFO package"=20 > > >(which is a little bit circular) to "for a particular usage". > >=20 > > I think the "associated with" wording is used elsewhere in the=20 > > document also, so I would prefer to keep it. > [JRE] I still think your text proposal is circular: "Info=20 > package defines ....associated with the Info Package". The=20 > was the main point of my comment. Perhaps circular is a=20 > little unfair. However, I do think it is worth saying that=20 > the data is for a particular purpose (i.e., for some usage or=20 > application) - the Info Package is only a means to an end. If=20 > you want to keep "associated with" and don't want to use the=20 > word "usage", I would say "...associated with a given application". >=20 > >=20 > > And, I thought we wanted go get rid of the "usage" wording=20 > with INFO,=20 > > unless We talk about legacy INFO usage. > [JRE] That was not the point I was making earlier. I am=20 > comfortable with an Info package defining a usage, but there=20 > was some text somewhere that used usage in some other=20 > context, and that was what I was concerned about. >=20 > I think we are getting to the point where we need a new=20 > draft, which presumably you intend to do before the cut-off=20 > (despite the hard time Paul and I are giving you). >=20 > John >=20 >=20 > >=20 > > I will implement the rest of you comments. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Thu Oct 22 01:07:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9480A3A68E8 for ; Thu, 22 Oct 2009 01:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4yOIRNcsz+g for ; Thu, 22 Oct 2009 01:07:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 930983A68A2 for ; Thu, 22 Oct 2009 01:07:18 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b0-4ae012be6921 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 57.70.24026.EB210EA4; Thu, 22 Oct 2009 10:07:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:07:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 10:07:25 +0200 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E29@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpSrJLvYALjvDi5RECRk8KxqVjAogAKb6BAAAJoJMAAAdLOkAAAMaVgAAGhYpA= References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2E29@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 08:07:26.0574 (UTC) FILETIME=[B16AC8E0:01CA52EE] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 08:07:20 -0000 =20 Hi, >>I think the "associated with" wording is used elsewhere in the=20 >>document also, so I would prefer to keep it. >[JRE] I still think your text proposal is circular: "Info=20 >package defines ....associated with the Info Package". The=20 >was the main point of my comment. Perhaps circular is a=20 >little unfair. However, I do think it is worth saying that=20 >the data is for a particular purpose (i.e., for some usage or=20 >application) - the Info Package is only a means to an end. If=20 >you want to keep "associated with" and don't want to use the=20 >word "usage", I would say "...associated with a given application". What about: "The Info Package SPECIFICAITION defines defines the content blah blah blah associated with the Info Package". Regards, Christer From pkyzivat@cisco.com Thu Oct 22 06:30:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7283A6823 for ; Thu, 22 Oct 2009 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9apPptzu61HA for ; Thu, 22 Oct 2009 06:30:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0D0873A67E1 for ; Thu, 22 Oct 2009 06:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2534; q=dns/txt; s=rtpiport02001; t=1256218254; x=1257427854; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2009:30:52=20-0400|Message-ID:=20<4AE05E8C. 8050709@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20draft-ietf-sipcore-info-events@tools.ietf. org|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20=20<4ADE227C.5020500@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20<7 402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww 902.siemens.net>=20<4ADF99E7.4000103@cisco.com>=20; bh=Gxpkr4QddwLanMXTCwo8wkJHztRqGe7i2lppW4mhYRE=; b=lh3vEl9ihgIKbIsREmodT2O7lSs38sO2mlF0ke2F6UZbNH6uLkBRbHbR UFoeu41F3fSuQ45m4UMGlMZddQqaWj6E1lZfevYHgSxxmQDSCqzev/SW2 02WI1VhYCDWuCLfbcf+WSz73QMNPcbtFcnHplaxtqUl/+i9Im5d1d1XXX w=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK7730pAZnwM/2dsb2JhbADCXZhjhD8E X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="64378423" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2009 13:30:53 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MDUrOk027123; Thu, 22 Oct 2009 13:30:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:30:53 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:30:52 -0400 Message-ID: <4AE05E8C.8050709@cisco.com> Date: Thu, 22 Oct 2009 09:30:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 13:30:52.0752 (UTC) FILETIME=[E0668D00:01CA531B] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:30:47 -0000 Christer Holmberg wrote: > Hi, > >>> [JRE] But wouldn't that then conflict with the first of my >>> proposed sentences? The first sentence says "The body part >>> associated with the Info Package MUST contain a >>> Content-Disposition header field with value 'Info-Package'". >>> Your modified second sentence then seems to contradict it by >>> saying only in certain circumstances does it need to do this. >> I think we are probably just not envisioning the same use case. >> This is entangled with the debate I am having with Christer elsewhere. >> I'll try a picture: >> >> ==== INFO message headers ====== >> | INFO ... >> | C-D: info-pkg >> | C-T: multipart/whatever >> | (other headers) >> | >> ==== INFO body start =========== >> | ==== Part 1 headers ========== >> | | C-T: text/plain >> | | C-D: foo >> | | >> | ==== Part 1 body start ======= >> | | some text >> | ==== Part 1 end ============== >> | ==== Part 2 headers ========== >> | | C-T: application/bar >> | | C-D: baz >> | | >> | ==== Part 2 body start ======= >> | | (application/baz stuff) >> | ==== Part 2 end ============== >> ==== INFO end ================== >> >> This is what my text was trying to describe. And I don't >> think it is in conflict with your text in the beginning of the > paragraph. > > You are using different C-D values for the body parts associated with > the Info Package. > > But, again, a body part associated with an Info Package shall have value > 'info-package'. You keep repeated the last sentence above as a mantra, as if it was cast in stone. But we are discussing what is supposed to be written on the stone. And in any case, in the above it is the body part with C-D of info-package that is associated with the info package. > And, in your example above, assuming that Part 2 would NOT be part of > the Info Package, HOW do you indicate that Part 1 (C-D: foo) is > associated with the Info Package? Wrong assumption. *My* assumption is that once a body/body part is associated with the info package, then *all the bits it contains* including any nested body parts, are transitively also associated with the info package. Its a tree. If I own a branch, then I own all the descendents of that branch. If I saw it off and take it somewhere, I take the whole thing. I don't just take away my immediate branch and leave some of its children behind floating in the air around the tree. Thanks, Paul > Regards, > > Christer > > From pkyzivat@cisco.com Thu Oct 22 06:41:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A3C28C151 for ; Thu, 22 Oct 2009 06:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSVf-xoOLqeP for ; Thu, 22 Oct 2009 06:41:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9834628C14E for ; Thu, 22 Oct 2009 06:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=7958; q=dns/txt; s=rtpiport02001; t=1256218887; x=1257428487; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20(draft-ietf-sipcore-info-even ts)=20-=20Style=20of=20section=0D=0A=201=20in=20info-even ts|Date:=20Thu,=2022=20Oct=202009=2009:41:20=20-0400 |Message-ID:=20<4AE06100.4080604@cisco.com>|To:=20"Elwell ,=20John"=20|CC:=20Ch rister=20Holmberg=20,=0D =0A=20=20=20=20=20=20=20=20SIPCORE=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<7402509E63C5A145A6095D46C179A5B7148B2E1D @DEMCHP99E35MSX.ww902.siemens.net>|References:=20<7402509 E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.si emens.net>=20=20<4ADFA3CE.4010300@cisco.com >=20=20<7402509E63C5A145A6095D46C179A5B7148 B2E1D@DEMCHP99E35MSX.ww902.siemens.net>; bh=MIKjPW0a/4MCJWUh6K2nN1GC8c9ylq2AdQl2jJyCTW8=; b=F26hx/BYUU6mGANkkanAksFMv4dGMnsh40YJezpUV74Ucep8TV3iC8k0 tu8dKRyAlgBx5vYFtimAdIXVoBYEp+nBOpcaZFpM/AFvDUmhWpxRlHO/b bDKgdBPMj6/ckVnQNzVv9/tG1AMVQ/wv988GRLvVgUgd22oWcGIoVGZs6 o=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAv+30pAZnwN/2dsb2JhbADCUphjhD8E X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="64382045" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2009 13:41:26 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MDfL8C026145; Thu, 22 Oct 2009 13:41:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:41:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:41:21 -0400 Message-ID: <4AE06100.4080604@cisco.com> Date: Thu, 22 Oct 2009 09:41:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 13:41:21.0041 (UTC) FILETIME=[56E3D810:01CA531D] Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:41:19 -0000 I like the new wording. I also support the change John proposes here. I didn't pick up on it myself, but since John pointed it out I agree that the circularity is problematic, and his wording fixes it. Thanks, Paul Regarding "associated with", on other threads we seem to be having trouble with that. Elwell, John wrote: > Christer, > > Looking good. Just a couple of nits below. > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 22 October 2009 06:27 >> To: Paul Kyzivat >> Cc: Elwell, John; SIPCORE >> Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events) >> - Style of section 1 in info-events >> >> >> Hi, >> >>>> Basically we should only refer to 2976 when we talk about >> legacy INFO >>>> usage, and when we talk about the drawbacks of legacy INFO usage. >>> IMO it should only be referenced informatively, not >>> normatively. And as such it should not be necessary to >>> reference it *at all* to build an implementation that >>> supports legacy behavior. >> I have removed lots of references to 2976. It is now only used when >> talking about legacy INFO usage. >> >>>> This document defines a new method, INFO, for the Session >>>> Initiation Protocol (SIP) [RFC2976]. >>> Why the rfc ref there? *THIS* document is the new definition of the >> INFO method. >> >> It should be [RFC3261]. >> >>>> When a UA sends an INFO request, it uses the Info-Package header >>>> field to indicate which Info Package is associated with >>>> the request. One particular INFO request can only be >> associated with a >> single Info Package. >>>> This document obosoletes [RFC2976]. However, for backward >> compability >> it allows >>>> to use INFO per [RFC2976], referred to as legacy INFO usage in the >> document. >>> However, for backward compatibility it specifies a "legacy" >>> mode of usage of the INFO method that is compatible with the >>> usage previously defined in RFC2976. >> Looks ok. >> >>>> 1.2 Problems with leagcy INFO usage >>>> >>>> While legacy INFO usage [RFC2976] has been widely adopted for >>>> specific application use cases, such as ISUP and DTMF exchange, >> [RFC2976] >>>> does not not define a mechanisms for SIP UAs to indicate for >>>> which types of applications and contexts they >>>> support the INFO method.what usages of INFO. In addition, [RFC2976] >>>> does not provide a mechanism to explicitly indicate the type of >> application and context >>>> for which a specific INFO message is associated to. >>> I'm ok with the above, except that I think it should always refer to >>> RFC2976 in the past tense, since it is obsoleted by this >>> document. >> I agree. However, I would still prefer to say "has been >> widely adopted", >> rather than "was adopted". >> >> "was" sounds like it was done at some point, but not anymore :) >> >> -------------------------------------- >> >> New try :) I have tried to implement both Paul's and John's comments. >> >> "1. Introduction >> >> 1.1 General >> >> This document defines a new method, INFO, for the Session >> Initiation Protocol (SIP) [RFC3261]. >> >> The purpose of the INFO message is to carry application >> level information between endpoints, using the SIP session >> signaling path. Note that the INFO method is not used to update >> characteristics of the SIP session, but to allow the applications >> which use the SIP session to exchange information (which may >> update the state of those applications). >> >> In addition, this document also defines an Info Package mechanism. An >> Info Package defines the content and semantics of the >> iformation carried in an INFO message associated with the >> Info Package. > [JRE] I would change "associated with the INFO package" (which is a little bit circular) to "for a particular usage". > >> The Info Package mechanism also provides a way for UAs to indicate >> for which types of applications and contexts they are willing >> to receive >> INFO requests. The >> document defines how the INFO method is used, new SIP header fields >> for the INFO method, and how to transport payload information >> associated with an Info Package using INFO requests. > [JRE] Change "The document" to "This document". And since the sentence is not specifically talking about the Info Package mechanism, it should be preceded by a paragraph break. > > John > >> >> Use of the INFO method does not constitute a separate dialog usage. >> INFO messages are always part of, and share the fate of, >> an invite dialog usage. INFO messages cannot be sent as part of >> other dialog usages. >> >> A UA uses the Recv-Info header field, on a per-dialog basis, >> to indicate >> for which Info >> Packages it is willing to receive INFO requests. A UA can indicate an >> initial set of Info Packages during dialog >> establishment and can indicate a new set during the lifetime of the >> invite dialog usage. >> >> A UA can use a "nil" header field value to indicate that it is not >> willing to >> receive INFO requests associated with any Info Packages at a certain >> moment, but that >> the UA still supports the Info Package mechanism. >> >> When a UA sends an INFO request, it uses the Info-Package header >> field to indicate which Info Package is associated with >> the request. One particular INFO request can only be associated with a >> single Info Package. >> >> This document obosoletes [RFC2976]. However, for backward >> compatibility >> it specifies a "legacy" >> mode of usage of the INFO method that is compatible with the usage >> previously defined in [RFC2976], >> referred to as "legacy INFO Usage" in this document. >> >> 1.2 Problems with leagcy INFO usage >> >> While legacy INFO usage [RFC2976] has been widely adopted for specific >> application use cases, such as ISUP and DTMF exchange, [RFC2976] did >> not define a mechanism for SIP UAs to indicate which types of >> applications and contexts support the INFO method. In addition, >> [RFC2976] did not provide a mechanism to explicitly indicate the type >> of application and context for which a specific INFO message is >> associated. >> >> Example: If the Content-Type is "image/jpeg", the MIME-attached >> content is a JPEG image. Still, there are many useful >> ways a UA can render an image. The image could be a caller-id >> picture, a contact icon, a photo for sharing, and so on. The sender >> does not >> know which image to send to the receiver if the receiver supports an >> image >> content type. Likewise, the receiver does not know the context of an >> image the client is sending if the receiver supports >> receiving more than one image content type. >> >> Due to the problems described above, legacy INFO usages often require >> static configuration about for what type of applications and contexts >> UAs support the INFO method, and the way they handle application >> information >> transported in INFO messages. >> That has caused interoperability problems in the industry. >> Therefore,a need for a well defined and documented description of what >> the information sent in >> the INFO is used for has been identified. This situation is >> analogous to >> the >> context issue in Internet Mail [RFC3458]. >> >> 1.3 Relationship to subscription-based event >> >> Event Packages [RFC3265] perform the role of disambiguating the >> context of a message for subscription-based events. The >> Info Package mechanism provides similar functionality for application >> information exchange using invite dialog usages [RFC5057]. However, >> there is no formal relationship between the Info Package mechanism and >> the >> subscription-based event mechanism." >> >> Regards, >> >> Christer >> >> From pkyzivat@cisco.com Thu Oct 22 06:45:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2DA63A696D for ; Thu, 22 Oct 2009 06:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrBPn3CZ3+5H for ; Thu, 22 Oct 2009 06:45:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 594013A6855 for ; Thu, 22 Oct 2009 06:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3733; q=dns/txt; s=rtpiport01001; t=1256219144; x=1257428744; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2009:45:42=20-0400|Message-ID:=20<4AE06206. 7070206@cisco.com>|To:=20"Elwell,=20John"=20|CC:=20Christer=20Holmberg=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20"draft-ietf-sipcore-info-events@tools.ietf .org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<7402509E63C5A145A6095D46C179A5B7148B2E1F @DEMCHP99E35MSX.ww902.siemens.net>|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP 99E35MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com >=20<7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35 MSX.ww902.siemens.net>=20=20<4ADE168F.70603 03@cisco.com>=20=20<4ADE227C.5020500@cisco. com>=20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99 E35MSX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF99E7.4000103@cisco.com>=20<7 402509E63C5A145A6095D46C179A5B7148B2E1F@DEMCHP99E35MSX.ww 902.siemens.net>; bh=vU3Cnu+Tx99DRBWocAusuEKpHUxLgKoBfeqw4VaWT34=; b=mGZw7i+77bGsEJfxcOepb11owmGwdYpde9yS8BC+fu2phLFsB1zbE5DW Mds2ktAi8SsdmlO7CAxO2KQSZ49Sm1rzSFGqipr34vWInPcb7/psF4b53 ocb8Oo5zFzgbjLEGDwBonpQ25YeyQSJHAAU8sxZbErOV5bdGFVDx7PpmQ w=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPb+30pAZnwM/2dsb2JhbADCYZhjhD8E X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="64351417" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 13:45:43 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MDjhnj011084; Thu, 22 Oct 2009 13:45:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:45:43 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 09:45:42 -0400 Message-ID: <4AE06206.7070206@cisco.com> Date: Thu, 22 Oct 2009 09:45:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1F@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2E1F@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 13:45:43.0011 (UTC) FILETIME=[F3094B30:01CA531D] Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:45:35 -0000 Elwell, John wrote: > Paul, > > Yes, we were talking at cross purposes, and I realise now there was some ambiguity in my original text proposal. Anyway, let's get the big issue between you and Christer resolved before we go back to word smithing. Then if we now have a common basis for discussion, what is your thinking on the debate Christer and I are having? I think it is actually quite fundamental in how one approaches implementing this, or implementing multipart support in general. Thanks, Paul > John > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 22 October 2009 00:32 >> To: Elwell, John >> Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo >> Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org >> Subject: Re: [sipcore] WGLC comments >> (draft-ietf-sipcore-info-events-01) - John E's comments - >> non-I-P body parts in INFO? >> >> >> >> Elwell, John wrote: >>> >>> >>>> -----Original Message----- >> [snip] >>>>> The body part associated with the Info Package MUST contain >>>> a Content-Disposition header field with value 'Info-Package', >>>> in order easily to distinguish payloads associated with the >>>> Info Package from other payloads. If the message body only >>>> contains the single body part associated with the >>>> Info-Package, the SIP level Content-Disposition header field >>>> MUST contain value 'Info-Package'. If the message body is of >>>> type multipart/mixed, the child body part associated with the >>>> Info-Package MUST include a Content-Disposition header field >>>> with value 'Info-Package'. Child body parts of a >>>> multipart/mixed body part associated with the Info-Package do >>>> not require this Content-Disposition value. >>>> >>>> Some slight rewording suggestions: >>>> >>>> ... >>>> If the message body is of type multipart/mixed, >>>> * and the Content-Disposition is "render" or unspecified, >>>> the child body part associated with the Info-Package >> MUST include a >>>> Content-Disposition header field with value >>>> 'Info-Package'. Child body >>>> * parts of a multipart body part associated with the >>>> Info-Package do not >>>> * ^^^^^^^^^^ >>>> require this Content-Disposition value. >>>> >>>> In the above I added "and the Content-Disposition is "render" or >>>> unspecified". >>> [JRE] But wouldn't that then conflict with the first of my >> proposed sentences? The first sentence says "The body part >> associated with the Info Package MUST contain a >> Content-Disposition header field with value 'Info-Package'". >> Your modified second sentence then seems to contradict it by >> saying only in certain circumstances does it need to do this. >> >> I think we are probably just not envisioning the same use case. >> This is entangled with the debate I am having with Christer elsewhere. >> I'll try a picture: >> >> ==== INFO message headers ====== >> | INFO ... >> | C-D: info-pkg >> | C-T: multipart/whatever >> | (other headers) >> | >> ==== INFO body start =========== >> | ==== Part 1 headers ========== >> | | C-T: text/plain >> | | C-D: foo >> | | >> | ==== Part 1 body start ======= >> | | some text >> | ==== Part 1 end ============== >> | ==== Part 2 headers ========== >> | | C-T: application/bar >> | | C-D: baz >> | | >> | ==== Part 2 body start ======= >> | | (application/baz stuff) >> | ==== Part 2 end ============== >> ==== INFO end ================== >> >> This is what my text was trying to describe. And I don't >> think it is in >> conflict with your text in the beginning of the paragraph. >> >> Thanks, >> Paul >> From christer.holmberg@ericsson.com Thu Oct 22 06:46:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31953A69C6 for ; Thu, 22 Oct 2009 06:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mH6MrP4qzcv for ; Thu, 22 Oct 2009 06:46:49 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5FAFE3A6910 for ; Thu, 22 Oct 2009 06:46:49 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-0f-4ae06251fbb7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 2F.09.04191.15260EA4; Thu, 22 Oct 2009 15:46:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 15:46:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 15:46:56 +0200 Message-ID: In-Reply-To: <4AE05E8C.8050709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTG+dt5xHP5EsLSNqe5d80PvbFXAAAFDUw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 13:46:56.0935 (UTC) FILETIME=[1F193370:01CA531E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 13:46:50 -0000 Hi,=20 =20 >>>>[JRE] But wouldn't that then conflict with the first of my proposed=20 >>>>sentences? The first sentence says "The body part associated with=20 >>>>the Info Package MUST contain a Content-Disposition header field=20 >>>>with value 'Info-Package'". >>>>Your modified second sentence then seems to contradict it by saying=20 >>>>only in certain circumstances does it need to do this. >>>I think we are probably just not envisioning the same use case. >>> This is entangled with the debate I am having with=20 >Christer elsewhere. >>> I'll try a picture: >>> >>> =3D=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D >>> | INFO ... >>> | C-D: info-pkg >>> | C-T: multipart/whatever >>> | (other headers) >>> | >>> =3D=3D=3D=3D INFO body start =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | =3D=3D=3D=3D Part 1 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | | C-T: text/plain >>> | | C-D: foo >>> | | >>> | =3D=3D=3D=3D Part 1 body start =3D=3D=3D=3D=3D=3D=3D >>> | | some text >>> | =3D=3D=3D=3D Part 1 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | =3D=3D=3D=3D Part 2 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> | | C-T: application/bar >>> | | C-D: baz >>> | | >>> | =3D=3D=3D=3D Part 2 body start =3D=3D=3D=3D=3D=3D=3D >>> | | (application/baz stuff) >>> | =3D=3D=3D=3D Part 2 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> =3D=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>>This is what my text was trying to describe. And I don't think it is=20 >>>in conflict with your text in the beginning of the paragraph. >>=20 >>You are using different C-D values for the body parts associated with=20 >>the Info Package. >>=20 >>But, again, a body part associated with an Info Package shall have value 'info-package'. >=20 >You keep repeated the last sentence above as a mantra, as if it was cast in stone. But we are discussing what is supposed=20 >to be written on the stone. Well, my understanding is that we decided that a long time ago, so I wouldn't like to change it unless it doesn't work. But I may of course be wrong. In my opinion, since the SIP stack doesn't need to know whether the content of the I-P body part shall be rendered, or whatever, we can always use 'info-package'. The I-P specification then defines what the application shall do with it. >And in any case, in the above it is the body part with C-D of info-package that is associated with the info package. Yes, but as you know, my opinion is that the individual body parts also shall have the correct C-D value, so foo and baz should be 'info-package' :) >>And, in your example above, assuming that Part 2 would NOT be part of=20 >>the Info Package, HOW do you indicate that Part 1 (C-D: foo) is=20 >>associated with the Info Package? >=20 >Wrong assumption. *My* assumption is that once a body/body=20 >part is associated with the info package, then *all the bits=20 >it contains* including any nested body parts, are=20 >transitively also associated with the info package. >=20 >Its a tree. If I own a branch, then I own all the descendents=20 >of that branch. If I saw it off and take it somewhere, I take=20 >the whole thing. I don't just take away my immediate branch=20 >and leave some of its children behind floating in the air=20 >around the tree. But, again, how would the message look like if Part 1 is an I-P body part and Part 2 isn't? That IS a possible use-case, since we have agreed that someone may add extra body parts to the INFO. Would you add a second multipart (C-D 'info-package'), inside the first multipart, which would only contain Part 1? Regards, Christer From pkyzivat@cisco.com Thu Oct 22 07:33:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507613A6A61 for ; Thu, 22 Oct 2009 07:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh+VvEzz-mwJ for ; Thu, 22 Oct 2009 07:33:16 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 10A063A688C for ; Thu, 22 Oct 2009 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6441; q=dns/txt; s=rtpiport01001; t=1256222004; x=1257431604; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2010:33:22=20-0400|Message-ID:=20<4AE06D32. 8010109@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20"Elwell,=20John"=20,=0D=0A=20=20=20=20=20=20=20 =20SIPCORE=20,=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20Gonzalo=20Cama rillo=20,=0D=0A=20=20=20 =20=20=20=20=20draft-ietf-sipcore-info-events@tools.ietf. org|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20=20<7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E3 5MSX.ww902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20 <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX. ww902.siemens.net>=20=20<4ADE168F.7060303@c isco.com>=20=20<4ADE227C.5020500@cisco.com> =20<7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35M SX.ww902.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20<7 402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww 902.siemens.net>=20<4ADF99E7.4000103@cisco.com>=20=20<4AE05E8C.8050709@cisco.com>=20; bh=jcTL75lJLige1Zj7Gfg6rxZPWBqwP4LCJ0VOZML3gX0=; b=f2YP3PXdsTKOrRaWkQEu+40IULFkUNV0wYQQJcqt0ip8/jX6gu+zAyn1 ut9/glRTOECvEiG4dZzz5EcYrHDkM1U8tV3bzyVPzbxaFtbeTOzP9IGPh t+csJC3tb+KZOhhr5cwY/TeiMHztvbe8JT8PTi7C++seeTR5yPi2KXx5q A=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIMJ4EpAZnwM/2dsb2JhbADDB5hehD8E X-IronPort-AV: E=Sophos;i="4.44,605,1249257600"; d="scan'208";a="64359536" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 14:33:23 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MEXNg3013138; Thu, 22 Oct 2009 14:33:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:33:23 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 10:33:22 -0400 Message-ID: <4AE06D32.8010109@cisco.com> Date: Thu, 22 Oct 2009 10:33:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 14:33:22.0672 (UTC) FILETIME=[9B86EF00:01CA5324] Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 14:33:17 -0000 Christer Holmberg wrote: > Hi, > >>>>> [JRE] But wouldn't that then conflict with the first of my proposed >>>>> sentences? The first sentence says "The body part associated with >>>>> the Info Package MUST contain a Content-Disposition header field >>>>> with value 'Info-Package'". >>>>> Your modified second sentence then seems to contradict it by saying >>>>> only in certain circumstances does it need to do this. >>>> I think we are probably just not envisioning the same use case. >>>> This is entangled with the debate I am having with >> Christer elsewhere. >>>> I'll try a picture: >>>> >>>> ==== INFO message headers ====== >>>> | INFO ... >>>> | C-D: info-pkg >>>> | C-T: multipart/whatever >>>> | (other headers) >>>> | >>>> ==== INFO body start =========== >>>> | ==== Part 1 headers ========== >>>> | | C-T: text/plain >>>> | | C-D: foo >>>> | | >>>> | ==== Part 1 body start ======= >>>> | | some text >>>> | ==== Part 1 end ============== >>>> | ==== Part 2 headers ========== >>>> | | C-T: application/bar >>>> | | C-D: baz >>>> | | >>>> | ==== Part 2 body start ======= >>>> | | (application/baz stuff) >>>> | ==== Part 2 end ============== >>>> ==== INFO end ================== >>>> >>>> This is what my text was trying to describe. And I don't think it is >>>> in conflict with your text in the beginning of the paragraph. >>> You are using different C-D values for the body parts associated with >>> the Info Package. >>> >>> But, again, a body part associated with an Info Package shall have > value 'info-package'. >> You keep repeated the last sentence above as a mantra, as if it was > cast in stone. But we are discussing what is supposed >> to be written on the stone. > > Well, my understanding is that we decided that a long time ago, so I > wouldn't like to change it unless it doesn't work. But I may of course > be wrong. > > In my opinion, since the SIP stack doesn't need to know whether the > content of the I-P body part shall be rendered, or whatever, we can > always use 'info-package'. The I-P specification then defines what the > application shall do with it. That is fine, at the branch of the tree where the thing is determined to be I-P content. Below that point is another story. >> And in any case, in the above it is the body part with C-D of > info-package that is associated with the info package. > > Yes, but as you know, my opinion is that the individual body parts also > shall have the correct C-D value, so foo and baz should be > 'info-package' :) Which is the heart of the discussion. >>> And, in your example above, assuming that Part 2 would NOT be part of >>> the Info Package, HOW do you indicate that Part 1 (C-D: foo) is >>> associated with the Info Package? >> Wrong assumption. *My* assumption is that once a body/body >> part is associated with the info package, then *all the bits >> it contains* including any nested body parts, are >> transitively also associated with the info package. >> >> Its a tree. If I own a branch, then I own all the descendents >> of that branch. If I saw it off and take it somewhere, I take >> the whole thing. I don't just take away my immediate branch >> and leave some of its children behind floating in the air >> around the tree. > > But, again, how would the message look like if Part 1 is an I-P body > part and Part 2 isn't? That IS a possible use-case, since we have agreed > that someone may add extra body parts to the INFO. OK, lets draw a few more cases. 1) My case from the earlier message with some names changed to make things clearer: === INFO message headers =========== | INFO ... | C-D: info-pkg | C-T: multipart/whatever | (other headers) | === INFO body start ================ | === Info-pkg txt part headers ==== | | C-T: text/plain | | C-D: foo | | | === Info-pkg txt part body start = | | some text | === Info-pkg txt part end ======== | === Info-pkg xml part headers ==== | | C-T: application/bar | | C-D: baz | | | === Info-pkg xml part body start = | | (application/bar stuff) | === Info-pkg xml part end ======== === INFO end ======================= 2) Your case, where the info package only requires a single text part, but an extension header also requires a part that is unrelated to the info package. === INFO message headers =========== | INFO ... | C-D: info-pkg | C-T: multipart/mixed | Extension-Header: | (other headers) | === INFO body start ================ | === Info-pkg txt part headers ==== | | C-T: text/plain | | C-D: info-package | | | === Info-pkg txt part body start = | | some text | === Info-pkg txt part end ======== | === Ext-hdr part headers ========= | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | === Ext-hdr part body start ====== | | (application/extension-header stuff) | === Ext-hdr part end ============= === INFO end ======================= 3) A combination of the two cases. The stuff "associated with the info package" is again a multipart, just as in the first case, but now it shares the INFO body with a body part for the extension header of the second case. This requires introducing a multipart/mixed just as the 2nd case did === INFO message headers ============= | INFO ... | C-D: info-pkg | C-T: multipart/mixed | Extension-Header: | (other headers) | === INFO body start ================== | === Info-pkg multipart headers ===== | | C-D: info-pkg | | C-T: multipart/whatever | | | === Info-pkg multipart body start == | | === Info-pkg txt part headers ==== | | | C-T: text/plain | | | C-D: foo | | | | | === Info-pkg txt part body start = | | | some text | | === Info-pkg txt part end ======== | | === Info-pkg xml part headers ==== | | | C-T: application/bar | | | C-D: baz | | | | | === Info-pkg xml part body start = | | | (application/bar stuff) | | === Info-pkg xml part end ======== | === Info-pkg multipart end ========= | === Ext-hdr part headers =========== | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | === Ext-hdr part body start ======== | | (application/extension-header stuff) | === Ext-hdr part end =============== === INFO end ========================= Is that clear? Thanks, Paul From christer.holmberg@ericsson.com Thu Oct 22 09:21:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373F63A67BD for ; Thu, 22 Oct 2009 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WTy8L34rPcP for ; Thu, 22 Oct 2009 09:21:10 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 48E503A65A6 for ; Thu, 22 Oct 2009 09:21:10 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-be-4ae0867e1307 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id DD.24.08816.E7680EA4; Thu, 22 Oct 2009 18:21:18 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:20:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 18:20:29 +0200 Message-ID: In-Reply-To: <4AE06100.4080604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events Thread-Index: AcpTHk6K9k/e5O1UT0OGpLzkcW1rkgAFOb0A References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> <4AE06100.4080604@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 22 Oct 2009 16:20:31.0559 (UTC) FILETIME=[93713D70:01CA5333] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:21:12 -0000 Hi, I changed the wording to "An Info Package *specification* defines the content and semantics of the iformation carried in an INFO message associated with the Info Package", and John told me he was ok with it. Also, I've removed 1.2 and 1.3, and moved the text into other places of the specifcation. I am preparing a new version of the draft, and I will submit it soon (today, if I get everything done). We still have an open issue regarding the C-D stuff, but due to the amount of comments and changes since the previous version I think it is good to base comments etc on a new version. It will also be easier for others to follow the discussions. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 22. lokakuuta 2009 16:41 To: Elwell, John Cc: Christer Holmberg; SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events I like the new wording. I also support the change John proposes here. I didn't pick up on it myself, but since John pointed it out I agree that the circularity is problematic, and his wording fixes it. Thanks, Paul Regarding "associated with", on other threads we seem to be having trouble with that. Elwell, John wrote: > Christer, >=20 > Looking good. Just a couple of nits below.=20 >=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 22 October 2009 06:27 >> To: Paul Kyzivat >> Cc: Elwell, John; SIPCORE >> Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events) >> - Style of section 1 in info-events >> >> >> Hi, >> >>>> Basically we should only refer to 2976 when we talk about >> legacy INFO >>>> usage, and when we talk about the drawbacks of legacy INFO usage. >>> IMO it should only be referenced informatively, not normatively. And >>> as such it should not be necessary to reference it *at all* to build >>> an implementation that supports legacy behavior. >> I have removed lots of references to 2976. It is now only used when=20 >> talking about legacy INFO usage. >> >>>> This document defines a new method, INFO, for the Session=20 >>>> Initiation Protocol (SIP) [RFC2976]. >>> Why the rfc ref there? *THIS* document is the new definition of the >> INFO method. >> >> It should be [RFC3261]. >> >>>> When a UA sends an INFO request, it uses the Info-Package header=20 >>>> field to indicate which Info Package is associated with the=20 >>>> request. One particular INFO request can only be >> associated with a >> single Info Package. >>>> This document obosoletes [RFC2976]. However, for backward >> compability >> it allows >>>> to use INFO per [RFC2976], referred to as legacy INFO usage in the >> document. >>> However, for backward compatibility it specifies a "legacy"=20 >>> mode of usage of the INFO method that is compatible with the usage=20 >>> previously defined in RFC2976. >> Looks ok. >> >>>> 1.2 Problems with leagcy INFO usage >>>> >>>> While legacy INFO usage [RFC2976] has been widely adopted for=20 >>>> specific application use cases, such as ISUP and DTMF exchange, >> [RFC2976] >>>> does not not define a mechanisms for SIP UAs to indicate for which=20 >>>> types of applications and contexts they support the INFO=20 >>>> method.what usages of INFO. In addition, [RFC2976] does not provide >>>> a mechanism to explicitly indicate the type of >> application and context >>>> for which a specific INFO message is associated to. >>> I'm ok with the above, except that I think it should always refer to >>> RFC2976 in the past tense, since it is obsoleted by this document. >> I agree. However, I would still prefer to say "has been widely=20 >> adopted", rather than "was adopted". >> >> "was" sounds like it was done at some point, but not anymore :) >> >> -------------------------------------- >> >> New try :) I have tried to implement both Paul's and John's comments. >> >> "1. Introduction >> =20 >> 1.1 General >> =20 >> This document defines a new method, INFO, for the Session Initiation=20 >> Protocol (SIP) [RFC3261]. >> >> The purpose of the INFO message is to carry application level=20 >> information between endpoints, using the SIP session signaling path.=20 >> Note that the INFO method is not used to update characteristics of=20 >> the SIP session, but to allow the applications which use the SIP=20 >> session to exchange information (which may update the state of those=20 >> applications). >> >> In addition, this document also defines an Info Package mechanism. An >> Info Package defines the content and semantics of the iformation=20 >> carried in an INFO message associated with the Info Package. > [JRE] I would change "associated with the INFO package" (which is a little bit circular) to "for a particular usage". >=20 >> The Info Package mechanism also provides a way for UAs to indicate=20 >> for which types of applications and contexts they are willing=20 >> to receive >> INFO requests. The >> document defines how the INFO method is used, new SIP header fields=20 >> for the INFO method, and how to transport payload information=20 >> associated with an Info Package using INFO requests.=20 > [JRE] Change "The document" to "This document". And since the sentence is not specifically talking about the Info Package mechanism, it should be preceded by a paragraph break. >=20 > John >=20 >> =20 >> Use of the INFO method does not constitute a separate dialog usage. >> INFO messages are always part of, and share the fate of,=20 >> an invite dialog usage. INFO messages cannot be sent as part of=20 >> other dialog usages. >> =20 >> A UA uses the Recv-Info header field, on a per-dialog basis,=20 >> to indicate >> for which Info=20 >> Packages it is willing to receive INFO requests. A UA can indicate an >> initial set of Info Packages during dialog=20 >> establishment and can indicate a new set during the lifetime of the >> invite dialog usage.=20 >> >> A UA can use a "nil" header field value to indicate that it is not >> willing to >> receive INFO requests associated with any Info Packages at a certain >> moment, but that=20 >> the UA still supports the Info Package mechanism. >> =20 >> When a UA sends an INFO request, it uses the Info-Package header >> field to indicate which Info Package is associated with=20 >> the request. One particular INFO request can only be associated with a >> single Info Package. >> =20 >> This document obosoletes [RFC2976]. However, for backward=20 >> compatibility >> it specifies a "legacy"=20 >> mode of usage of the INFO method that is compatible with the usage >> previously defined in [RFC2976],=20 >> referred to as "legacy INFO Usage" in this document. >> =20 >> 1.2 Problems with leagcy INFO usage >> =20 >> While legacy INFO usage [RFC2976] has been widely adopted for specific >> application use cases, such as ISUP and DTMF exchange, [RFC2976] did >> not define a mechanism for SIP UAs to indicate which types of >> applications and contexts support the INFO method. In addition, >> [RFC2976] did not provide a mechanism to explicitly indicate the type >> of application and context for which a specific INFO message is >> associated.=20 >> >> Example: If the Content-Type is "image/jpeg", the MIME-attached >> content is a JPEG image. Still, there are many useful=20 >> ways a UA can render an image. The image could be a caller-id=20 >> picture, a contact icon, a photo for sharing, and so on. The sender >> does not=20 >> know which image to send to the receiver if the receiver supports an >> image >> content type. Likewise, the receiver does not know the context of an >> image the client is sending if the receiver supports=20 >> receiving more than one image content type. >> =20 >> Due to the problems described above, legacy INFO usages often require >> static configuration about for what type of applications and contexts >> UAs support the INFO method, and the way they handle application >> information=20 >> transported in INFO messages. >> That has caused interoperability problems in the industry. >> Therefore,a need for a well defined and documented description of what >> the information sent in=20 >> the INFO is used for has been identified. This situation is=20 >> analogous to >> the >> context issue in Internet Mail [RFC3458]. >> =20 >> 1.3 Relationship to subscription-based event >> =20 >> Event Packages [RFC3265] perform the role of disambiguating the >> context of a message for subscription-based events. The=20 >> Info Package mechanism provides similar functionality for application >> information exchange using invite dialog usages [RFC5057]. However,=20 >> there is no formal relationship between the Info Package mechanism and >> the >> subscription-based event mechanism." >> >> Regards, >> >> Christer >> >> From pkyzivat@cisco.com Thu Oct 22 09:31:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A453A68BA for ; Thu, 22 Oct 2009 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxZ7LOtbD9RF for ; Thu, 22 Oct 2009 09:31:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 140DA3A6961 for ; Thu, 22 Oct 2009 09:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9211; q=dns/txt; s=sjiport05001; t=1256229070; x=1257438670; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20(draft-ietf-sipcore-info-even ts)=20-=20Style=20of=20section=0D=0A=201=20in=20info-even ts|Date:=20Thu,=2022=20Oct=202009=2012:31:02=20-0400 |Message-ID:=20<4AE088C6.7040805@cisco.com>|To:=20Christe r=20Holmberg=20|CC:=20"El well,=20John"=20,=0D =0A=20=20=20=20=20=20=20=20SIPCORE=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20|References:=20<7402509E63C 5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemen s.net>=20=20<4ADFA3CE.4010300@cisco.com>=20 =20<7402509E63C5A145A6095D46C179A5B7148B2E1 D@DEMCHP99E35MSX.ww902.siemens.net>=20<4AE06100.4080604@c isco.com>=20; bh=8b49Mip8aiSi708FTWNvTAcLGwlvAmjTn4nojSQbSJk=; b=W8e2uhhtmUWe1MOQt7ePEsdsPYjIifvcLHBMK/nnkcmbRM5J8oMRdg31 Kj6pX6/3UcDpb5F3NlweNQadjrme/I/vy8vQ7sFqULqMJx9+wef/rDyD+ eKpflF/Haep7jGaFwaCEKOhwhRkPIJyG49PWsYLY2d4qR7/VRkQhqvf6A k=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN8l4EqrR7H+/2dsb2JhbADDYZhfhD8E X-IronPort-AV: E=Sophos;i="4.44,606,1249257600"; d="scan'208";a="100413519" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2009 16:31:10 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MGUul3025781; Thu, 22 Oct 2009 16:31:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:31:03 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:31:02 -0400 Message-ID: <4AE088C6.7040805@cisco.com> Date: Thu, 22 Oct 2009 12:31:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B7148B2D1F@DEMCHP99E35MSX.ww902.siemens.net> <4ADFA3CE.4010300@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1D@DEMCHP99E35MSX.ww902.siemens.net> <4AE06100.4080604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 16:31:02.0810 (UTC) FILETIME=[0BB27FA0:01CA5335] Cc: SIPCORE Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of section 1 in info-events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:31:02 -0000 sounds good. Christer Holmberg wrote: > Hi, > > I changed the wording to "An Info Package *specification* defines the > content and semantics of the iformation carried in an INFO message > associated with the Info Package", and John told me he was ok with it. > > Also, I've removed 1.2 and 1.3, and moved the text into other places of > the specifcation. > > I am preparing a new version of the draft, and I will submit it soon > (today, if I get everything done). We still have an open issue regarding > the C-D stuff, but due to the amount of comments and changes since the > previous version I think it is good to base comments etc on a new > version. It will also be easier for others to follow the discussions. > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 22. lokakuuta 2009 16:41 > To: Elwell, John > Cc: Christer Holmberg; SIPCORE > Subject: Re: [sipcore] WGLC (draft-ietf-sipcore-info-events) - Style of > section 1 in info-events > > I like the new wording. I also support the change John proposes here. I > didn't pick up on it myself, but since John pointed it out I agree that > the circularity is problematic, and his wording fixes it. > > Thanks, > Paul > > Regarding "associated with", on other threads we seem to be having > trouble with that. > > Elwell, John wrote: >> Christer, >> >> Looking good. Just a couple of nits below. >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 22 October 2009 06:27 >>> To: Paul Kyzivat >>> Cc: Elwell, John; SIPCORE >>> Subject: RE: [sipcore] WGLC (draft-ietf-sipcore-info-events) >>> - Style of section 1 in info-events >>> >>> >>> Hi, >>> >>>>> Basically we should only refer to 2976 when we talk about >>> legacy INFO >>>>> usage, and when we talk about the drawbacks of legacy INFO usage. >>>> IMO it should only be referenced informatively, not normatively. And > >>>> as such it should not be necessary to reference it *at all* to build > >>>> an implementation that supports legacy behavior. >>> I have removed lots of references to 2976. It is now only used when >>> talking about legacy INFO usage. >>> >>>>> This document defines a new method, INFO, for the Session >>>>> Initiation Protocol (SIP) [RFC2976]. >>>> Why the rfc ref there? *THIS* document is the new definition of the >>> INFO method. >>> >>> It should be [RFC3261]. >>> >>>>> When a UA sends an INFO request, it uses the Info-Package header >>>>> field to indicate which Info Package is associated with the >>>>> request. One particular INFO request can only be >>> associated with a >>> single Info Package. >>>>> This document obosoletes [RFC2976]. However, for backward >>> compability >>> it allows >>>>> to use INFO per [RFC2976], referred to as legacy INFO usage in the >>> document. >>>> However, for backward compatibility it specifies a "legacy" >>>> mode of usage of the INFO method that is compatible with the usage >>>> previously defined in RFC2976. >>> Looks ok. >>> >>>>> 1.2 Problems with leagcy INFO usage >>>>> >>>>> While legacy INFO usage [RFC2976] has been widely adopted for >>>>> specific application use cases, such as ISUP and DTMF exchange, >>> [RFC2976] >>>>> does not not define a mechanisms for SIP UAs to indicate for which >>>>> types of applications and contexts they support the INFO >>>>> method.what usages of INFO. In addition, [RFC2976] does not provide > >>>>> a mechanism to explicitly indicate the type of >>> application and context >>>>> for which a specific INFO message is associated to. >>>> I'm ok with the above, except that I think it should always refer to >>>> RFC2976 in the past tense, since it is obsoleted by this document. >>> I agree. However, I would still prefer to say "has been widely >>> adopted", rather than "was adopted". >>> >>> "was" sounds like it was done at some point, but not anymore :) >>> >>> -------------------------------------- >>> >>> New try :) I have tried to implement both Paul's and John's comments. >>> >>> "1. Introduction >>> >>> 1.1 General >>> >>> This document defines a new method, INFO, for the Session Initiation >>> Protocol (SIP) [RFC3261]. >>> >>> The purpose of the INFO message is to carry application level >>> information between endpoints, using the SIP session signaling path. >>> Note that the INFO method is not used to update characteristics of >>> the SIP session, but to allow the applications which use the SIP >>> session to exchange information (which may update the state of those >>> applications). >>> >>> In addition, this document also defines an Info Package mechanism. An > >>> Info Package defines the content and semantics of the iformation >>> carried in an INFO message associated with the Info Package. >> [JRE] I would change "associated with the INFO package" (which is a > little bit circular) to "for a particular usage". >>> The Info Package mechanism also provides a way for UAs to indicate >>> for which types of applications and contexts they are willing >>> to receive >>> INFO requests. The >>> document defines how the INFO method is used, new SIP header fields >>> for the INFO method, and how to transport payload information >>> associated with an Info Package using INFO requests. >> [JRE] Change "The document" to "This document". And since the sentence > is not specifically talking about the Info Package mechanism, it should > be preceded by a paragraph break. >> John >> >>> >>> Use of the INFO method does not constitute a separate dialog usage. >>> INFO messages are always part of, and share the fate of, >>> an invite dialog usage. INFO messages cannot be sent as part of >>> other dialog usages. >>> >>> A UA uses the Recv-Info header field, on a per-dialog basis, >>> to indicate >>> for which Info >>> Packages it is willing to receive INFO requests. A UA can indicate an >>> initial set of Info Packages during dialog >>> establishment and can indicate a new set during the lifetime of the >>> invite dialog usage. >>> >>> A UA can use a "nil" header field value to indicate that it is not >>> willing to >>> receive INFO requests associated with any Info Packages at a certain >>> moment, but that >>> the UA still supports the Info Package mechanism. >>> >>> When a UA sends an INFO request, it uses the Info-Package header >>> field to indicate which Info Package is associated with >>> the request. One particular INFO request can only be associated with > a >>> single Info Package. >>> >>> This document obosoletes [RFC2976]. However, for backward >>> compatibility >>> it specifies a "legacy" >>> mode of usage of the INFO method that is compatible with the usage >>> previously defined in [RFC2976], >>> referred to as "legacy INFO Usage" in this document. >>> >>> 1.2 Problems with leagcy INFO usage >>> >>> While legacy INFO usage [RFC2976] has been widely adopted for > specific >>> application use cases, such as ISUP and DTMF exchange, [RFC2976] did >>> not define a mechanism for SIP UAs to indicate which types of >>> applications and contexts support the INFO method. In addition, >>> [RFC2976] did not provide a mechanism to explicitly indicate the type >>> of application and context for which a specific INFO message is >>> associated. >>> >>> Example: If the Content-Type is "image/jpeg", the MIME-attached >>> content is a JPEG image. Still, there are many useful >>> ways a UA can render an image. The image could be a caller-id >>> picture, a contact icon, a photo for sharing, and so on. The sender >>> does not >>> know which image to send to the receiver if the receiver supports an >>> image >>> content type. Likewise, the receiver does not know the context of an >>> image the client is sending if the receiver supports >>> receiving more than one image content type. >>> >>> Due to the problems described above, legacy INFO usages often require >>> static configuration about for what type of applications and contexts >>> UAs support the INFO method, and the way they handle application >>> information >>> transported in INFO messages. >>> That has caused interoperability problems in the industry. >>> Therefore,a need for a well defined and documented description of > what >>> the information sent in >>> the INFO is used for has been identified. This situation is >>> analogous to >>> the >>> context issue in Internet Mail [RFC3458]. >>> >>> 1.3 Relationship to subscription-based event >>> >>> Event Packages [RFC3265] perform the role of disambiguating the >>> context of a message for subscription-based events. The >>> Info Package mechanism provides similar functionality for application > >>> information exchange using invite dialog usages [RFC5057]. However, >>> there is no formal relationship between the Info Package mechanism > and >>> the >>> subscription-based event mechanism." >>> >>> Regards, >>> >>> Christer >>> >>> > From christer.holmberg@ericsson.com Thu Oct 22 09:48:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94C2C28B797 for ; Thu, 22 Oct 2009 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmcUVRag-SLb for ; Thu, 22 Oct 2009 09:48:30 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 00FEE3A6983 for ; Thu, 22 Oct 2009 09:48:28 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-d4-4ae08ce5b32f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 9B.45.08816.5EC80EA4; Thu, 22 Oct 2009 18:48:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 18:48:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 18:48:36 +0200 Message-ID: In-Reply-To: <4AE06D32.8010109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTJKATgfAfFGQmRmu07Ny7bQ8F6wADzkhg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> <4AE06D32.8010109@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 16:48:37.0250 (UTC) FILETIME=[80314620:01CA5337] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Adam Roach , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:48:31 -0000 Hi,=20 >>>>> [JRE] But wouldn't that then conflict with the first of my=20 >>>>> proposed sentences? The first sentence says "The body part=20 >>>>> associated with the Info Package MUST contain a=20 >>>>> Content-Disposition header field with value 'Info-Package'". >>>>> Your modified second sentence then seems to contradict it by=20 >>>>> saying only in certain circumstances does it need to do this. >>>> I think we are probably just not envisioning the same use case. >>>> This is entangled with the debate I am having with >> Christer elsewhere. >>>> I'll try a picture: >>>> >>>> =3D=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D >>>> | INFO ... >>>> | C-D: info-pkg >>>> | C-T: multipart/whatever >>>> | (other headers) >>>> | >>>> =3D=3D=3D=3D INFO body start =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> | =3D=3D=3D=3D Part 1 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> | | C-T: text/plain >>>> | | C-D: foo >>>> | | >>>> | =3D=3D=3D=3D Part 1 body start =3D=3D=3D=3D=3D=3D=3D >>>> | | some text >>>> | =3D=3D=3D=3D Part 1 end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> | =3D=3D=3D=3D Part 2 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> | | C-T: application/bar >>>> | | C-D: baz >>>> | | >>>> | =3D=3D=3D=3D Part 2 body start =3D=3D=3D=3D=3D=3D=3D >>>> | | (application/baz stuff) >>>> | =3D=3D=3D=3D Part 2 end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> =3D=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> This is what my text was trying to describe. And I don't think it=20 >>>> is in conflict with your text in the beginning of the paragraph. >>> You are using different C-D values for the body parts associated=20 >>> with the Info Package. >>> >>> But, again, a body part associated with an Info Package shall have > value 'info-package'. >> You keep repeated the last sentence above as a mantra, as if it was > cast in stone. But we are discussing what is supposed >> to be written on the stone. >=20 >>Well, my understanding is that we decided that a long time ago, so I=20 >>wouldn't like to change it unless it doesn't work. But I may of course >>be wrong. >>=20 >>In my opinion, since the SIP stack doesn't need to know whether the=20 >>content of the I-P body part shall be rendered, or whatever, we can=20 >>always use 'info-package'. The I-P specification then defines what the >>application shall do with it. > >That is fine, at the branch of the tree where the thing is determined to be I-P content. Below that point is another story. (Christer) I think we need to separate 3 issues. FIRST, can an Info Package specification in general specify another C-D value than 'info-package' to a body part associated with the I-P (without considering where in the body part the body part will be located). SECOND, if a multipart contains C-D "info-package", does it matter what C-D values the children have? THIRD, do we require all body parts (if many) associated with the I-P to be part of the same multipart of the message (no matter whether the children will get C-D 'info-package' or not). Regarding the FIRST issue, when looking at your examples below, I THINK that we agree that an I-P specification should never assign another C-D value than 'info-package' to a body part associated with the I-P. Correct? Regarding the SECOND issue, I think that is we have different views. You say that as long as the parent has C-D 'info-package' it doesn't matter what values a parser may assign to the children, while I think that the children should also explicitly be assigned 'info-package'. Regarding the THIRD issue, I don't think we should mandate it. I think that a I-P specification should indicate whether some body parts need to be collected within a multipart, what multipart type (mixed, alternative etc) shall be used etc. ------------------- >OK, lets draw a few more cases. > >1) My case from the earlier message with some names changed to make things clearer: > >=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| INFO ... >| C-D: info-pkg >| C-T: multipart/whatever >| (other headers) >| >=3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D >| | C-T: text/plain >| | C-D: foo >| | >| =3D=3D=3D Info-pkg txt part body start =3D >| | some text >| =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Info-pkg xml part headers =3D=3D=3D=3D >| | C-T: application/bar >| | C-D: baz >| | >| =3D=3D=3D Info-pkg xml part body start =3D >| | (application/bar stuff) >| =3D=3D=3D Info-pkg xml part end =3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So, just to be clear: it does not matter what foo and baz are, since the parent C-D is info-pkg. In other words, the I-P specification does not specifiy that the foo and baz values shall be used for these body parts. ------------------- >2) Your case, where the info package only requires a single text part, but an extension header also requires a part that is unrelated to the info package. > >=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| INFO ... >| C-D: info-pkg >| C-T: multipart/mixed >| Extension-Header: >| (other headers) >| >=3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D >| | C-T: text/plain >| | C-D: info-package >| | >| =3D=3D=3D Info-pkg txt part body start =3D >| | some text >| =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Ext-hdr part headers =3D=3D=3D=3D=3D=3D=3D=3D=3D >| | C-T: application/extension-header >| | C-D: by-reference >| | Content-ID: some-label >| | >| =3D=3D=3D Ext-hdr part body start =3D=3D=3D=3D=3D=3D >| | (application/extension-header stuff) >| =3D=3D=3D Ext-hdr part end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is the example on which I assume your opinion on the first issue: if an I-P body part does not have a parent with C-D 'info-package', it shall always have C-D 'info-package'. The I-P specification does not mention "foo" - "foo" in the previous example was just whatever value which the receiving parser may have assigned, right? Also, would it be allowed to have multiple I-P body partss inside this multipart? That could happen if the original INVITE contains a multipart with two I-P body parts, but someone else inserts a third body into the multipart. Or, would whoever inserts the third body part be mandated to create a second level multipart for the I-P body parts (as in example 3)? ------------------- >3) A combination of the two cases. The stuff "associated with the info package" is again a multipart, just as in the first case, but now it shares the INFO body with a body part for the extension header >of the second case. This requires introducing a multipart/mixed just as the 2nd case did > >=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| INFO ... >| C-D: info-pkg >| C-T: multipart/mixed >| Extension-Header: >| (other headers) >| >=3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Info-pkg multipart headers =3D=3D=3D=3D=3D >| | C-D: info-pkg >| | C-T: multipart/whatever >| | >| =3D=3D=3D Info-pkg multipart body start =3D=3D >| | =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D >| | | C-T: text/plain >| | | C-D: foo >| | | >| | =3D=3D=3D Info-pkg txt part body start =3D >| | | some text >| | =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D >| | =3D=3D=3D Info-pkg xml part headers =3D=3D=3D=3D >| | | C-T: application/bar >| | | C-D: baz >| | | >| | =3D=3D=3D Info-pkg xml part body start =3D >| | | (application/bar stuff) >| | =3D=3D=3D Info-pkg xml part end =3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Info-pkg multipart end =3D=3D=3D=3D=3D=3D=3D=3D=3D >| =3D=3D=3D Ext-hdr part headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >| | C-T: application/extension-header >| | C-D: by-reference >| | Content-ID: some-label >| | >| =3D=3D=3D Ext-hdr part body start =3D=3D=3D=3D=3D=3D=3D=3D >| | (application/extension-header stuff) >| =3D=3D=3D Ext-hdr part end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= On this example I of course have the same issue as the first one, regaring the C-D values withint the I-P mulipart. But, this example also raises the third issue: do we mandate that all I-P body parts belong to the same multipart? Regards, Christer From adam@estacado.net Thu Oct 22 10:41:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8587F3A6967 for ; Thu, 22 Oct 2009 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTPcU3IIKu8w for ; Thu, 22 Oct 2009 10:41:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 1A1EE3A6809 for ; Thu, 22 Oct 2009 10:41:41 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9MHfkX0001354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 12:41:46 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE0995A.9050906@estacado.net> Date: Thu, 22 Oct 2009 12:41:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Kyzivat References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> In-Reply-To: <4ADF9BFC.50007@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 22 Oct 2009 10:43:41 -0700 Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:41:43 -0000 On 10/21/09 18:40, Oct 21, Paul Kyzivat wrote: > > Christer Holmberg wrote: >> >> I don't agree. Eventhough I do hear what you are saying, in my opinion >> "We don't care" goes against what we tried to fix with RFC 5621, and >> could potentially cause problems. An Info-Package body part shall have >> C-D 'info-package', and I don't like that fact that we should allow "any >> value" to be assigned to a body part just because it is transported >> within a multipart. > > IMO its not about overhead, its about layering. > Consider multiparts used in email, such as for attachments. The > attachments are often understood by pieces of software independent of > the email system. > > Similarly here. There will be something that receives the info package > body - that knows that is what it is. But if it has chosen to use > multipart to consolidate a number of things into it, those might come > from, and be consumed by independent software. (Considering that INFO > has been used for tunneling stuff for other protocols, its really easy > to imagine that.) > > The subordinate C-D values may be needed to interpret that stuff. > > I think we don't have enough people in this discussion. The two of us > are just not going to agree. I'd like to hear from Adam who has had a > lot of insight into multipart in the past, and from Gonzallo, who > wrote the body handling draft. I'm with Paul on this one. By requiring subparts within an INFO multipart document to be *all* labeled with a C-D of "info-package", you're removing a lot of flexibility. Suddenly, INFO packages are disallowed from using C-D on their own multipart subparts to impact processing. Consider a hypothetical INFO package that, for some reason or another, needed to carry an email message in its body. In this particular case, consider that the email message contains two attachments: one image (say, a company logo), and a document. The image is inline in the sender's signature. The document shouldn't be inlined, but is expected to be rendered simply as a separate attachment. If we take the approach Paul & I are advocating, you can properly mark the attachments with "Content-Disposition: inline" and "Content-Disposition: attachment." With your approach, the package would be forced to mark them both with "Content-Disposition: info-package." It seems like a horrific waste forcing the redundant "info-package" string down into places where it (a) adds no additional information and (b) precludes the ability to *add* useful information. /a From christer.holmberg@ericsson.com Thu Oct 22 10:57:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659BC3A68A0 for ; Thu, 22 Oct 2009 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxjKaSFTXv6d for ; Thu, 22 Oct 2009 10:57:54 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0DBEF3A6980 for ; Thu, 22 Oct 2009 10:57:53 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b6-4ae09d2ab363 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 54.BF.24026.A2D90EA4; Thu, 22 Oct 2009 19:58:02 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 19:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 19:58:01 +0200 Message-ID: In-Reply-To: <4AE0995A.9050906@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTPu+bOeJdNg/KT1CZOrYT/X7nmgAAF39Q References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> From: "Christer Holmberg" To: "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 17:58:02.0159 (UTC) FILETIME=[32ABF3F0:01CA5341] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:57:55 -0000 Hi,=20 >>> I don't agree. Eventhough I do hear what you are saying, in my=20 >>> opinion "We don't care" goes against what we tried to fix with RFC=20 >>> 5621, and could potentially cause problems. An Info-Package body part=20 >>> shall have C-D 'info-package', and I don't like that fact that we=20 >>> should allow "any value" to be assigned to a body part just because=20 >>> it is transported within a multipart. >> >> IMO its not about overhead, its about layering. >> Consider multiparts used in email, such as for attachments. The=20 >> attachments are often understood by pieces of software independent of >> the email system. >> >> Similarly here. There will be something that receives the info package=20 >> body - that knows that is what it is. But if it has chosen to use=20 >> multipart to consolidate a number of things into it, those might come >> from, and be consumed by independent software. (Considering that INFO >> has been used for tunneling stuff for other protocols, its really easy=20 >> to imagine that.) >> >> The subordinate C-D values may be needed to interpret that stuff. >> >> I think we don't have enough people in this discussion. The two of us >> are just not going to agree. I'd like to hear from Adam who has had a >> lot of insight into multipart in the past, and from Gonzallo, who=20 >> wrote the body handling draft. > >I'm with Paul on this one. By requiring subparts within an INFO multipart document to be *all* labeled with a C-D of "info-package", you're removing a lot of flexibility. Suddenly, INFO packages are=20 >disallowed from using C-D on their own multipart subparts to impact processing. There are cases (see Paul's examples) where I believe you MUST use C-D 'info-package' for the I-P body part, so we could not assume that one would always be able to use something else (inline, attachment etc) for the body part. In addition, based on Paul's previous reply, I am not sure whether being able to specify other C-D values for I-P body parts is really what he is asking for. He is saying (I guess he should confirm it :) that if you have a multipart with C-D 'info-package', then it does not matter what C-D values the parser may assign the body parts within the multipart, since one knows that they all belong to the I-P. That is NOT the same as saying that a body non-'info-package' should be defined for a specific I-P body part. >Consider a hypothetical INFO package that, for some reason or another, needed to carry an email message in its body. In this particular case, consider that the email message contains two attachments: one=20 >image (say, a company logo), and a document. The image is inline in the sender's signature. The document shouldn't be inlined, but is expected to be rendered simply as a separate attachment. If we take=20 >the approach Paul & I are advocating, you can properly mark the attachments with "Content-Disposition: inline" and "Content-Disposition: attachment." > >With your approach, the package would be forced to mark them both with >"Content-Disposition: info-package." It seems like a horrific waste forcing the redundant "info-package" string down into places where it >(a) adds no additional information and (b) precludes the ability to *add* useful information. So, if you have a single multipart, with one I-P body part with C-D:inline, and one non-I-P body part (may have been inserted by someone else), how do you indicate which body part belongs to the I-P? Regards, Christer From adam@estacado.net Thu Oct 22 11:54:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204AB3A68F8 for ; Thu, 22 Oct 2009 11:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHz+nxbh5QHx for ; Thu, 22 Oct 2009 11:54:19 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D94ED3A68E4 for ; Thu, 22 Oct 2009 11:54:18 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9MIsNYL007039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 13:54:23 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE0AA5F.3010308@estacado.net> Date: Thu, 22 Oct 2009 13:54:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 18:54:20 -0000 On 10/22/09 12:58, Oct 22, Christer Holmberg wrote: > So, if you have a single multipart, with one I-P body part with > C-D:inline, and one non-I-P body part (may have been inserted by > someone else), how do you indicate which body part belongs to the I-P? I think you've missed something important about my example. Keep in mind that multipart bodies are trees, not flat lists. You would never have the "inline" body part I described on the same level as something outside the info-package. Perhaps diagrams would help. In the case I described, the hypothetical INFO package I propose would be structured like this: C-T: multipart/related C-D: info-package | +- C-T: text/html | +- C-T: image/jpeg | C-D: inline | +- C-T: application/pdf C-D: attachment Now, throw in Paul's example of something like an AIB. According to the way MIME works, the resulting document would look like this: C-T: multipart/parallel | +- C-T: multipart/related | C-D: info-package | | | +- C-T: text/html | | | +- C-T: image/jpeg | | C-D: inline | | | +- C-T: application/pdf | C-D: attachment | +- C-T: message/sipfrag C-D: aib It's pretty clear, on a casual inspection, that the text/html, image/jpeg, and application/pdf are all part of the information related to the info-package, because they all have an ancestor marked with a C-D of "info-package". Similarly, the message/sipfrag clearly is not part of the info-package, because it does *not* have an ancestor marked as "info-package". If I read it correctly, your proposal would require the image/jpeg and application/pdf to both be marked with a C-D of "info-package", even though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In doing so, you wipe out the ability to indicate applicable C-Ds like "inline". /a From john.elwell@siemens-enterprise.com Thu Oct 22 12:37:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768D528C176 for ; Thu, 22 Oct 2009 12:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d06JixLUt2k2 for ; Thu, 22 Oct 2009 12:37:42 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by core3.amsl.com (Postfix) with ESMTP id 3D3D228C114 for ; Thu, 22 Oct 2009 12:37:41 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9MJapu0022241; Thu, 22 Oct 2009 21:36:51 +0200 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9MJao42014040; Thu, 22 Oct 2009 21:36:50 +0200 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET0MSX.ww902.siemens.net ([139.25.131.181]) with mapi; Thu, 22 Oct 2009 21:36:50 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Thu, 22 Oct 2009 21:36:47 +0200 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTHfRu3I5wRPjwTiuhjMtLmfnptgAMLHnw Message-ID: <7402509E63C5A145A6095D46C179A5B7148B307B@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E1F@DEMCHP99E35MSX.ww902.siemens.net> <4AE06206.7070206@cisco.com> In-Reply-To: <4AE06206.7070206@cisco.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:37:43 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 22 October 2009 14:46 > To: Elwell, John > Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo=20 > Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body parts in INFO? >=20 >=20 >=20 > Elwell, John wrote: > > Paul, > >=20 > > Yes, we were talking at cross purposes, and I realise now=20 > there was some ambiguity in my original text proposal.=20 > Anyway, let's get the big issue between you and Christer=20 > resolved before we go back to word smithing. >=20 > Then if we now have a common basis for discussion, what is=20 > your thinking=20 > on the debate Christer and I are having? I think it is actually quite=20 > fundamental in how one approaches implementing this, or implementing=20 > multipart support in general. [JRE] I tend to share your point of view, but my understanding of what has = been discussed before on SIP bodies (both in this context and in the body-h= andling RFC context) is somewhat weak, so I am reluctant to speak out too s= trongly on this one. John >=20 > Thanks, > Paul >=20 > > John=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > >> Sent: 22 October 2009 00:32 > >> To: Elwell, John > >> Cc: Christer Holmberg; SIPCORE; Adam Roach; Gonzalo=20 > >> Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > >> Subject: Re: [sipcore] WGLC comments=20 > >> (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > >> non-I-P body parts in INFO? > >> > >> > >> > >> Elwell, John wrote: > >>> =20 > >>> > >>>> -----Original Message----- > >> [snip] > >>>>> The body part associated with the Info Package MUST contain=20 > >>>> a Content-Disposition header field with value 'Info-Package',=20 > >>>> in order easily to distinguish payloads associated with the=20 > >>>> Info Package from other payloads. If the message body only=20 > >>>> contains the single body part associated with the=20 > >>>> Info-Package, the SIP level Content-Disposition header field=20 > >>>> MUST contain value 'Info-Package'. If the message body is of=20 > >>>> type multipart/mixed, the child body part associated with the=20 > >>>> Info-Package MUST include a Content-Disposition header field=20 > >>>> with value 'Info-Package'. Child body parts of a=20 > >>>> multipart/mixed body part associated with the Info-Package do=20 > >>>> not require this Content-Disposition value. > >>>> > >>>> Some slight rewording suggestions: > >>>> > >>>> ... > >>>> If the message body is of type multipart/mixed, > >>>> * and the Content-Disposition is "render" or unspecified, > >>>> the child body part associated with the Info-Package=20 > >> MUST include a > >>>> Content-Disposition header field with value=20 > >>>> 'Info-Package'. Child body > >>>> * parts of a multipart body part associated with the=20 > >>>> Info-Package do not > >>>> * ^^^^^^^^^^ > >>>> require this Content-Disposition value. > >>>> > >>>> In the above I added "and the Content-Disposition is "render" or=20 > >>>> unspecified".=20 > >>> [JRE] But wouldn't that then conflict with the first of my=20 > >> proposed sentences? The first sentence says "The body part=20 > >> associated with the Info Package MUST contain a=20 > >> Content-Disposition header field with value 'Info-Package'".=20 > >> Your modified second sentence then seems to contradict it by=20 > >> saying only in certain circumstances does it need to do this. > >> > >> I think we are probably just not envisioning the same use case. > >> This is entangled with the debate I am having with=20 > Christer elsewhere. > >> I'll try a picture: > >> > >> =3D=3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D > >> | INFO ... > >> | C-D: info-pkg > >> | C-T: multipart/whatever > >> | (other headers) > >> | > >> =3D=3D=3D=3D INFO body start =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> | =3D=3D=3D=3D Part 1 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> | | C-T: text/plain > >> | | C-D: foo > >> | | > >> | =3D=3D=3D=3D Part 1 body start =3D=3D=3D=3D=3D=3D=3D > >> | | some text > >> | =3D=3D=3D=3D Part 1 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> | =3D=3D=3D=3D Part 2 headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> | | C-T: application/bar > >> | | C-D: baz > >> | | > >> | =3D=3D=3D=3D Part 2 body start =3D=3D=3D=3D=3D=3D=3D > >> | | (application/baz stuff) > >> | =3D=3D=3D=3D Part 2 end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> =3D=3D=3D=3D INFO end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > >> > >> This is what my text was trying to describe. And I don't=20 > >> think it is in=20 > >> conflict with your text in the beginning of the paragraph. > >> > >> Thanks, > >> Paul > >> > = From adam@estacado.net Thu Oct 22 13:57:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1ED3A696A for ; Thu, 22 Oct 2009 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sUfx9WZBujo for ; Thu, 22 Oct 2009 13:57:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 35C703A6942 for ; Thu, 22 Oct 2009 13:57:08 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9MKvDi1016490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Oct 2009 15:57:13 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE0C729.6030108@estacado.net> Date: Thu, 22 Oct 2009 15:57:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Paul Kyzivat References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> <4AE06D32.8010109@cisco.com> In-Reply-To: <4AE06D32.8010109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 20:57:10 -0000 I think some MIME confusion has slipped into Paul's examples. Comments below. On 10/22/09 09:33, Oct 22, Paul Kyzivat wrote: > > > Christer Holmberg wrote: >> But, again, how would the message look like if Part 1 is an I-P body >> part and Part 2 isn't? That IS a possible use-case, since we have agreed >> that someone may add extra body parts to the INFO. > > OK, lets draw a few more cases. > > 1) My case from the earlier message with some names changed to make > things clearer: > > === INFO message headers =========== > | INFO ... > | C-D: info-pkg > | C-T: multipart/whatever > | (other headers) > | > === INFO body start ================ > | === Info-pkg txt part headers ==== > | | C-T: text/plain > | | C-D: foo > | | > | === Info-pkg txt part body start = > | | some text > | === Info-pkg txt part end ======== > | === Info-pkg xml part headers ==== > | | C-T: application/bar > | | C-D: baz > | | > | === Info-pkg xml part body start = > | | (application/bar stuff) > | === Info-pkg xml part end ======== > === INFO end ======================= This looks right to me. > > 2) Your case, where the info package only requires a single text part, > but an extension header also requires a part that is unrelated to the > info package. > > === INFO message headers =========== > | INFO ... > | C-D: info-pkg > | C-T: multipart/mixed > | Extension-Header: > | (other headers) > | > === INFO body start ================ > | === Info-pkg txt part headers ==== > | | C-T: text/plain > | | C-D: info-package > | | > | === Info-pkg txt part body start = > | | some text > | === Info-pkg txt part end ======== > | === Ext-hdr part headers ========= > | | C-T: application/extension-header > | | C-D: by-reference > | | Content-ID: some-label > | | > | === Ext-hdr part body start ====== > | | (application/extension-header stuff) > | === Ext-hdr part end ============= > === INFO end ======================= > > This doesn't look right. I don't think the SIP headers should include C-D: info-pkg. That should appear only on the text/plain subpart. > 3) A combination of the two cases. The stuff "associated with the info > package" is again a multipart, just as in the first case, but now it > shares the INFO body with a body part for the extension header of the > second case. This requires introducing a multipart/mixed just as the > 2nd case did > > === INFO message headers ============= > | INFO ... > | C-D: info-pkg > | C-T: multipart/mixed > | Extension-Header: > | (other headers) > | > === INFO body start ================== > | === Info-pkg multipart headers ===== > | | C-D: info-pkg > | | C-T: multipart/whatever > | | > | === Info-pkg multipart body start == > | | === Info-pkg txt part headers ==== > | | | C-T: text/plain > | | | C-D: foo > | | | > | | === Info-pkg txt part body start = > | | | some text > | | === Info-pkg txt part end ======== > | | === Info-pkg xml part headers ==== > | | | C-T: application/bar > | | | C-D: baz > | | | > | | === Info-pkg xml part body start = > | | | (application/bar stuff) > | | === Info-pkg xml part end ======== > | === Info-pkg multipart end ========= > | === Ext-hdr part headers =========== > | | C-T: application/extension-header > | | C-D: by-reference > | | Content-ID: some-label > | | > | === Ext-hdr part body start ======== > | | (application/extension-header stuff) > | === Ext-hdr part end =============== > === INFO end ========================= > Again, I think you erroneously included a C-D of "info-package" in the SIP header fields. It should appear only on the "multipart/whatever" subpart. /a From pkyzivat@cisco.com Thu Oct 22 14:15:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995F23A6894 for ; Thu, 22 Oct 2009 14:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpzCSA3fzXcc for ; Thu, 22 Oct 2009 14:15:43 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 34CA53A6842 for ; Thu, 22 Oct 2009 14:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3240; q=dns/txt; s=rtpiport02001; t=1256246153; x=1257455753; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2017:15:53=20-0400|Message-ID:=20<4AE0CB89. 8030907@cisco.com>|To:=20Adam=20Roach=20|CC:=20Christer=20Holmberg=20,=0D=0A=20=20=20=20=20=20=20=20"Elwell,=20John"=20< john.elwell@siemens-enterprise.com>,=0D=0A=20=20=20=20=20 =20=20=20SIPCORE=20,=0D=0A=20=20=20=20 =20=20=20=20Gonzalo=20Camarillo=20,=0D=0A=20=20=20=20=20=20=20=20draft-ietf-sipcor e-info-events@tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AE0C7 29.6030108@estacado.net>|References:=20=20< 7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.w w902.siemens.net>=20<4ADDDA50.1050704@cisco.com>=20<74025 09E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902. siemens.net>=20=20<4ADE168F.7060303@cisco.c om>=20=20<4ADE227C.5020500@cisco.com>=20<74 02509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww9 02.siemens.net>=20<4ADF1E49.5030804@cisco.com>=20<7402509 E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.si emens.net>=20<4ADF99E7.4000103@cisco.com>=20=20<4AE05E8C.8050709@cisco.com>=20=20<4AE0 6D32.8010109@cisco.com>=20<4AE0C729.6030108@estacado.net>; bh=/K7camNtKZtQfUlLGCzHQhmk3kGP0NKQscM6akwSzhM=; b=aOqyiF3wdoy5JBlV3E/p7d5EreUf278Ivr3A4vewKJGugwqytnUxFLcd 5DR4FY6jl15MYcZtOYEtj46/cPkIbPYBbGvV9d8icaeK30ra7O54VtcAm 5VvwuXg10wQ9Vb1vyc8Peqpirbo2Q3vjQotgaxWhR4SfnOYNRv0fZ2c09 o=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKpo4EpAZnwM/2dsb2JhbADEJ5hUhD8E X-IronPort-AV: E=Sophos;i="4.44,607,1249257600"; d="scan'208";a="64453269" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2009 21:15:52 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MLFqG1005757; Thu, 22 Oct 2009 21:15:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:15:52 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:15:51 -0400 Message-ID: <4AE0CB89.8030907@cisco.com> Date: Thu, 22 Oct 2009 17:15:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> <4AE06D32.8010109@cisco.com> <4AE0C729.6030108@estacado.net> In-Reply-To: <4AE0C729.6030108@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 21:15:51.0766 (UTC) FILETIME=[D5823F60:01CA535C] Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:15:44 -0000 Adam Roach wrote: > I think some MIME confusion has slipped into Paul's examples. Comments > below. Yes, it wasn't what I intended to say. I did this part of example 2 right once, and then did it over to change the names to be clearer while adding (3), and botched it. :-( To facilitate further discussion, here is a revised version of all the examples: OK, lets draw a few more cases. 1) My case from the earlier message with some names changed to make things clearer: === INFO message headers =========== | INFO ... | C-D: info-pkg | C-T: multipart/whatever | (other headers) | === INFO body start ================ | === Info-pkg txt part headers ==== | | C-T: text/plain | | C-D: foo | | | === Info-pkg txt part body start = | | some text | === Info-pkg txt part end ======== | === Info-pkg xml part headers ==== | | C-T: application/bar | | C-D: baz | | | === Info-pkg xml part body start = | | (application/bar stuff) | === Info-pkg xml part end ======== === INFO end ======================= 2) Your case, where the info package only requires a single text part, but an extension header also requires a part that is unrelated to the info package. === INFO message headers =========== | INFO ... | C-D: render (or none) | C-T: multipart/mixed | Extension-Header: | (other headers) | === INFO body start ================ | === Info-pkg txt part headers ==== | | C-T: text/plain | | C-D: info-package | | | === Info-pkg txt part body start = | | some text | === Info-pkg txt part end ======== | === Ext-hdr part headers ========= | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | === Ext-hdr part body start ====== | | (application/extension-header stuff) | === Ext-hdr part end ============= === INFO end ======================= 3) A combination of the two cases. The stuff "associated with the info package" is again a multipart, just as in the first case, but now it shares the INFO body with a body part for the extension header of the second case. This requires introducing a multipart/mixed just as the 2nd case did === INFO message headers ============= | INFO ... | C-D: render (or none) | C-T: multipart/mixed | Extension-Header: | (other headers) | === INFO body start ================== | === Info-pkg multipart headers ===== | | C-D: info-pkg | | C-T: multipart/whatever | | | === Info-pkg multipart body start == | | === Info-pkg txt part headers ==== | | | C-T: text/plain | | | C-D: foo | | | | | === Info-pkg txt part body start = | | | some text | | === Info-pkg txt part end ======== | | === Info-pkg xml part headers ==== | | | C-T: application/bar | | | C-D: baz | | | | | === Info-pkg xml part body start = | | | (application/bar stuff) | | === Info-pkg xml part end ======== | === Info-pkg multipart end ========= | === Ext-hdr part headers =========== | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | === Ext-hdr part body start ======== | | (application/extension-header stuff) | === Ext-hdr part end =============== === INFO end ========================= From ankriste@cisco.com Thu Oct 22 14:22:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE5B28C181 for ; Thu, 22 Oct 2009 14:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjDVsOIv2DpL for ; Thu, 22 Oct 2009 14:22:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5A73F28C177 for ; Thu, 22 Oct 2009 14:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ankriste@cisco.com; l=3313; q=dns/txt; s=sjiport06001; t=1256246537; x=1257456137; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Anders=20Kristensen=20 |Subject:=20Re:=20[sipcore]=20WGLC=20comments=20(draft-ie tf-sipcore-info-events-01)=20-=0D=0A=20John=20E's=20comme nts=20-=20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu ,=2022=20Oct=202009=2014:22:17=20-0700|Message-ID:=20<4AE 0CD09.4060302@cisco.com>|To:=20Adam=20Roach=20|CC:=20Paul=20Kyzivat=20,=20S IPCORE=20,=0D=0A=20=20=20=20=20=20=20 =20Gonzalo=20Camarillo=20 ,=0D=0A=20=20=20=20=20=20=20=20draft-ietf-sipcore-info-ev ents@tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4AE099 5A.9050906@estacado.net>|References:=20=09< 7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.w w902.siemens.net>=09<4ADDDA50.1050704@cisco.com>=09<74025 09E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902. siemens.net>=09=09<4ADE168F.7060303@cisco.c om>=09=09<4ADE227C.5020500@cisco.com>=09<74 02509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww9 02.siemens.net>=09<4ADF1E49.5030804@cisco.com>=09=09<4ADF63CD.5050707@cisco.com>=09=09 <4ADF9BFC.50007@cisco.com>=20<4AE0995A.9050906@estacado.n et>; bh=nYP0bNEyZqLoandfkfjooKPI4LsY6JfShEfuEz4KV88=; b=FzInEdXeXpVvpuCCKFg4BXC0zNraGrSsVax6gzmao33XGJCSKmC3fkYJ ZuhLT1LVmm9eZqQfHixETGVIBztLNOv/m/rhnIO1NVOO605indeVSejCB x5qp5QcmOYZWar1zS9c/4qXFLvnWeUqjuK3Ary0J+VnIsvmfKHEoaTHcD o=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,608,1249257600"; d="scan'208";a="415526179" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 22 Oct 2009 21:22:17 +0000 Received: from [171.70.217.159] (dhcp-171-70-217-159.cisco.com [171.70.217.159]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9MLMH2H010335; Thu, 22 Oct 2009 21:22:17 GMT Message-ID: <4AE0CD09.4060302@cisco.com> Date: Thu, 22 Oct 2009 14:22:17 -0700 From: Anders Kristensen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> In-Reply-To: <4AE0995A.9050906@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Oct 2009 14:24:19 -0700 Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:22:08 -0000 I think that in this particular example it would be more natural to carry the email as message/rfc822. That's not a multipart type so it amounts to carrying the multipart email as a blob inside some other multipart structure although of course the message/rfc822 body can still be parsed as a multipart body itself... [I've mostly given up on this thread and I don't have an opinion either way so apologies if this is completely off the mark...] Anders Adam Roach wrote: > On 10/21/09 18:40, Oct 21, Paul Kyzivat wrote: >> >> Christer Holmberg wrote: >>> >>> I don't agree. Eventhough I do hear what you are saying, in my opinion >>> "We don't care" goes against what we tried to fix with RFC 5621, and >>> could potentially cause problems. An Info-Package body part shall have >>> C-D 'info-package', and I don't like that fact that we should allow "any >>> value" to be assigned to a body part just because it is transported >>> within a multipart. >> >> IMO its not about overhead, its about layering. >> Consider multiparts used in email, such as for attachments. The >> attachments are often understood by pieces of software independent of >> the email system. >> >> Similarly here. There will be something that receives the info package >> body - that knows that is what it is. But if it has chosen to use >> multipart to consolidate a number of things into it, those might come >> from, and be consumed by independent software. (Considering that INFO >> has been used for tunneling stuff for other protocols, its really easy >> to imagine that.) >> >> The subordinate C-D values may be needed to interpret that stuff. >> >> I think we don't have enough people in this discussion. The two of us >> are just not going to agree. I'd like to hear from Adam who has had a >> lot of insight into multipart in the past, and from Gonzallo, who >> wrote the body handling draft. > > I'm with Paul on this one. By requiring subparts within an INFO > multipart document to be *all* labeled with a C-D of "info-package", > you're removing a lot of flexibility. Suddenly, INFO packages are > disallowed from using C-D on their own multipart subparts to impact > processing. > > Consider a hypothetical INFO package that, for some reason or another, > needed to carry an email message in its body. In this particular case, > consider that the email message contains two attachments: one image > (say, a company logo), and a document. The image is inline in the > sender's signature. The document shouldn't be inlined, but is expected > to be rendered simply as a separate attachment. If we take the approach > Paul & I are advocating, you can properly mark the attachments with > "Content-Disposition: inline" and "Content-Disposition: attachment." > > With your approach, the package would be forced to mark them both with > "Content-Disposition: info-package." It seems like a horrific waste > forcing the redundant "info-package" string down into places where it > (a) adds no additional information and (b) precludes the ability to > *add* useful information. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Thu Oct 22 14:28:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257793A67E3 for ; Thu, 22 Oct 2009 14:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK1ZJVTxA7zW for ; Thu, 22 Oct 2009 14:28:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C8AF53A680F for ; Thu, 22 Oct 2009 14:28:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-d8-4ae0ce928516 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 6D.CE.04191.29EC0EA4; Thu, 22 Oct 2009 23:28:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 23:28:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 23:28:49 +0200 Message-ID: In-Reply-To: <4AE0AA5F.3010308@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTSRjeOzaxIpErR6aiIwksYdkpgQAEp9Eg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 22 Oct 2009 21:28:50.0135 (UTC) FILETIME=[A573EE70:01CA535E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:28:43 -0000 Hi,=20 >>So, if you have a single multipart, with one I-P body part with=20 >>C-D:inline, and one non-I-P body part (may have been inserted by=20 >>someone else), how do you indicate which body part belongs to the I-P? > >I think you've missed something important about my example. Keep in mind that multipart bodies are trees, not flat lists. You would never have the "inline" body part I described on the same level as=20 >something outside the info-package. > >Perhaps diagrams would help. > >In the case I described, the hypothetical INFO package I propose would be structured like this: > >C-T: multipart/related >C-D: info-package > | > +- C-T: text/html > | > +- C-T: image/jpeg > | C-D: inline > | > +- C-T: application/pdf > C-D: attachment > >Now, throw in Paul's example of something like an AIB. According to the way MIME works, the resulting document would look like this: > >C-T: multipart/parallel > | > +- C-T: multipart/related > | C-D: info-package > | | > | +- C-T: text/html > | | > | +- C-T: image/jpeg > | | C-D: inline > | | > | +- C-T: application/pdf > | C-D: attachment > | > +- C-T: message/sipfrag >C-D: aib Yes, but what about if there is only I-P ONE body part (e.g. image/jpeg), plus the aib body part. Will you use the multipart/related body part with that single I-P body part only? C-T: multipart/parallel | +- C-T: multipart/related | C-D: info-package | | | +- C-T: image/jpeg | C-D: inline | +- C-T: message/sipfrag C-D: aib If so, I don't think that is what Paul proposed. He proposed: C-T: multipart/parallel | +- C-T: image/jpeg | C-D: info-package | =20 +- C-T: message/sipfrag C-D: aib Note that the C-D value has now changed from 'inline' to 'info-package' in order to distinguish the I-P body part from the rest. That is bad, in my opinion. (Maybe I missunderstood Paul, and in that case I appologize, but that is how he showed it in one of his pictures.) >It's pretty clear, on a casual inspection, that the text/html, image/jpeg, and application/pdf are all part of the information related to the info-package, because they all have an ancestor marked with a=20 >C-D of "info-package". Similarly, the message/sipfrag clearly is not part of the info-package, because it does *not* have an ancestor marked as "info-package". > >If I read it correctly, your proposal would require the image/jpeg and application/pdf to both be marked with a C-D of "info-package", even though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In=20 >doing so, you wipe out the ability to indicate applicable C-Ds like "inline". My assumption has been that the body part payload contains information what the application is supposed to do with it. But, the important thing is to agree on something that works. But, I hope that it wouldn't mean that one is not allowed to use C-D 'info-package' for a non-multipart body part, in case the payload contains information on how the application is supposed to process it. Regards, Christer From christer.holmberg@ericsson.com Thu Oct 22 14:40:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CADBE28C1C7 for ; Thu, 22 Oct 2009 14:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soj8PN3OXKVI for ; Thu, 22 Oct 2009 14:40:49 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2F08128C1C4 for ; Thu, 22 Oct 2009 14:40:48 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-f5-4ae0d169d66b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 02.6B.08816.961D0EA4; Thu, 22 Oct 2009 23:40:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 23:40:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Oct 2009 23:40:15 +0200 Message-ID: In-Reply-To: <4AE0CB89.8030907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTXOEHSycq93xHR6S3SyTibcDdlAAAl5wg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> <4AE06D32.8010109@cisco.com> <4AE0C729.6030108@estacado.net> <4AE0CB89.8030907@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 22 Oct 2009 21:40:16.0552 (UTC) FILETIME=[3E96DA80:01CA5360] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:40:51 -0000 Hi Paul, Sometimes in your example you use C-D 'foo' for the text/plain body part, and sometime you use C-D 'info-package' for text/plan. My understanding of what Adam is saying that an I-P body part (non-multipart) should be allowed to have any C-D value, and in that case I don't think we can change the value depending on where the body part is located. For example, the I-P specification may say that text/plain can have either C-D 'foo' and 'baz', and it is important that the remote application gets that information. Then you can't change it to 'info-package'. Now, if would assume that all I-P body parts have C-D 'info-package' it would not be a problem - but that is not what Adam says. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 23. lokakuuta 2009 0:16 To: Adam Roach Cc: Christer Holmberg; Elwell, John; SIPCORE; Gonzalo Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Adam Roach wrote: > I think some MIME confusion has slipped into Paul's examples. Comments > below. Yes, it wasn't what I intended to say. I did this part of example 2 right once, and then did it over to change the names to be clearer while adding (3), and botched it. :-( To facilitate further discussion, here is a revised version of all the examples: OK, lets draw a few more cases. 1) My case from the earlier message with some names changed to make things clearer: =3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | INFO ... | C-D: info-pkg | C-T: multipart/whatever | (other headers) | =3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D | | C-T: text/plain | | C-D: foo | | | =3D=3D=3D Info-pkg txt part body start =3D | | some text | =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Info-pkg xml part headers =3D=3D=3D=3D | | C-T: application/bar | | C-D: baz | | | =3D=3D=3D Info-pkg xml part body start =3D | | (application/bar stuff) | =3D=3D=3D Info-pkg xml part end =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) Your case, where the info package only requires a single text part, but an extension header also requires a part that is unrelated to the info package. =3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | INFO ... | C-D: render (or none) | C-T: multipart/mixed | Extension-Header: | (other headers) | =3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D | | C-T: text/plain | | C-D: info-package | | | =3D=3D=3D Info-pkg txt part body start =3D | | some text | =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Ext-hdr part headers =3D=3D=3D=3D=3D=3D=3D=3D=3D | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | =3D=3D=3D Ext-hdr part body start =3D=3D=3D=3D=3D=3D | | (application/extension-header stuff) | =3D=3D=3D Ext-hdr part end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3) A combination of the two cases. The stuff "associated with the info package" is again a multipart, just as in the first case, but now it shares the INFO body with a body part for the extension header of the second case. This requires introducing a multipart/mixed just as the 2nd case did =3D=3D=3D INFO message headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | INFO ... | C-D: render (or none) | C-T: multipart/mixed | Extension-Header: | (other headers) | =3D=3D=3D INFO body start = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Info-pkg multipart headers =3D=3D=3D=3D=3D | | C-D: info-pkg | | C-T: multipart/whatever | | | =3D=3D=3D Info-pkg multipart body start =3D=3D | | =3D=3D=3D Info-pkg txt part headers =3D=3D=3D=3D | | | C-T: text/plain | | | C-D: foo | | | | | =3D=3D=3D Info-pkg txt part body start =3D | | | some text | | =3D=3D=3D Info-pkg txt part end =3D=3D=3D=3D=3D=3D=3D=3D | | =3D=3D=3D Info-pkg xml part headers =3D=3D=3D=3D | | | C-T: application/bar | | | C-D: baz | | | | | =3D=3D=3D Info-pkg xml part body start =3D | | | (application/bar stuff) | | =3D=3D=3D Info-pkg xml part end =3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Info-pkg multipart end =3D=3D=3D=3D=3D=3D=3D=3D=3D | =3D=3D=3D Ext-hdr part headers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | C-T: application/extension-header | | C-D: by-reference | | Content-ID: some-label | | | =3D=3D=3D Ext-hdr part body start =3D=3D=3D=3D=3D=3D=3D=3D | | (application/extension-header stuff) | =3D=3D=3D Ext-hdr part end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D INFO end = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= From pkyzivat@cisco.com Thu Oct 22 14:46:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E6828C1EE for ; Thu, 22 Oct 2009 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiS94yAeVJxE for ; Thu, 22 Oct 2009 14:46:11 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 99D1F28C1E7 for ; Thu, 22 Oct 2009 14:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3734; q=dns/txt; s=rtpiport02001; t=1256247974; x=1257457574; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2017:46:14=20-0400|Message-ID:=20<4AE0D2A6. 8090007@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20"Elwell,=20John"=20< john.elwell@siemens-enterprise.com>,=0D=0A=20=20=20=20=20 =20=20=20SIPCORE=20,=0D=0A=20=20=20=20 =20=20=20=20Gonzalo=20Camarillo=20,=0D=0A=20=20=20=20=20=20=20=20draft-ietf-sipcor e-info-events@tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20=20<7402509E63C5A145A 6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> =20<4ADDDA50.1050704@cisco.com>=20<7402509E63C5A145A6095D 46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net>=20=20<4ADE168F.7060303@cisco.com>=20=20<4ADE227C.5020500@cisco.com>=20<7402509E63C5A145A60 95D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> =20<4ADF1E49.5030804@cisco.com>=20=20<4ADF6 3CD.5050707@cisco.com>=20=20<4ADF9BFC.50007 @cisco.com>=20<4AE0995A.9050906@estacado.net>=20=20<4AE0AA5F.3010308@estacado.net>=20; bh=oPWBmpKN25y8gg9x9TctLhS4lZckqjDFWW8Z+Xt9b5c=; b=bkfoldV/guQd3sz1AIzWGjs1+hUbbuYmiA5a1Tp16VX4gw6V7wR9bx7o 9EaT9+OyEqQisXFPaJQ4HC97JHTYUkLj0oHFcq+ybCqcIYoKeowpAcnbg AXQKlHd7ZWQkNXu5sdOBFu15j5CHhW1mU3AP339YdiRDAb1CTKmSnyl6E M=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALNv4EpAZnwN/2dsb2JhbADEEJhUhD8E X-IronPort-AV: E=Sophos;i="4.44,608,1249257600"; d="scan'208";a="64456558" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2009 21:46:13 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MLkD0q003858; Thu, 22 Oct 2009 21:46:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:46:13 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:46:12 -0400 Message-ID: <4AE0D2A6.8090007@cisco.com> Date: Thu, 22 Oct 2009 17:46:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 21:46:12.0469 (UTC) FILETIME=[12BB7A50:01CA5361] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:46:12 -0000 Christer Holmberg wrote: > Hi, > >>> So, if you have a single multipart, with one I-P body part with >>> C-D:inline, and one non-I-P body part (may have been inserted by >>> someone else), how do you indicate which body part belongs to the I-P? >> I think you've missed something important about my example. Keep in > mind that multipart bodies are trees, not flat lists. You would never > have the "inline" body part I described on the same level as >> something outside the info-package. >> >> Perhaps diagrams would help. >> >> In the case I described, the hypothetical INFO package I propose would > be structured like this: >> C-T: multipart/related >> C-D: info-package >> | >> +- C-T: text/html >> | >> +- C-T: image/jpeg >> | C-D: inline >> | >> +- C-T: application/pdf >> C-D: attachment >> >> Now, throw in Paul's example of something like an AIB. According to the > way MIME works, the resulting document would look like this: >> C-T: multipart/parallel >> | >> +- C-T: multipart/related >> | C-D: info-package >> | | >> | +- C-T: text/html >> | | >> | +- C-T: image/jpeg >> | | C-D: inline >> | | >> | +- C-T: application/pdf >> | C-D: attachment >> | >> +- C-T: message/sipfrag >> C-D: aib > > Yes, but what about if there is only I-P ONE body part (e.g. > image/jpeg), plus the aib body part. Will you use the multipart/related > body part with that single I-P body part only? > > C-T: multipart/parallel > | > +- C-T: multipart/related > | C-D: info-package > | | > | +- C-T: image/jpeg > | C-D: inline > | > +- C-T: message/sipfrag > C-D: aib > > If so, I don't think that is what Paul proposed. He proposed: > > C-T: multipart/parallel > | > +- C-T: image/jpeg > | C-D: info-package > | > +- C-T: message/sipfrag > C-D: aib > > Note that the C-D value has now changed from 'inline' to 'info-package' > in order to distinguish the I-P body part from the rest. That is bad, in > my opinion. I think you can use either of the above, depending on your needs. (But the choice will be in the specification of the particular info package, not by the developer.) You would use the first if the C-D:inline is important to preserve, and the second if it is not. > (Maybe I missunderstood Paul, and in that case I appologize, but that is > how he showed it in one of his pictures.) In this case you did understand me. >> It's pretty clear, on a casual inspection, that the text/html, > image/jpeg, and application/pdf are all part of the information related > to the info-package, because they all have an ancestor marked with a >> C-D of "info-package". Similarly, the message/sipfrag clearly is not > part of the info-package, because it does *not* have an ancestor marked > as "info-package". >> If I read it correctly, your proposal would require the image/jpeg and > application/pdf to both be marked with a C-D of "info-package", even > though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In >> doing so, you wipe out the ability to indicate applicable C-Ds like > "inline". > > My assumption has been that the body part payload contains information > what the application is supposed to do with it. But, the important thing > is to agree on something that works. > > But, I hope that it wouldn't mean that one is not allowed to use C-D > 'info-package' for a non-multipart body part, in case the payload > contains information on how the application is supposed to process it. That should be perfectly fine, and I think will be the common case. Thanks, Paul From pkyzivat@cisco.com Thu Oct 22 14:51:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBAA628C147 for ; Thu, 22 Oct 2009 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYg3Sf1oRd53 for ; Thu, 22 Oct 2009 14:51:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5061A3A69EB for ; Thu, 22 Oct 2009 14:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=5303; q=dns/txt; s=rtpiport02001; t=1256248311; x=1257457911; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Kyzivat=20|Subject: =20Re:=20[sipcore]=20WGLC=20comments=20(draft-ietf-sipcor e-info-events-01)=20-=0D=0A=20John=20E's=20comments=20- =20non-I-P=20body=20parts=20in=20INFO?|Date:=20Thu,=2022 =20Oct=202009=2017:51:52=20-0400|Message-ID:=20<4AE0D3F8. 8080702@cisco.com>|To:=20Christer=20Holmberg=20|CC:=20Adam=20Roach=20,=0D=0A=20=20=20=20=20=20=20=20"Elwell,=20John"=20< john.elwell@siemens-enterprise.com>,=0D=0A=20=20=20=20=20 =20=20=20SIPCORE=20,=0D=0A=20=20=20=20 =20=20=20=20Gonzalo=20Camarillo=20,=0D=0A=20=20=20=20=20=20=20=20draft-ietf-sipcor e-info-events@tools.ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References:=20=20<4ADDDA50.1050704@ cisco.com>=20<7402509E63C5A145A6095D46C179A5B7148B2BA9@DE MCHP99E35MSX.ww902.siemens.net>=20=20<4ADE1 68F.7060303@cisco.com>=20=20<4ADE227C.50205 00@cisco.com>=20<7402509E63C5A145A6095D46C179A5B7148B2BC4 @DEMCHP99E35MSX.ww902.siemens.net>=20<4ADF1E49.5030804@ci sco.com>=20<7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMC HP99E35MSX.ww902.siemens.net>=20<4ADF99E7.4000103@cisco.c om>=20=20<4AE05E8C.8050709@cisco.com>=20=20<4AE06D32.8010109@cisco.com>=20<4AE0C729.60 30108@estacado.net>=20<4AE0CB89.8030907@cisco.com>=20; bh=JR1E4Qazx/H+hauBDYmDBFRcLR4uzbAuLXISET3Fns8=; b=iahT8StBjEk3N0CrXgjzXjfJklScI/Qbu8yuQxDkwbebnCg9Y3owlZ0b wpaTEglqtrACgljVmPaxnFEm1qo4xhVbUyVn7L9sqVr8F4QiwgxqZ9jHN TcBgG4Taje88q0pT8bxdVqzyLpGkXnDuWpcKuyh4WA+j3pZIOXNfNGHDc A=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGZw4EpAZnwM/2dsb2JhbADEEJhVhD8E X-IronPort-AV: E=Sophos;i="4.44,608,1249257600"; d="scan'208";a="64457400" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Oct 2009 21:51:50 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MLpoNU022398; Thu, 22 Oct 2009 21:51:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:51:50 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 17:51:50 -0400 Message-ID: <4AE0D3F8.8080702@cisco.com> Date: Thu, 22 Oct 2009 17:51:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2E0F@DEMCHP99E35MSX.ww902.siemens.net> <4ADF99E7.4000103@cisco.com> <4AE05E8C.8050709@cisco.com> <4AE06D32.8010109@cisco.com> <4AE0C729.6030108@estacado.net> <4AE0CB89.8030907@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2009 21:51:50.0085 (UTC) FILETIME=[DBF79750:01CA5361] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 21:51:42 -0000 Christer Holmberg wrote: > Hi Paul, > > Sometimes in your example you use C-D 'foo' for the text/plain body > part, and sometime you use C-D 'info-package' for text/plan. I used 'foo' (or some other random string) when my point was that it didn't matter. I used info-package when it needed to be that. > My understanding of what Adam is saying that an I-P body part > (non-multipart) should be allowed to have any C-D value, and in that > case I don't think we can change the value depending on where the body > part is located. See my comment to your other message about that. > For example, the I-P specification may say that text/plain can have > either C-D 'foo' and 'baz', and it is important that the remote > application gets that information. Then you can't change it to > 'info-package'. The info package specification will have to start with the understanding that the top of the body part tree that belongs to it *always* starts with C-D of info-package. If that tree is just a trunk with no branches, then that is all there is. If the particular info package permits that body to be a multipart, then it will also have to specify what kind of multipart and what the C-Ds of the branches may be. Thanks, Paul > Now, if would assume that all I-P body parts have C-D 'info-package' it > would not be a problem - but that is not what Adam says. > > Regards, > > Christer > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 23. lokakuuta 2009 0:16 > To: Adam Roach > Cc: Christer Holmberg; Elwell, John; SIPCORE; Gonzalo Camarillo; > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) > - John E's comments - non-I-P body parts in INFO? > > > > Adam Roach wrote: >> I think some MIME confusion has slipped into Paul's examples. Comments > >> below. > > Yes, it wasn't what I intended to say. I did this part of example 2 > right once, and then did it over to change the names to be clearer while > adding (3), and botched it. :-( > > To facilitate further discussion, here is a revised version of all the > examples: > > OK, lets draw a few more cases. > > 1) My case from the earlier message with some names changed to make > things clearer: > > === INFO message headers =========== > | INFO ... > | C-D: info-pkg > | C-T: multipart/whatever > | (other headers) > | > === INFO body start ================ > | === Info-pkg txt part headers ==== > | | C-T: text/plain > | | C-D: foo > | | > | === Info-pkg txt part body start = > | | some text > | === Info-pkg txt part end ======== > | === Info-pkg xml part headers ==== > | | C-T: application/bar > | | C-D: baz > | | > | === Info-pkg xml part body start = > | | (application/bar stuff) > | === Info-pkg xml part end ======== > === INFO end ======================= > > 2) Your case, where the info package only requires a single text part, > but an extension header also requires a part that is unrelated to the > info package. > > === INFO message headers =========== > | INFO ... > | C-D: render (or none) > | C-T: multipart/mixed > | Extension-Header: > | (other headers) > | > === INFO body start ================ > | === Info-pkg txt part headers ==== > | | C-T: text/plain > | | C-D: info-package > | | > | === Info-pkg txt part body start = > | | some text > | === Info-pkg txt part end ======== > | === Ext-hdr part headers ========= > | | C-T: application/extension-header > | | C-D: by-reference > | | Content-ID: some-label > | | > | === Ext-hdr part body start ====== > | | (application/extension-header stuff) > | === Ext-hdr part end ============= > === INFO end ======================= > > > 3) A combination of the two cases. The stuff "associated with the info > package" is again a multipart, just as in the first case, but now it > shares the INFO body with a body part for the extension header of the > second case. This requires introducing a multipart/mixed just as the 2nd > case did > > === INFO message headers ============= > | INFO ... > | C-D: render (or none) > | C-T: multipart/mixed > | Extension-Header: > | (other headers) > | > === INFO body start ================== > | === Info-pkg multipart headers ===== > | | C-D: info-pkg > | | C-T: multipart/whatever > | | > | === Info-pkg multipart body start == > | | === Info-pkg txt part headers ==== > | | | C-T: text/plain > | | | C-D: foo > | | | > | | === Info-pkg txt part body start = > | | | some text > | | === Info-pkg txt part end ======== > | | === Info-pkg xml part headers ==== > | | | C-T: application/bar > | | | C-D: baz > | | | > | | === Info-pkg xml part body start = > | | | (application/bar stuff) > | | === Info-pkg xml part end ======== > | === Info-pkg multipart end ========= > | === Ext-hdr part headers =========== > | | C-T: application/extension-header > | | C-D: by-reference > | | Content-ID: some-label > | | > | === Ext-hdr part body start ======== > | | (application/extension-header stuff) > | === Ext-hdr part end =============== > === INFO end ========================= > > From christer.holmberg@ericsson.com Thu Oct 22 15:05:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F57F3A67DA for ; Thu, 22 Oct 2009 15:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAZUDjNadKT4 for ; Thu, 22 Oct 2009 15:05:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E05653A67C0 for ; Thu, 22 Oct 2009 15:05:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-32-4ae0d749c225 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 83.E4.24026.947D0EA4; Fri, 23 Oct 2009 00:06:01 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 00:05:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 00:05:05 +0200 Message-ID: In-Reply-To: <4AE0D2A6.8090007@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpTYRVYpkYVtJtfQ6mlET7Tzecl3gAANtsw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE0D2A6. 8090007@ cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 22 Oct 2009 22:05:06.0756 (UTC) FILETIME=[B6D1F040:01CA5363] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 22:05:54 -0000 Hi,=20 >>>>So, if you have a single multipart, with one I-P body part with=20 >>>>C-D:inline, and one non-I-P body part (may have been inserted by=20 >>>>someone else), how do you indicate which body part belongs to the I-P? >>>>I think you've missed something important about my example. Keep in >>>>mind that multipart bodies are trees, not flat lists. You would never=20 >>>>have the "inline" body part I described on the same level as >>>>something outside the info-package. >>> >>>Perhaps diagrams would help. >>> >>>In the case I described, the hypothetical INFO package I propose would >>>be structured like this: >>>C-T: multipart/related >>>C-D: info-package >>> | >>> +- C-T: text/html >>> | >>> +- C-T: image/jpeg >>> | C-D: inline >>> | >>> +- C-T: application/pdf >>> C-D: attachment >>> >>>Now, throw in Paul's example of something like an AIB. According to=20 >>>the way MIME works, the resulting document would look like this: >>>C-T: multipart/parallel >>> | >>> +- C-T: multipart/related >>> | C-D: info-package >>> | | >>> | +- C-T: text/html >>> | | >>> | +- C-T: image/jpeg >>> | | C-D: inline >>> | | >>> | +- C-T: application/pdf >>> | C-D: attachment >>> | >>> +- C-T: message/sipfrag >>> C-D: aib >>=20 >>Yes, but what about if there is only I-P ONE body part (e.g. >>image/jpeg), plus the aib body part. Will you use the=20 >>multipart/related body part with that single I-P body part only? >>=20 >>C-T: multipart/parallel >> | >> +- C-T: multipart/related >> | C-D: info-package >> | | >> | +- C-T: image/jpeg >> | C-D: inline >> | >> +- C-T: message/sipfrag >> C-D: aib >>=20 >>If so, I don't think that is what Paul proposed. He proposed: >>=20 >>C-T: multipart/parallel >> | >> +- C-T: image/jpeg >> | C-D: info-package >> | =20 >> +- C-T: message/sipfrag >>C-D: aib >>=20 >>Note that the C-D value has now changed from 'inline' to 'info-package' >>in order to distinguish the I-P body part from the rest. That is bad,=20 >>in my opinion. > >I think you can use either of the above, depending on your needs. >(But the choice will be in the specification of the particular info package, not by the developer.) > >You would use the first if the C-D:inline is important to preserve, and the second if it is not. IF we, as suggested by Adam, allow different C-D values for I-P body parts, I REALLY think we shall ASSUME and REQUIRE that they SHALL be preserved. I am pretty sure that is how other applications work also... Otherwise we are really begging for interop problems, in my opinion. And, if the C-D value really doesn't matter to the remote application then one should use 'info-package'. I don't want specification text saying "Use whatver C-D value you want - noone cares anyway" :) >>It's pretty clear, on a casual inspection, that the text/html, >>image/jpeg, and application/pdf are all part of the information=20 >>related to the info-package, because they all have an ancestor marked=20 >>with a C-D of "info-package". Similarly, the message/sipfrag clearly is not >>part of the info-package, because it does *not* have an ancestor=20 >>marked as "info-package". >>If I read it correctly, your proposal would require the image/jpeg=20 >>and application/pdf to both be marked with a C-D of "info-package", even=20 >>though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In >>doing so, you wipe out the ability to indicate applicable C-Ds like >>"inline". >>=20 >>My assumption has been that the body part payload contains information >>what the application is supposed to do with it. But, the important=20 >>thing is to agree on something that works. >>=20 >>But, I hope that it wouldn't mean that one is not allowed to use C-D=20 >>'info-package' for a non-multipart body part, in case the payload=20 >>contains information on how the application is supposed to process it. > >That should be perfectly fine, and I think will be the common case. My proposal would then be to say that, by default, C-D 'info-package' is assigned to all I-P body parts, but that I-P specifications are allowed to define the usage values to be used also, as suggested by Adam (unless I missunderstood him also :) Regards, Christer From brett@broadsoft.com Fri Oct 23 05:05:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F2F3A6358 for ; Fri, 23 Oct 2009 05:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPJo3vyQDvGU for ; Fri, 23 Oct 2009 05:05:57 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id BC4C93A688B for ; Fri, 23 Oct 2009 05:05:57 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 23 Oct 2009 05:06:06 -0700 From: Brett Tate To: Christer Holmberg Date: Fri, 23 Oct 2009 05:05:58 -0700 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAIgm1eA= Message-ID: <747A6506A991724FB09B129B79D5FEB613ABA149DB@EXMBXCLUS01.citservers.local> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> 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 Cc: SIPCORE , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 12:05:58 -0000 > >>>11. In 5.2, why is Recv-Info allowed in NOTIFY request/response and > in > >>>REFER request? These doesn't related to invite dialog usages. > >> > >>See separate thread. > >[JRE] I couldn't find any discussion of Recv-Info in REFER and NOTIFY. > Can you point me at a particular message in that thread? >=20 > Sorry, I didn't mean that there was a separate thread dedicated to that > particular issue. But, Robert had the same comment, and I addresses it > in my of my replies on his comments. >=20 > But, I HAVE removed Recv-Info from REF and NOT, because I can't > remember > why they were put there. >=20 > ANYONE WHO REMEMBERS WHY THEY WERE PUT THERE, PLEASE SPEAK NOW OR > FOREVER SEND YOUR REFERS WITHOUT INFO PACKAGES! :) They were likely added as a result of my "draft-ietf-sip-info-events-03: co= mments and questions" thread from last February/March. Back then it was un= clear where the header was required to avoid accidentally indicating that y= ou no longer support the draft/packages communicated by Recv-Info earlier w= ithin the dialog. http://www.ietf.org/mail-archive/web/sip/current/msg26846.html From christer.holmberg@ericsson.com Fri Oct 23 05:14:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109E33A6836 for ; Fri, 23 Oct 2009 05:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4miHGY1CmTrK for ; Fri, 23 Oct 2009 05:14:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B0C623A6849 for ; Fri, 23 Oct 2009 05:14:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-2e-4ae19e41e661 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7B.81.24026.14E91EA4; Fri, 23 Oct 2009 14:14:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:14:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 14:12:07 +0200 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613ABA149DB@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAIgm1eAAAVBpAA== References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <747A6506A991724FB09B129B79D5FEB613ABA149DB@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" X-OriginalArrivalTime: 23 Oct 2009 12:14:02.0125 (UTC) FILETIME=[4EAA73D0:01CA53DA] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) -John E's comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 12:14:53 -0000 Hi Brett, The draft currently says that you use 'Recv-Info: nil' to indicate that you no longer want to receive INFO requests associated with an Info Package. Regards, Christer > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: 23. lokakuuta 2009 15:06 > To: Christer Holmberg > Cc: draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE > Subject: RE: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) -John E's comments >=20 > > >>>11. In 5.2, why is Recv-Info allowed in NOTIFY=20 > request/response and > > in > > >>>REFER request? These doesn't related to invite dialog usages. > > >> > > >>See separate thread. > > >[JRE] I couldn't find any discussion of Recv-Info in REFER=20 > and NOTIFY. > > Can you point me at a particular message in that thread? > >=20 > > Sorry, I didn't mean that there was a separate thread dedicated to=20 > > that particular issue. But, Robert had the same comment, and I=20 > > addresses it in my of my replies on his comments. > >=20 > > But, I HAVE removed Recv-Info from REF and NOT, because I can't=20 > > remember why they were put there. > >=20 > > ANYONE WHO REMEMBERS WHY THEY WERE PUT THERE, PLEASE SPEAK NOW OR=20 > > FOREVER SEND YOUR REFERS WITHOUT INFO PACKAGES! :) >=20 > They were likely added as a result of my=20 > "draft-ietf-sip-info-events-03: comments and questions"=20 > thread from last February/March. Back then it was unclear=20 > where the header was required to avoid accidentally=20 > indicating that you no longer support the draft/packages=20 > communicated by Recv-Info earlier within the dialog. >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg26846.html >=20 >=20 From christer.holmberg@ericsson.com Fri Oct 23 06:36:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E423A68E5 for ; Fri, 23 Oct 2009 06:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChGYvDZqCjl2 for ; Fri, 23 Oct 2009 06:36:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 166E93A68B7 for ; Fri, 23 Oct 2009 06:36:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-b5-4ae1b172c1de Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B9.04.04191.271B1EA4; Fri, 23 Oct 2009 15:36:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 15:36:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA53E5.85F3BA67" Date: Fri, 23 Oct 2009 15:34:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sipcore-info-events-02 (based on WGLC comments) Thread-Index: AcpT5YWINu1OVMn8Rc+wLEQeSANTRg== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 23 Oct 2009 13:36:28.0204 (UTC) FILETIME=[D2C236C0:01CA53E5] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , Gonzalo Camarillo Subject: [sipcore] Draft new version: draft-ietf-sipcore-info-events-02 (based on WGLC comments) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:36:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53E5.85F3BA67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on a long (but good) list of WGLC comments, and e-mail discussions, I've put together a new version of the info-events draft. - Some sections have been moved (why the section numbering has also changed), and some sections have again had major editorial changes. - I've tried to list the major functional changes in the change log, but it is not possible to list all editorial changes. Now, there are a few WGLC comments which have yet *not* been fully implemented: ------------------------------------------------------------------------ -------------------------------------------------- - Robert S had some comments, which I still need to look into, and may need help and guidance from others for: - IANA impacts regarding what specifications are needed in order to register an Info-Package. Input from others is appretiated. - 2119 wording. I have tried to get rid of some of the uppercase usages of MUST, SHALL etc, but I would need help and guidance from others. - Robert S also had some comments, which I had some issues/questions with, and replied to Robert about. - Text about the UAC being able to receive INFO before the first end-to-end provisional response. - Add "name" after "Recv-Info header filed" in old section 8.2. - There is still a discussion with regarding the usage of Content-Disposition and Content-Type. I have tried to clarify the existing text, but it may change based on the outcome of the discussions. NOTE: I have submitted the draft to IETF, but for some reason I have not yet received the verification e-mail, so I don't know when it will appear in the IETF archieve. But ,the draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-info-events-02 .txt Regards, Christer ------_=_NextPart_001_01CA53E5.85F3BA67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sipcore-info-events-02 (based on = WGLC comments)

Hi,

Based on a long (but good) list of WGLC = comments, and e-mail discussions, I've put together a new version of the = info-events draft.

- Some sections have been moved (why = the section numbering has also changed), and some sections have again = had major editorial changes.

- I've tried to list the major = functional changes in the change log, but it is not possible to list all = editorial changes.


Now, there are a few WGLC comments = which have yet *not* been fully implemented:
----------------------------------------------------------= ----------------------------------------------------------------

- Robert S had some comments, which I = still need to look into, and may need help and guidance from others = for:
        - IANA impacts regarding what specifications are needed = in order to register an Info-Package. Input from others is = appretiated.

        - 2119 wording. I have tried to get rid of some of the = uppercase usages of MUST, SHALL etc, but I would need help and guidance = from others.

- Robert S also had some comments, = which I had some issues/questions with, and replied to Robert = about.
        - Text about the UAC being able to receive INFO before = the first end-to-end provisional response.
        - Add "name" after "Recv-Info header = filed" in old section 8.2.

- There is still a discussion with = regarding the usage of Content-Disposition and Content-Type. I have = tried to clarify the existing text, but it may change based on the = outcome of the discussions.

NOTE: I have submitted the draft to = IETF, but for some reason I have not yet received the verification = e-mail, so I don't know when it will appear in the IETF = archieve.

But ,the draft can also be found = at:

http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-= info-events-02.txt

Regards,

Christer

------_=_NextPart_001_01CA53E5.85F3BA67-- From root@core3.amsl.com Fri Oct 23 14:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D8C3428C110; Fri, 23 Oct 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023211501.D8C3428C110@core3.amsl.com> Date: Fri, 23 Oct 2009 14:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : E. Burger, et al. Filename : draft-ietf-sipcore-info-events-02.txt Pages : 34 Date : 2009-10-23 This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-info-events-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23140953.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Fri Oct 23 15:08:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE4628C0E5 for ; Fri, 23 Oct 2009 15:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLB68eEYcX7J for ; Fri, 23 Oct 2009 15:08:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 20FC828B797 for ; Fri, 23 Oct 2009 15:08:33 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB/G4UqrR7H+/2dsb2JhbADCLpgthD8E X-IronPort-AV: E=Sophos;i="4.44,614,1249257600"; d="scan'208";a="416466148" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Oct 2009 22:08:44 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9NM8hc9012719; Fri, 23 Oct 2009 22:08:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 18:08:43 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 18:08:43 -0400 Message-ID: <4AE2296D.7040503@cisco.com> Date: Fri, 23 Oct 2009 18:08:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> In-Reply-To: <4AE0AA5F.3010308@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Oct 2009 22:08:43.0195 (UTC) FILETIME=[623DA8B0:01CA542D] Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 22:08:34 -0000 Thanks Adam. We are on the same page here. And I knew you would elaborate on the proper use of various multipart types. I think we can go further here. In an INFO message, *the* body part associated with the info package named in message will *always* be found in one of the following places: - it is the entire body of the message, with C-D:info-package among the sip headers. - the body body of the info message is C-T multipart/mixed (or some other variant of multipart, adam?) and C-D is "render" or the C-D is missing. And then one, and only one, of the immediate child parts of that multipart will have C-D:info-package and be the one. AFAIK there are no other possibilities that make any sense here. Thanks, Paul Adam Roach wrote: > On 10/22/09 12:58, Oct 22, Christer Holmberg wrote: >> So, if you have a single multipart, with one I-P body part with >> C-D:inline, and one non-I-P body part (may have been inserted by >> someone else), how do you indicate which body part belongs to the I-P? > > I think you've missed something important about my example. Keep in mind > that multipart bodies are trees, not flat lists. You would never have > the "inline" body part I described on the same level as something > outside the info-package. > > Perhaps diagrams would help. > > In the case I described, the hypothetical INFO package I propose would > be structured like this: > > C-T: multipart/related > C-D: info-package > | > +- C-T: text/html > | > +- C-T: image/jpeg > | C-D: inline > | > +- C-T: application/pdf > C-D: attachment > > Now, throw in Paul's example of something like an AIB. According to the > way MIME works, the resulting document would look like this: > > C-T: multipart/parallel > | > +- C-T: multipart/related > | C-D: info-package > | | > | +- C-T: text/html > | | > | +- C-T: image/jpeg > | | C-D: inline > | | > | +- C-T: application/pdf > | C-D: attachment > | > +- C-T: message/sipfrag > C-D: aib > > It's pretty clear, on a casual inspection, that the text/html, > image/jpeg, and application/pdf are all part of the information related > to the info-package, because they all have an ancestor marked with a C-D > of "info-package". Similarly, the message/sipfrag clearly is not part of > the info-package, because it does *not* have an ancestor marked as > "info-package". > > If I read it correctly, your proposal would require the image/jpeg and > application/pdf to both be marked with a C-D of "info-package", even > though doing so is *USELESS*, *REDUNDANT*, and *HARMFUL*. In doing so, > you wipe out the ability to indicate applicable C-Ds like "inline". > > /a > From christian.vogt@ericsson.com Fri Oct 23 18:11:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC57B3A685E; Fri, 23 Oct 2009 18:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3fnIhD6w5r8; Fri, 23 Oct 2009 18:11:54 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DD8333A683A; Fri, 23 Oct 2009 18:11:53 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9O1Bsxd004998; Fri, 23 Oct 2009 20:11:54 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 20:11:07 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 20:11:07 -0500 Received: from eharopa-t5400.eamcs.ericsson.se (147.117.20.212) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Fri, 23 Oct 2009 21:11:06 -0400 MIME-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset="us-ascii"; format=flowed; delsp=yes From: Christian Vogt In-Reply-To: Date: Fri, 23 Oct 2009 18:11:41 -0700 Content-Transfer-Encoding: 7bit Message-ID: <760DD414-61AA-4A71-8477-43FD9A99E736@ericsson.com> References: <572B7D13-422D-412E-8D9C-A07693B629E3@ericsson.com> To: Avshalom Houri X-Mailer: Apple Mail (2.1076) X-OriginalArrivalTime: 24 Oct 2009 01:11:07.0557 (UTC) FILETIME=[DD96C550:01CA5446] X-Mailman-Approved-At: Fri, 23 Oct 2009 21:55:05 -0700 Cc: "RjS@nostrum.com" , "vs2140@cs.columbia.edu" , "aoki@aol.net" , "hgs+ecrit@cs.columbia.edu" , Gen-ART Mailing List , "sipcore@ietf.org" , "Sriram.Parameswar@microsoft.com" Subject: Re: [sipcore] [Gen-art] Gen-ART review of draft-ietf-sipcore-presence-scaling-requirements-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 01:11:54 -0000 On Sep 23, 2009, Avshalom Houri wrote: > > - It would be worth mentioning in the introduction of the document > what > > the expected result of this document should be. Obviously, we > are > > expecting (or hoping for) an improvement in the scalability of > > SIP/SIMPLE, but this should be made explicit. Also, do we have > > estimates of how much SIP/SIMPLE will improve? > > These are defined by the requirements themselves specifically in 3.3. Right. But it would be useful if this was explained even earlier in the document. How about changing the first paragraph of the introduction as follows: OLD The document lists requirements for optimizations of the SIP/SIMPLE protocol. See [I-D.ietf-simple-simple] for the list of RFCs and drafts that are considered as part of the SIP/SIMPLE protocol. These optimizations should reduce the load on the network and the presence servers in interdomain presence subscriptions. The need for the requirements is based on a separate scaling analysis document [I-D.ietf-simple-interdomain-scaling-analysis]. NEW This document identifies requirements for optimizations of the SIP/SIMPLE protocol, which aim at increasing the scalability of the SIP/SIMPLE protocol, and at reducing the load on the network and the presence servers in interdomain presence subscriptions. The need for such requirements is based on the scaling analysis in [I-D.ietf-simple-interdomain-scaling-analysis]. See [I-D.ietf-simple-simple] for a list of RFCs and Internet drafts that are part of the SIP/SIMPLE protocol. This might already be sufficient. > > - The document only talks about "optimizations" to which the defined > > requirement should apply. How about other types of protocol > > enhancements, such as functional extensions? Wouldn't the > defined > > requirements apply to those just as well? > > No. Functional requirements are not in the scope of this document. Ok. - Christian From adam@estacado.net Fri Oct 23 22:14:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D953A6889 for ; Fri, 23 Oct 2009 22:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iksH6Q1Qof5e for ; Fri, 23 Oct 2009 22:14:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9D0F33A6926 for ; Fri, 23 Oct 2009 22:14:31 -0700 (PDT) Received: from [192.168.0.128] (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9O5EWJL061300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Oct 2009 00:14:34 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE28D37.6000902@estacado.net> Date: Sat, 24 Oct 2009 00:14:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Paul Kyzivat References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> In-Reply-To: <4AE2296D.7040503@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 05:14:44 -0000 On 10/23/2009 05:08 PM, Paul Kyzivat wrote: > I think we can go further here. In an INFO message, *the* body part > associated with the info package named in message will *always* be > found in one of the following places: > > - it is the entire body of the message, with C-D:info-package > among the sip headers. > > - the body body of the info message is C-T multipart/mixed > (or some other variant of multipart, adam?) and C-D is "render" > or the C-D is missing. And then one, and only one, of the > immediate child parts of that multipart will have C-D:info-package > and be the one. I think that is precisely the way we want to specify this behavior, and it's a far clearer formulation than my "exactly zero or one" proposal. Regarding your "...or some other variant..." question: by specification, the order of body parts in multipart/mixed is significant. If you have a set of parts in which order does not matter, then *technically*, the correct type to use is multipart/parallel. In *practice*, I think multipart/mixed ends up being used a lot where multipart/parallel would be more correct. In INFO, it would also make sense to have multipart/digest and multipart/signed documents. Finally, it is possible to register new types under "multipart" [1] -- so we should probably just call out "multipart" in the spec instead of narrowing it down to "multipart/mixed". > AFAIK there are no other possibilities that make any sense here. I agree 100%. /a [1] http://www.iana.org/assignments/media-types/multipart/ From dean.willis@softarmor.com Sat Oct 24 00:57:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F8C3A68F6 for ; Sat, 24 Oct 2009 00:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GwMLIusaNkh for ; Sat, 24 Oct 2009 00:57:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E5D603A67B6 for ; Sat, 24 Oct 2009 00:57:49 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9O7vAAR009280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Oct 2009 02:57:12 -0500 Message-ID: <4AE2B351.9080204@softarmor.com> Date: Sat, 24 Oct 2009 02:57:05 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Adam Roach , "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 07:57:50 -0000 Elwell, John wrote: > Christer, > > I tend to agree with Paul, and this is the text I would propose: > > For 7.6: "The Info Package specification MUST define what type of > body part is associated with the Info Package, and MUST refer to > specifications where the syntax, semantics and MIME type of that body > part (and, if multipart/mixed, any child body parts) are described." An Info package should be able to use multiple types of body parts, else we're back to the type=usage encoding. for example, a call-associated image might be tiff, jpeg, gif, etc. Also, what is the semantic of an image? There is no inherent semantic at the MIME level. MIME tells us what an object is, not what we should do with it. Rather, the Info Package specification must define the semantic of the info-package payload, rather than relying on the MIME specification to do do. -- Dean From christer.holmberg@ericsson.com Sat Oct 24 09:02:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538293A68F5 for ; Sat, 24 Oct 2009 09:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Koi3of571Q-b for ; Sat, 24 Oct 2009 09:02:54 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 033123A63EC for ; Sat, 24 Oct 2009 09:02:53 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-27-4ae325374b17 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D0.15.08816.73523EA4; Sat, 24 Oct 2009 18:03:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 18:02:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Oct 2009 18:02:29 +0200 Message-ID: In-Reply-To: <4AE28D37.6000902@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpUaOKH+HeUQRkXQuyuORH99a037wAWLymQ References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> From: "Christer Holmberg" To: "Adam Roach" , "Paul Kyzivat" X-OriginalArrivalTime: 24 Oct 2009 16:02:30.0056 (UTC) FILETIME=[63A47A80:01CA54C3] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 16:02:55 -0000 Hi,=20 >> I think we can go further here. In an INFO message, *the* body part=20 >> associated with the info package named in message will *always* be=20 >> found in one of the following places: >> >> - it is the entire body of the message, with C-D:info-package >> among the sip headers. >> >> - the body body of the info message is C-T multipart/mixed >> (or some other variant of multipart, adam?) and C-D is "render" >> or the C-D is missing. And then one, and only one, of the >> immediate child parts of that multipart will have C-D:info-package >> and be the one. > >I think that is precisely the way we want to specify this behavior, and it's a far clearer formulation than my "exactly=20 >zero or one" proposal. > >Regarding your "...or some other variant..." question: by specification, the order of body parts in multipart/mixed is=20 >significant. If you have a set of parts in which order does not matter, then *technically*, the correct type to use is=20 >multipart/parallel. In *practice*, I think multipart/mixed ends up being used a lot where multipart/parallel would be=20 >more correct. In INFO, it would also make sense to have multipart/digest and multipart/signed documents. Finally, it is=20 >possible to register new types under "multipart" [1] -- so we should probably just call out "multipart" in the spec=20 >instead of narrowing it down to "multipart/mixed". One alternative would be to define a default type in the base spec, and if, for a specific I-P another value shall be used the I-P specification shall indicate that. I would still like to have an answer on the following: what is the multipart value if the multipart only contains a SINGLE child part? I guess one could use almost whatever value, but I would still like to know whether there are any rules. >>AFAIK there are no other possibilities that make any sense here. > >I agree 100%. I just hope that other entities that insert body parts into the INFO message will do the right thing... Regards, Christer From christer.holmberg@ericsson.com Sat Oct 24 09:07:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38513A68C3 for ; Sat, 24 Oct 2009 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQWgAjg6gJRA for ; Sat, 24 Oct 2009 09:07:27 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6AB993A67A6 for ; Sat, 24 Oct 2009 09:07:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-38-4ae32649ab01 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7B.0B.04191.94623EA4; Sat, 24 Oct 2009 18:07:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 18:06:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Oct 2009 18:06:33 +0200 Message-ID: In-Reply-To: <4AE2B351.9080204@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpUf5yjSTnImSZ2QfCDgn/DKZhmVQAQ8jwQ References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4AE2B351.9080204@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Elwell, John" X-OriginalArrivalTime: 24 Oct 2009 16:06:34.0404 (UTC) FILETIME=[F5490640:01CA54C3] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 16:07:28 -0000 Hi Dean,=20 >> I tend to agree with Paul, and this is the text I would propose: >>=20 >> For 7.6: "The Info Package specification MUST define what type of body=20 >> part is associated with the Info Package, and MUST refer to=20 >> specifications where the syntax, semantics and MIME type of that body >> part (and, if multipart/mixed, any child body parts) are described." > > >An Info package should be able to use multiple types of body parts, else we're back to the type=3Dusage encoding. > >for example, a call-associated image might be tiff, jpeg, gif, etc. > >Also, what is the semantic of an image? There is no inherent semantic at the MIME level. MIME tells us what an object is,=20 >not what we should do with it. Rather, the Info Package specification must define the semantic of the info-package=20 >payload, rather than relying on the MIME specification to do do. Just to clarify, I have not said anything about the Content-Type of a body part. I agree it could be whatever. One question has been whether a body part associated with the Info Package could have a Content-Disposition value other than "info-package". Regards, Christer From adam@estacado.net Sat Oct 24 11:49:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57A33A68F1 for ; Sat, 24 Oct 2009 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+9QuxBIAjs3 for ; Sat, 24 Oct 2009 11:49:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A51F73A67BD for ; Sat, 24 Oct 2009 11:49:57 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9OInjPx021845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Oct 2009 13:49:45 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE34C49.20503@estacado.net> Date: Sat, 24 Oct 2009 13:49:45 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4AE2B351.9080204@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 18:49:58 -0000 On 10/24/09 11:06, Oct 24, Christer Holmberg wrote: > One question has been whether a body part associated with the Info > Package could have a Content-Disposition value other than "info-package". For the top-level INFO-related part, I think the answer is "no." For any parts under [1] that top-level INFO-related part, I think the answer is "yes, and in fact, it MUST NOT have a C-D of 'info-package'." /a [1] I mean "under" in the sense of being descendants in the MIME tree structure. From adam@estacado.net Sat Oct 24 12:04:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E8B3A6873 for ; Sat, 24 Oct 2009 12:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chG4lSBmDx6P for ; Sat, 24 Oct 2009 12:04:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 75D6C3A67BD for ; Sat, 24 Oct 2009 12:04:44 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9OJ4pAJ022868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Oct 2009 14:04:51 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE34FD3.4070408@estacado.net> Date: Sat, 24 Oct 2009 14:04:51 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070604000608050106020109" Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 19:04:45 -0000 This is a multi-part message in MIME format. --------------070604000608050106020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/24/09 11:02, Oct 24, Christer Holmberg wrote: >> Regarding your "...or some other variant..." question: by >> > specification, the order of body parts in multipart/mixed is > >> significant. If you have a set of parts in which order does not matter, >> > then *technically*, the correct type to use is > >> multipart/parallel. In *practice*, I think multipart/mixed ends up >> > being used a lot where multipart/parallel would be > >> more correct. In INFO, it would also make sense to have >> > multipart/digest and multipart/signed documents. Finally, it is > >> possible to register new types under "multipart" [1] -- so we should >> > probably just call out "multipart" in the spec > >> instead of narrowing it down to "multipart/mixed". >> > One alternative would be to define a default type in the base spec, and > if, for a specific I-P another value shall be used the I-P specification > shall indicate that. > The whole point here is that body part handling for non-INFO body parts is going to be outside the INFO package specifications -- it's going to be defined by other documents. See, for example: * The final paragraph on page 4 of RFC 3893 * Section 3.4.3.2 of RFC 2633 It would be the height of folly to nail down specific handling in both the base INFO spec and its packages, as they woule > I would still like to have an answer on the following: what is the > multipart value if the multipart only contains a SINGLE child part? multipart/justkidding? multipart/notreally? multipart/i-dont-understand-how-mime-works? Why would someone *DO* that? > >>> AFAIK there are no other possibilities that make any sense here. >>> >> I agree 100%. >> > I just hope that other entities that insert body parts into the INFO > message will do the right thing... > Unless the procedures that they are implementing are designed by people who don't have a basic understanding of MIME, they will all Do The Right Thing, under the rules that Paul and I are advocating. /a --------------070604000608050106020109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/24/09 11:02, Oct 24, Christer Holmberg wrote: 
Regarding your "...or some other variant..." question: by
    
specification, the order of body parts in multipart/mixed is 
  
significant. If you have a set of parts in which order does not matter,
    
then *technically*, the correct type to use is 
  
multipart/parallel. In *practice*, I think multipart/mixed ends up
    
being used a lot where multipart/parallel would be 
  
more correct. In INFO, it would also make sense to have
    
multipart/digest and multipart/signed documents. Finally, it is 
  
possible to register new types under "multipart" [1] -- so we should
    
probably just call out "multipart" in the spec 
  
instead of narrowing it down to "multipart/mixed".
    
One alternative would be to define a default type in the base spec, and
if, for a specific I-P another value shall be used the I-P specification
shall indicate that.

The whole point here is that body part handling for non-INFO body parts is going to be outside the INFO package specifications -- it's going to be defined by other documents. See, for example:
  • The final paragraph on page 4 of RFC 3893
  • Section 3.4.3.2 of RFC 2633
It would be the height of folly to nail down specific handling in both the base INFO spec and its packages, as they woule

I would still like to have an answer on the following: what is the
multipart value if the multipart only contains a SINGLE child part?

multipart/justkidding? multipart/notreally? multipart/i-dont-understand-how-mime-works?

Why would someone *DO* that?

  
AFAIK there are no other possibilities that make any sense here.
      
I agree 100%.
    
I just hope that other entities that insert body parts into the INFO
message will do the right thing...

Unless the procedures that they are implementing are designed by people who don't have a basic understanding of MIME, they will all Do The Right Thing, under the rules that Paul and I are advocating.

/a
--------------070604000608050106020109-- From christer.holmberg@ericsson.com Sat Oct 24 13:44:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEED3A682A for ; Sat, 24 Oct 2009 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEqIBdbJijKJ for ; Sat, 24 Oct 2009 13:44:18 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7B9E33A6819 for ; Sat, 24 Oct 2009 13:44:17 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-c6-4ae3672b994c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 05.38.08816.B2763EA4; Sat, 24 Oct 2009 22:44:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 22:44:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Oct 2009 22:44:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpU2ssiV32BuObxS/OjjZKgy0DZ8gADX5TU References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4AE2B351.9080204@softarmor.com> <4AE34C49.20503@estacado.net> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 24 Oct 2009 20:44:27.0731 (UTC) FILETIME=[C75CD230:01CA54EA] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 20:44:19 -0000 Hi, =20 >>One question has been whether a body part associated with the Info = Package could have a Content-Disposition value other than = "info-package". > >For the top-level INFO-related part, I think the answer is "no." > >For any parts under [1] that top-level INFO-related part, I think the >answer is "yes, and in fact, it MUST NOT have a C-D of 'info-package'." =20 So, assume Info Package X uses a body part 'application/foo'. =20 Now, if I understand you correctly, if this body part happens to be on = the top-level (for example, it is the only body part in the message body = of the request) it would have C-D 'info-package', but if it happens to = be within a multipart with C-D 'info-package' it could have C-D 'foo'? =20 In my opinion the I-P specification for X shall say: "For this package, = when you use C-T 'application/foo', you use C-D 'baz'". That should be = independent on where in the message body structure application/foo is = located. =20 The I-P specification should NOT say: "If application/foo is on this = level you use C-D 'baz', and if it is on that level you use C-D = 'info-package'."=20 =20 That would be really messy... =20 Regards, =20 Chriser =20 =20 From christer.holmberg@ericsson.com Sat Oct 24 13:52:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B4F3A68B3 for ; Sat, 24 Oct 2009 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.195 X-Spam-Level: X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvikcFTCxKVh for ; Sat, 24 Oct 2009 13:52:09 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 04E513A6819 for ; Sat, 24 Oct 2009 13:52:08 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-52-4ae369037536 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D9.58.08816.30963EA4; Sat, 24 Oct 2009 22:52:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 22:52:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Oct 2009 22:52:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpU3N+hfArwdcxZSMm/V8wqCq3juQADhOS5 References: <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacad o.net> From: "Christer Holmberg" To: "Adam Roach" X-OriginalArrivalTime: 24 Oct 2009 20:52:18.0908 (UTC) FILETIME=[E034B9C0:01CA54EB] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 20:52:10 -0000 Hi, =20 The encoding of the e-mail got a little messed up, so I may have missed = something. =20 I agree that the draft is not describing body handling for non-INFO body = parts. I was only talking about multiparts with C-D 'info-package', ie = multiparts which contain body parts associated with the I-P. =20 Assume that the Info Package Y specification defines the usage of body = parts 'application/aaa' and 'application/bbb'. The specification says = that both body parts can be sent in a single INFO request, inside a = multipart. My proposal was that the I-P specification would say what = type is used for THAT multipart - because who else will know what type = to use?=20 =20 Whatever other multiparts types are used in the message body is outside = the scope... =20 Regards, =20 Christer ________________________________ From: Adam Roach [mailto:adam@estacado.net] Sent: Sat 24/10/2009 21:04 To: Christer Holmberg Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo; = draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) = - John E's comments - non-I-P body parts in INFO? On 10/24/09 11:02, Oct 24, Christer Holmberg wrote:=20 Regarding your "...or some other variant..." question: by =20 specification, the order of body parts in multipart/mixed is=20 =20 significant. If you have a set of parts in which order does not = matter, =20 then *technically*, the correct type to use is=20 =20 multipart/parallel. In *practice*, I think multipart/mixed ends up =20 being used a lot where multipart/parallel would be=20 =20 more correct. In INFO, it would also make sense to have =20 multipart/digest and multipart/signed documents. Finally, it is=20 =20 possible to register new types under "multipart" [1] -- so we should =20 probably just call out "multipart" in the spec=20 =20 instead of narrowing it down to "multipart/mixed". =20 One alternative would be to define a default type in the base spec, and if, for a specific I-P another value shall be used the I-P = specification shall indicate that. =20 The whole point here is that body part handling for non-INFO body parts = is going to be outside the INFO package specifications -- it's going to = be defined by other documents. See, for example: * The final paragraph on page 4 of RFC 3893=20 * Section 3.4.3.2 of RFC 2633=20 It would be the height of folly to nail down specific handling in both = the base INFO spec and its packages, as they woule I would still like to have an answer on the following: what is the multipart value if the multipart only contains a SINGLE child part? multipart/justkidding? multipart/notreally? = multipart/i-dont-understand-how-mime-works? Why would someone *DO* that? =20 AFAIK there are no other possibilities that make any sense here. =20 I agree 100%. =20 I just hope that other entities that insert body parts into the INFO message will do the right thing... =20 Unless the procedures that they are implementing are designed by people = who don't have a basic understanding of MIME, they will all Do The Right = Thing, under the rules that Paul and I are advocating. /a From jmpolk@cisco.com Sun Oct 25 23:40:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD82F3A677D; Sun, 25 Oct 2009 23:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9K5WKbnaq+s; Sun, 25 Oct 2009 23:40:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F59E3A681C; Sun, 25 Oct 2009 23:40:00 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAKbg5EqrR7Hu/2dsb2JhbACIGbZ2llqEPwQ X-IronPort-AV: E=Sophos;i="4.44,624,1249257600"; d="scan'208";a="417677159" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 06:40:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q6eDWL009176; Mon, 26 Oct 2009 06:40:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 23:40:12 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.63]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 23:40:12 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 01:40:07 -0500 To: miguel.a.garcia@ericsson.com From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Oct 2009 06:40:12.0287 (UTC) FILETIME=[2B30F8F0:01CA5607] Cc: geopriv@ietf.org, sipcore@ietf.org Subject: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 06:40:00 -0000 Miguel I have concerns about your "Indirect Presence Publication with SIP" draft. http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01.txt Currently, and pretty much since whatever version of http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt has existed in whatever WG it happened to reside in at the time, Location Conveyance using SIP has included the use of PUBLISH to convey location as a message body, or as a location URI since about, or before 2005. I fail to see or read what you want in your doc that cannot be covered in SIP Location Conveyance. I cannot figure out how you claim usage of the Geolocation is too limiting. Additionally, I was forced to change the Location: header to the Geolocation: header due the SIP WG's conclusion it would be confused , therefore I do not believe you will be able to progress this forward for that additional reason as a Location header-value. James BTW -- you use a really old reference for the Location Conveyance ID. It is on the -01 version in SIPCORE now, about to be -02. From miguel.a.garcia@ericsson.com Mon Oct 26 00:54:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35F33A698E; Mon, 26 Oct 2009 00:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+AMX+f251cW; Mon, 26 Oct 2009 00:54:36 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 140563A6898; Mon, 26 Oct 2009 00:54:35 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-08-4ae555c7c3a7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 44.22.31706.7C555EA4; Mon, 26 Oct 2009 08:54:47 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:54:44 +0100 Received: from [159.107.25.11] ([159.107.25.11]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:54:43 +0100 Message-ID: <4AE555C3.9000109@ericsson.com> Date: Mon, 26 Oct 2009 08:54:43 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "James M. Polk" , "Thomson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 07:54:43.0950 (UTC) FILETIME=[948298E0:01CA5611] X-Brightmail-Tracker: AAAAAA== Cc: geopriv@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 07:54:37 -0000 James, Actually, Martin Thomson has been pushing and submitting this draft. We (the authors) do not agree with all the content in there, for which we had little time to react. So, please, take this document as a mechanism to generate discussion more than as the reflected consensus among the authors. Now, I will give you my personal thoughts below, which, as I said, might not match other authors'. On 26/10/2009 7:40, James M. Polk wrote: > Miguel > > old SIP and your targeted Geopriv WGs> > > I have concerns about your "Indirect Presence Publication with SIP" draft. > http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01.txt > > > Currently, and pretty much since whatever version of > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt > has existed in whatever WG it happened to reside in at the time, > Location Conveyance using SIP has included the use of PUBLISH to convey > location as a message body, or as a location URI since about, or before > 2005. I fail to see or read what you want in your doc that cannot be > covered in SIP Location Conveyance. I understand that the Geolocation header has quite a few similarities with what is proposed in the draft. I don't think the Geolocation header has means to indicate the presence server "you should de-reference the location and insert it in a presence document to be offered to watchers". > > I cannot figure out how you claim usage of the Geolocation is too limiting. I have several criticism to the use of a SIP header to convey this information. Indirect location is just a particular case of a general solution, which is, a presentity wants to publish some information by reference not by value. Location is the more straight forward example, but we should try to find a general solution. So, if we agree to pursue a general solution for publication of presence information by reference, then I find difficult to think of a solution based on a new or existing SIP header. Instead, we should be looking at the XML body, either to an extension to the existing one or a new XML body that. If we don't agree with pursuing a general solution, then we should carefully look at the existing Geolocation header. > > Additionally, I was forced to change the Location: header to the > Geolocation: header due the SIP WG's conclusion it would be confused , > therefore I do not believe you will be able to progress this forward for > that additional reason as a Location header-value. I agree with you, as I said, I don't even think the correct solution is to use a header at all. I think the chosen name "Location" is quite unfortunate due to historical reasons. /Miguel > > James > > BTW -- you use a really old reference for the Location Conveyance ID. It > is on the -01 version in SIPCORE now, about to be -02. > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ian.elz@ericsson.com Mon Oct 26 03:37:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4FA3A69B4 for ; Mon, 26 Oct 2009 03:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkdFHdscnWxH for ; Mon, 26 Oct 2009 03:37:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 971433A68D3 for ; Mon, 26 Oct 2009 03:37:04 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-03-4ae57bdc8aa5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FF.49.04191.CDB75EA4; Mon, 26 Oct 2009 11:37:16 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:36:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 11:36:19 +0100 Message-ID: In-Reply-To: <4ADCF72F.3080604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcpWKCfC84P5f67ZS6eDOsgT494h2Q== References: <4A5FAF4E.4030901@cisco.com> <1ECE0EB50388174790F9694F77522CCF1FDB68F4@zrc2hxm0.corp.nortel.com> <8468C1EF-D9F4-4031-A306-E49F7365B050@ntt-at.com> <1ECE0EB50388174790F9694F77522CCF1FDB7171@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D11D@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203B1273@zrc2hxm0.corp.nortel.com> <7402509E63C5A145A6095D46C179A5B705C6D1E0@DEMCHP99E35MSX.ww902.siemens.net> <1ECE0EB50388174790F9694F77522CCF203EECA3@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241127k6ec043a7vcdec27bf81bfa9c@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF111@zrc2hxm0.corp.nortel.com> <9ae56b1e0909241147w3e3662depe305f8f5e1e1900@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF203EF16D@zrc2hxm0.corp.nortel.com> <5816799C-C767-4C87-BBA8-11B3729CC8F9@ntt-at.com> <03234651-30D7-4E4C-9AD2-FA5E83AF691E@gmail.com><7402509E63C5A145A6095D46C179A5B71477DD21@DEMCHP99E35MSX.ww902.siemens.net> <4ADCF72F.3080604@cisco.com> From: "Ian Elz" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 26 Oct 2009 10:36:21.0029 (UTC) FILETIME=[286B6D50:01CA5628] X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Lennox , =?iso-8859-1?Q?Fran=E7ois_AUDET?= , sipcore@ietf.org, Hadriel Kaplan , Dean Willis , ELWELL John , Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 10:37:06 -0000 All, Paul is correct in the name to name translation. As well as the basic translation that Paul identified it is also common = to translate from one 'freephone type' number to another. This occurs = where a call answering service has multiple answering locations and the = specific answering location is determined based upon identity of the = caller, date/day/time etc. When the call answering service is required to handle calls from = multiple different 'freephone' numbers then it is often easier to have = one number which defines the answering location and another which is the = 'dialed' number which translates to the number, or numbers, which define = the call handling. In effect a hierarchy can be using these numbers = which translate to each other. I use the term 'freephone type' as freephone relates to one charging = scenario where there are other charging scenarios defined in different = regulatory regimes, local call rate, national call rate and a plethora = of different premium rates. All of these are logically handled in a = similar fashion. The ISUP PSTN network allows the provision 2 different numbers to the = called party, original called party number and redirecting number. The = redirecting number is the last identity which performed a diversion of = redirection. The original called party number is the number dialed by = the caller ( as modified by the network to make is a standard format, = e.g. national or international number). For H-I we need to be able to replicate at least the ability to identify = the original number/identity called and the last identity which = diverted/redirected the call. The intermediate information which is not available in ISUP is also = useful, particularly when some data is incorrect, as it allow tracing of = how a call was handled. Ian Elz -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 20 October 2009 00:33 To: Elwell, John Cc: Jonathan Lennox; Fran=E7ois AUDET; sipcore@ietf.org; Hadriel Kaplan; = Dean Willis; ELWELL John; Keith Drage Subject: Re: [sipcore] rfc4244bis: what is an AoR? Elwell, John wrote: > But in actual fact, any E.164 number is a name, so the tag would apply = to any E.164 to SIP URI translation. Is this helpful? Yes, any E.164 number is a name, even if it is embedded in a SIP uri = containing a domain name. (Its quite likely the domain name doesn't = reflect the "owner" of the E.164 number, just a convenient server that = will hopefully figure out what to do next based on the number.) Of course, once upon a time phone numbers *were* addresses, and were = routed digit by digit. But that time is over. Similarly, the domain = names in SIP URIs are *name*s, not addresses. And the IP addresses are = actually names too, ... What's a name and what's an address is a matter = of perspective and layering. So, to go this will will require careful definition of the distinction = in this context. Also, Shida said: > In deployment, name to name translation never happens That's not really true is it? IIUC, its pretty normal for a "name" like 1-800-666-1111 to be translated to another name,like 1-212-555-1234, = which then must be routed to a responsible server. Thanks, Paul > John >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Fran=E7ois AUDET >> Sent: 18 October 2009 15:37 >> To: Shida Schubert >> Cc: Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis;=20 >> ELWELL John; Keith Drage >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> This is quite an interesting idea. Probably wider in scope than=20 >> History-Info, but it sounds like a good way to tackle the problem. >> >> On Oct 18, 2009, at 24:16 , Shida Schubert wrote: >> >>> The reason why current use of "mp" tag is not semantically correct=20 >>> for freephone, is because Service-URN and free-phone is a "name" and = >>> not an "address" based on the definition in the target-uri draft. >>> >>> I believe we need to define another tag for "name" to "address"=20 >>> translation. >>> >>> ## Definition of address/name in the target-uri draft ## >>> >>> A name is a moniker for an entity which refers to it in a >> way which >>> reveals nothing about where it is in a network. In SIP, tel URI >>> which doesn't represent the location of the entity is a name. >>> >>> An address is an identifier for an entity which describes >> it by its >>> location on the network. In SIP, the SIP URI itself is a form of >>> address because the host part of the URI, the only >> mandatory part of >>> the URI besides the scheme itself, indicates the location of a SIP >>> server that can be used to handle the request. >>> >>> ## -- ## >>> >>> In deployment, name to name translation never happens and generally = >>> "name" to "address" translation is very deterministic that entity=20 >>> doing the mapping/translation can tag the entry with confidence. >>> >>> For example, If one sends a request to PSAP using 911, directory=20 >>> assistance using 411, name(411,911 or service-URN) is translated to=20 >>> an address. That address may be translated numerous times to another = >>> address (PSAP in NYC to PSAP in NJ) but will never be translated=20 >>> again to another name(911 to 411). >>> >>> Furthermore, entity/organization that is expecting to be reached by=20 >>> name usually knows what name it will be reached by, so having the=20 >>> ability to distinguish one service to another is probably not=20 >>> necessary but having the ability to tag "name" to "address" >>> translation, I believe is very helpful. >>> >>> Any thoughts? >>> >>> Regards >>> Shida >>> >>> >>> On Sep 25, 2009, at 3:48 AM, Francois Audet wrote: >>> >>>> Other idea? >>>> >>>> (I really don't care personally about "freephone"...) >>>> >>>>> -----Original Message----- >>>>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>>> Sent: Thursday, September 24, 2009 11:48 >>>>> To: Audet, Francois (SC100:3055); Elwell, John; Shida Schubert;=20 >>>>> Jonathan Lennox; sipcore@ietf.org; Hadriel Kaplan; Dean Willis;=20 >>>>> Elwell, John; Keith Drage >>>>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>>>> >>>>> Yes got that, but that does not justify a service specific tag in = >>>>> 4244bis. >>>>> /hans erik >>>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Mon Oct 26 06:08:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C876928B56A for ; Mon, 26 Oct 2009 06:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR-cgQnTMFGh for ; Mon, 26 Oct 2009 06:08:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 060E53A67FD for ; Mon, 26 Oct 2009 06:08:07 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABQ85UqrR7Hu/2dsb2JhbADAZZZuhD8E X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="417927029" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 13:08:20 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9QD7Ziq003749; Mon, 26 Oct 2009 13:08:20 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:07:54 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:07:53 -0400 Message-ID: <4AE59F22.5080509@cisco.com> Date: Mon, 26 Oct 2009 09:07:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4AE2B351.9080204@softarmor.com> <4AE34C49.20503@estacado.net> In-Reply-To: <4AE34C49.20503@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 13:07:53.0829 (UTC) FILETIME=[54269950:01CA563D] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:08:07 -0000 Adam Roach wrote: > On 10/24/09 11:06, Oct 24, Christer Holmberg wrote: >> One question has been whether a body part associated with the Info >> Package could have a Content-Disposition value other than "info-package". > > For the top-level INFO-related part, I think the answer is "no." Agree. This is a "duh" since this is *the* way the part associated with the info package is identified. > For any parts under [1] that top-level INFO-related part, I think the > answer is "yes, and in fact, it MUST NOT have a C-D of 'info-package'." Lets not get carried away here and ban things just because we can't currently conceive of a use. I can think of cases where descendents might want to reuse the C-D:info-package. (E.g. where the info package contains a copy of a full SIP message, including possibly an INFO message, or a sipfrag of one.) Thanks, Paul > /a > > [1] I mean "under" in the sense of being descendants in the MIME tree > structure. > From pkyzivat@cisco.com Mon Oct 26 06:09:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D940F3A67FD for ; Mon, 26 Oct 2009 06:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVydur0EoB2H for ; Mon, 26 Oct 2009 06:09:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BE53B3A6768 for ; Mon, 26 Oct 2009 06:09:48 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMQ85UpAZnwN/2dsb2JhbADAb5ZuhD8E X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="64900345" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2009 13:10:01 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QDA1EX027604; Mon, 26 Oct 2009 13:10:01 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:10:01 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:10:00 -0400 Message-ID: <4AE59FA1.2000006@cisco.com> Date: Mon, 26 Oct 2009 09:09:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 13:10:00.0966 (UTC) FILETIME=[9FEE2A60:01CA563D] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:09:49 -0000 Christer Holmberg wrote: > Hi, > > The encoding of the e-mail got a little messed up, so I may have missed something. > > I agree that the draft is not describing body handling for non-INFO body parts. I was only talking about multiparts with C-D 'info-package', ie multiparts which contain body parts associated with the I-P. > > Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The specification says that both body parts can be sent in a single INFO request, inside a multipart. My proposal was that the I-P specification would say what type is used for THAT multipart - because who else will know what type to use? It first must specify *the* top level part. In your case it will presumably have decided that it needs some sort of multipart for that, and will indeed specify which variety/varieties of multipart make sense for it. > Whatever other multiparts types are used in the message body is outside the scope... Good. Thanks, Paul > Regards, > > Christer > > ________________________________ > > From: Adam Roach [mailto:adam@estacado.net] > Sent: Sat 24/10/2009 21:04 > To: Christer Holmberg > Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? > > > On 10/24/09 11:02, Oct 24, Christer Holmberg wrote: > > Regarding your "...or some other variant..." question: by > > > specification, the order of body parts in multipart/mixed is > > > significant. If you have a set of parts in which order does not matter, > > > then *technically*, the correct type to use is > > > multipart/parallel. In *practice*, I think multipart/mixed ends up > > > being used a lot where multipart/parallel would be > > > more correct. In INFO, it would also make sense to have > > > multipart/digest and multipart/signed documents. Finally, it is > > > possible to register new types under "multipart" [1] -- so we should > > > probably just call out "multipart" in the spec > > > instead of narrowing it down to "multipart/mixed". > > > One alternative would be to define a default type in the base spec, and > if, for a specific I-P another value shall be used the I-P specification > shall indicate that. > > > > The whole point here is that body part handling for non-INFO body parts is going to be outside the INFO package specifications -- it's going to be defined by other documents. See, for example: > > > * The final paragraph on page 4 of RFC 3893 > * Section 3.4.3.2 of RFC 2633 > > It would be the height of folly to nail down specific handling in both the base INFO spec and its packages, as they woule > > > > I would still like to have an answer on the following: what is the > multipart value if the multipart only contains a SINGLE child part? > > > multipart/justkidding? multipart/notreally? multipart/i-dont-understand-how-mime-works? > > Why would someone *DO* that? > > > > > > AFAIK there are no other possibilities that make any sense here. > > > I agree 100%. > > > I just hope that other entities that insert body parts into the INFO > message will do the right thing... > > > > Unless the procedures that they are implementing are designed by people who don't have a basic understanding of MIME, they will all Do The Right Thing, under the rules that Paul and I are advocating. > > /a > > From christer.holmberg@ericsson.com Mon Oct 26 06:31:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0866828C272 for ; Mon, 26 Oct 2009 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkwwnfAuToo0 for ; Mon, 26 Oct 2009 06:31:08 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 60A7528C294 for ; Mon, 26 Oct 2009 06:31:07 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-32-4ae5a4a78f38 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7A.F7.24026.7A4A5EA4; Mon, 26 Oct 2009 14:31:19 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:30:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 14:25:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWPaL6+vq0mIeVSiWAPDcztFHEFQAAiJ7s References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.co m> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 13:30:15.0885 (UTC) FILETIME=[741417D0:01CA5640] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:31:09 -0000 Hi, =20 >>The encoding of the e-mail got a little messed up, so I may have = missed something. >>=20 >>I agree that the draft is not describing body handling for non-INFO = body parts. I was only talking about multiparts with C- >>D 'info-package', ie multiparts which contain body parts associated = with the I-P. >>=20 >>Assume that the Info Package Y specification defines the usage of body = parts 'application/aaa' and 'application/bbb'. The=20 >>specification says that both body parts can be sent in a single INFO = request, inside a multipart. My proposal was that the=20 >>I-P specification would say what type is used for THAT multipart - = because who else will know what type to use? > >It first must specify *the* top level part. In your case it will >presumably have decided that it needs some sort of multipart for that, >and will indeed specify which variety/varieties of multipart make sense >for it. Then, take the following example: An INFO request contains only a SINGLE body part (application/aaa), = associated with the I-P. The I-P specification says that C-D 'foo' is used for 'application/aaa'. = And, since there is only one single body part, the SIP header C-T will = indicate 'application/aaa' and the SIP header C-D will indicate 'foo'. Now, WHERE are you going to put the "top level" part, which indicates = 'info-package'? Are you going to create a multipart for that single body part, so that = you can put C-D 'info-packag' in the SIP header, and C-D 'foo' inside = the multipart? Regards, Christer =20 =20 =20 =20 =20 =20 > Whatever other multiparts types are used in the message body is = outside the scope... Good. Thanks, Paul > Regards, >=20 > Christer > > ________________________________ > > From: Adam Roach [mailto:adam@estacado.net] > Sent: Sat 24/10/2009 21:04 > To: Christer Holmberg > Cc: Paul Kyzivat; Elwell, John; SIPCORE; Gonzalo Camarillo; = draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments = (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body = parts in INFO? > > > On 10/24/09 11:02, Oct 24, Christer Holmberg wrote: > > Regarding your "...or some other variant..." question: = by > =20 > > specification, the order of body parts in multipart/mixed is > =20 > > significant. If you have a set of parts in which order = does not matter, > =20 > > then *technically*, the correct type to use is > =20 > > multipart/parallel. In *practice*, I think = multipart/mixed ends up > =20 > > being used a lot where multipart/parallel would be > =20 > > more correct. In INFO, it would also make sense to have > =20 > > multipart/digest and multipart/signed documents. Finally, it is > =20 > > possible to register new types under "multipart" [1] -- = so we should > =20 > > probably just call out "multipart" in the spec > =20 > > instead of narrowing it down to "multipart/mixed". > =20 > > One alternative would be to define a default type in the base = spec, and > if, for a specific I-P another value shall be used the I-P = specification > shall indicate that. > =20 > > > The whole point here is that body part handling for non-INFO body = parts is going to be outside the INFO package specifications -- it's = going to be defined by other documents. See, for example: > > > * The final paragraph on page 4 of RFC 3893 > * Section 3.4.3.2 of RFC 2633 > > It would be the height of folly to nail down specific handling in both = the base INFO spec and its packages, as they woule > > > > I would still like to have an answer on the following: what is = the > multipart value if the multipart only contains a SINGLE child = part? > > > multipart/justkidding? multipart/notreally? = multipart/i-dont-understand-how-mime-works? > > Why would someone *DO* that? > > > > =20 > > AFAIK there are no other possibilities that make = any sense here. > =20 > > I agree 100%. > =20 > > I just hope that other entities that insert body parts into the = INFO > message will do the right thing... > =20 > > > Unless the procedures that they are implementing are designed by = people who don't have a basic understanding of MIME, they will all Do = The Right Thing, under the rules that Paul and I are advocating. > > /a > > From christer.holmberg@ericsson.com Mon Oct 26 06:32:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF4128C27F for ; Mon, 26 Oct 2009 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-ZJljn5Dc3S for ; Mon, 26 Oct 2009 06:32:28 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 047BD28C279 for ; Mon, 26 Oct 2009 06:32:22 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-3e-4ae5a4f3b957 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1F.18.24026.3F4A5EA4; Mon, 26 Oct 2009 14:32:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:32:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 14:30:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWPWc5QkgKYBpcQ7S+P2KkPbIzYQAAxB0E References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <4ADDDA50.1050704@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BA9@DEMCHP99E35MSX.ww902.siemens.net> <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4AE2B351.9080204@softarmor.com> <4AE34C49.20503@estacado.net> <4AE59F22.5080509@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Adam Roach" X-OriginalArrivalTime: 26 Oct 2009 13:32:35.0039 (UTC) FILETIME=[C7054EF0:01CA5640] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo , Gonzalo@core3.amsl.com Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:32:31 -0000 Hi, =20 I think C-D 'info-package' shall be allowed for any part associated with = the I-P, if the remote terminating knows how to process the information. =20 Regards, =20 Christer ________________________________ From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Mon 26/10/2009 14:07 To: Adam Roach Cc: Christer Holmberg; Dean Willis; Elwell, John; = draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE; = Gonzalo@core3.amsl.com; Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) = - John E's comments - non-I-P body parts in INFO? Adam Roach wrote: > On 10/24/09 11:06, Oct 24, Christer Holmberg wrote: >> One question has been whether a body part associated with the Info >> Package could have a Content-Disposition value other than = "info-package". > > For the top-level INFO-related part, I think the answer is "no." Agree. This is a "duh" since this is *the* way the part associated with the info package is identified. > For any parts under [1] that top-level INFO-related part, I think the > answer is "yes, and in fact, it MUST NOT have a C-D of = 'info-package'." Lets not get carried away here and ban things just because we can't currently conceive of a use. I can think of cases where descendents might want to reuse the C-D:info-package. (E.g. where the info package contains a copy of a full SIP message, including possibly an INFO message, or a sipfrag of one.) Thanks, Paul > /a > > [1] I mean "under" in the sense of being descendants in the MIME tree > structure. > From br@brianrosen.net Mon Oct 26 06:43:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779C13A6977; Mon, 26 Oct 2009 06:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR0jhjIUDtQB; Mon, 26 Oct 2009 06:43:44 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 51B803A686A; Mon, 26 Oct 2009 06:43:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.216]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2PrN-0006M7-AD; Mon, 26 Oct 2009 08:43:46 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Mon, 26 Oct 2009 09:43:43 -0400 From: Brian Rosen To: Miguel Garcia , James Polk , "Thomson, Martin" Message-ID: Thread-Topic: [sipcore] draft-garcia-geopriv-indirect-publish Thread-Index: AcpWQlUoca1UZkw+e0O0r0tEBANPOw== In-Reply-To: <4AE555C3.9000109@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: geopriv@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:43:45 -0000 I agree that we need a generalized way to indicate indirect presence publish, and would not want to see a specialized mechanism for location. I do think we could add a parameter to Geolocation which was instructions to the presence server to fetch the location and include it in the presence notifications, which would be much better than a new header just for that, but a generalized indirect publish would be better IMO. Brian On 10/26/09 3:54 AM, "Miguel Garcia" wrote: > James, > > Actually, Martin Thomson has been pushing and submitting this draft. We > (the authors) do not agree with all the content in there, for which we > had little time to react. So, please, take this document as a mechanism > to generate discussion more than as the reflected consensus among the > authors. > > Now, I will give you my personal thoughts below, which, as I said, might > not match other authors'. > > > On 26/10/2009 7:40, James M. Polk wrote: >> Miguel >> >> > old SIP and your targeted Geopriv WGs> >> >> I have concerns about your "Indirect Presence Publication with SIP" draft. >> http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01. >> txt >> >> >> Currently, and pretty much since whatever version of >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01 >> .txt >> has existed in whatever WG it happened to reside in at the time, >> Location Conveyance using SIP has included the use of PUBLISH to convey >> location as a message body, or as a location URI since about, or before >> 2005. I fail to see or read what you want in your doc that cannot be >> covered in SIP Location Conveyance. > > I understand that the Geolocation header has quite a few similarities > with what is proposed in the draft. I don't think the Geolocation header > has means to indicate the presence server "you should de-reference the > location and insert it in a presence document to be offered to watchers". > >> >> I cannot figure out how you claim usage of the Geolocation is too limiting. > > I have several criticism to the use of a SIP header to convey this > information. Indirect location is just a particular case of a general > solution, which is, a presentity wants to publish some information by > reference not by value. Location is the more straight forward example, > but we should try to find a general solution. > > So, if we agree to pursue a general solution for publication of presence > information by reference, then I find difficult to think of a solution > based on a new or existing SIP header. Instead, we should be looking at > the XML body, either to an extension to the existing one or a new XML > body that. > > If we don't agree with pursuing a general solution, then we should > carefully look at the existing Geolocation header. > >> >> Additionally, I was forced to change the Location: header to the >> Geolocation: header due the SIP WG's conclusion it would be confused , >> therefore I do not believe you will be able to progress this forward for >> that additional reason as a Location header-value. > > I agree with you, as I said, I don't even think the correct solution is > to use a header at all. I think the chosen name "Location" is quite > unfortunate due to historical reasons. > > /Miguel > >> >> James >> >> BTW -- you use a really old reference for the Location Conveyance ID. It >> is on the -01 version in SIPCORE now, about to be -02. >> >> From gonzalo.camarillo@ericsson.com Mon Oct 26 07:07:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12F428C2A8 for ; Mon, 26 Oct 2009 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XSiVXCzDo+D for ; Mon, 26 Oct 2009 07:07:18 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C775828C2AA for ; Mon, 26 Oct 2009 07:07:17 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-56-4ae5ad22a700 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 43.95.31706.22DA5EA4; Mon, 26 Oct 2009 15:07:30 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:07:29 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:07:29 +0100 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3D8A726C4 for ; Mon, 26 Oct 2009 16:07:29 +0200 (EET) Message-ID: <4AE5AD21.6070603@ericsson.com> Date: Mon, 26 Oct 2009 16:07:29 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 14:07:29.0385 (UTC) FILETIME=[A7592590:01CA5645] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:07:19 -0000 Folks, I have just submitted a new version of the re-INVITE handling draft: http://www.ietf.org/id/draft-camarillo-sipcore-reinvite-01.txt This revision reflects the conclusions reached during the extensive discussions we had on this topic. Comments on the whole draft are very welcome. Additionally, there is an issue marked as TODO, which is related to RFC 3264. You may want to comment on that as well. Note that our charter has the following milestone: Invite Transaction Handling Correction This draft directly addresses that milestone. Cheers, Gonzalo From brett@broadsoft.com Mon Oct 26 07:12:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126113A68AB for ; Mon, 26 Oct 2009 07:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JakP7jRD8UzL for ; Mon, 26 Oct 2009 07:12:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 44D963A6885 for ; Mon, 26 Oct 2009 07:12:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 07:12:52 -0700 From: Brett Tate To: Christer Holmberg , SIPCORE Date: Mon, 26 Oct 2009 07:12:43 -0700 Thread-Topic: draft-ietf-sipcore-info-events-02: WGLC comment and questions Thread-Index: AcpWRmKHGMuKpE6vRvC/3lg3UdC4/w== Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB1B8@EXMBXCLUS01.citservers.local> 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 Subject: [sipcore] draft-ietf-sipcore-info-events-02: WGLC comment and questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:12:39 -0000 Hi Christer, The following are a few comments and questions concerning draft-ietf-sipcor= e-info-events-02. Thanks, Brett ------------ Section 3.2 paragraph 2: Concerning "during the dialog establishment, and d= uring a target refresh", how should it be interpreted in relation to PRACK = and ACK discussed within the next sentence? More specifically, is indicati= on of Recv-Info limited to call setup or can it be performed during the re-= INVITE process? Section 3.2 paragraph 3: "to INFO" should likely be "to receive INFO". The= last sentence potentially could be reworded to avoid "This" ambiguity. Section 3.5: It is unclear if OPTIONS within dialog can be used to communic= ate a Recv-Info change similar to target refresh requests like UPDATE. Section 3.5 paragraph 1: The strength of "SHALL" is likely too strong and p= otentially conflicts with the drafts table 2. In case it matters, RFC 3261= tables 2 and 3 indicated "m*" for various OPTIONS headers. For compliance= , is this "SHALL" going to cause devices that use OPTIONS as a device ping = (outside of dialog) to be required to add Recv-Info if they support this dr= aft? Section 4.4 and table 2: Concerning the 469, should it be optional (or mand= atory) to return Recv-Info? Section 5.1 figure 1: Retry-After needs a 500 next to the 503. Section 6.1 table 2: ACK responses should have "-" instead of "o". Section 6.1 table 2: Because of rfc4320, the "Recv-Info 1xx" row should lik= ely only have "-" everywhere except INV. Section 6.1 table 2: Is there really a current reason for "Recv-Info r" row= ? If so or not, why would UPD have an "o" when INV has a "-"? Section 11.4 bullet 2: Since it doesn't follow the related rfc4485 section = 4.4 "SHOULD", why are the parameter names and values case-sensitive? From pkyzivat@cisco.com Mon Oct 26 08:02:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60763A6A9F for ; Mon, 26 Oct 2009 08:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbMRBQJWI-F1 for ; Mon, 26 Oct 2009 08:02:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C6423A6A9D for ; Mon, 26 Oct 2009 08:02:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAARX5UpAZnwM/2dsb2JhbADBV5Z7hD8E X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="64953631" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2009 15:03:03 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QF2wtg012476; Mon, 26 Oct 2009 15:03:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:03:03 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:03:02 -0400 Message-ID: <4AE5BA15.7060907@cisco.com> Date: Mon, 26 Oct 2009 11:02:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 15:03:02.0549 (UTC) FILETIME=[6A119C50:01CA564D] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:02:53 -0000 Christer Holmberg wrote: > Hi, > >>> The encoding of the e-mail got a little messed up, so I may have missed something. >>> >>> I agree that the draft is not describing body handling for non-INFO body parts. I was only talking about multiparts with C- >>> D 'info-package', ie multiparts which contain body parts associated with the I-P. >>> >>> Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The >>> specification says that both body parts can be sent in a single INFO request, inside a multipart. My proposal was that the >>> I-P specification would say what type is used for THAT multipart - because who else will know what type to use? >> It first must specify *the* top level part. In your case it will >> presumably have decided that it needs some sort of multipart for that, >> and will indeed specify which variety/varieties of multipart make sense >> for it. > > Then, take the following example: > > An INFO request contains only a SINGLE body part (application/aaa), associated with the I-P. > > The I-P specification says that C-D 'foo' is used for 'application/aaa'. And, since there is only one single body part, the SIP header C-T will indicate 'application/aaa' and the SIP header C-D will indicate 'foo'. > > Now, WHERE are you going to put the "top level" part, which indicates 'info-package'? > > Are you going to create a multipart for that single body part, so that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' inside the multipart? We have said that the body part associated with an I-P is determined by the C-D of info-package. So that is a given when writing the specification for the I-P. *If* the I-P wants to receive a single body part, and it wants that to have C-D of foo, then it is out of luck. It can then, if it wishes, specify that it should receive a multipart (with C-D of info-package) containing a single body part of C-T application/aaa and C-D of foo. Thanks, Paul From christer.holmberg@ericsson.com Mon Oct 26 08:42:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EF33A694A for ; Mon, 26 Oct 2009 08:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc+OUGGlRZJg for ; Mon, 26 Oct 2009 08:42:46 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 79AC63A6A87 for ; Mon, 26 Oct 2009 08:42:45 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-d2-4ae5c3818bae Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FE.62.04191.183C5EA4; Mon, 26 Oct 2009 16:42:57 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 16:41:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 16:41:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWTW/7rh103ougSPqSgzHnPHPQ7gABF8UC References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 15:41:34.0757 (UTC) FILETIME=[CC408D50:01CA5652] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:42:47 -0000 Hi, >>>> The encoding of the e-mail got a little messed up, so I may have = missed something. >>>> >>>> I agree that the draft is not describing body handling for non-INFO = body parts. I was only talking about multiparts with C- >>>> D 'info-package', ie multiparts which contain body parts associated = with the I-P. >>>> >>>> Assume that the Info Package Y specification defines the usage of = body parts 'application/aaa' and 'application/bbb'. The >>>> specification says that both body parts can be sent in a single = INFO request, inside a multipart. My proposal was that the >>>> I-P specification would say what type is used for THAT multipart - = because who else will know what type to use? >>> It first must specify *the* top level part. In your case it will >>> presumably have decided that it needs some sort of multipart for = that, >>> and will indeed specify which variety/varieties of multipart make = sense >>> for it. >> >> Then, take the following example: >> >> An INFO request contains only a SINGLE body part (application/aaa), = associated with the I-P. >> >> The I-P specification says that C-D 'foo' is used for = 'application/aaa'. And, since there is only one single body part, the = SIP header C-T will indicate 'application/aaa' and the SIP header C-D = will indicate 'foo'. >> >> Now, WHERE are you going to put the "top level" part, which indicates = 'info-package'? >> >> Are you going to create a multipart for that single body part, so = that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' = inside the multipart? > >We have said that the body part associated with an I-P is determined by >the C-D of info-package. So that is a given when writing the >specification for the I-P. Yes.=20 >*If* the I-P wants to receive a single body part, and it wants that to >have C-D of foo, then it is out of luck. It can then, if it wishes, >specify that it should receive a multipart (with C-D of info-package) >containing a single body part of C-T application/aaa and C-D of foo. Which is kinda overkill - especially since I think a single body part is = going to be the most common INFO use-case. Now, the easiest solution is of course to specify that C-D = 'info-package' shall be used for this body part. BUT, then C-D = 'info-package' shall be used also if the body part would be placed = inside a multipart with C-D 'multi-part'. Again, my point is that a single body part (non-multipart) should have = the same C-D value no matter where it is located in the INFO request. So, I think that we should allow non-'info-package' C-D values for I-P = body parts ONLY if they will ALWAYS be located inside a multipart with = C-D 'multi-part'. Regards, Christer =20 From adam@estacado.net Mon Oct 26 08:57:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A853A6A88 for ; Mon, 26 Oct 2009 08:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qmGwH1KgXbd for ; Mon, 26 Oct 2009 08:57:41 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 632293A6A9D for ; Mon, 26 Oct 2009 08:57:41 -0700 (PDT) Received: from [172.16.3.231] (orthrus.test.estacado.net [172.16.3.231] (may be forged)) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9QFvjVA012225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Oct 2009 10:57:45 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE5C6F9.4040707@estacado.net> Date: Mon, 26 Oct 2009 10:57:45 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Christer Holmberg References: <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:57:42 -0000 On 10/26/09 10:41 AM, Christer Holmberg wrote: > >> We have said that the body part associated with an I-P is determined by >> the C-D of info-package. So that is a given when writing the >> specification for the I-P. >> > Yes. > We appear to all be in agreement on this point. >> *If* the I-P wants to receive a single body part, and it wants that to >> have C-D of foo, then it is out of luck. It can then, if it wishes, >> specify that it should receive a multipart (with C-D of info-package) >> containing a single body part of C-T application/aaa and C-D of foo. >> > Which is kinda overkill - especially since I think a single body part is going to be the most common INFO use-case. > I agree with Christer on this point. > Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a multipart with C-D 'multi-part'. > Right. But that won't really happen inside the confines of an INFO package -- it can really only happen as the result of multipart processing due to some other technique (such as S/MIME or AIB processing). Which means that we can't really say anything useful about it in either of the INFO base spec or any of the INFO packages. The relevant procedures are defined by the thing that causes the multipart usage to arise. > Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request. > > I agree with this. > So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart with C-D 'multi-part'. > I think we're converging on agreement here. /a From brett@broadsoft.com Mon Oct 26 09:38:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E573328C106 for ; Mon, 26 Oct 2009 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFkg8jtEAAVi for ; Mon, 26 Oct 2009 09:38:26 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 3C07028C104 for ; Mon, 26 Oct 2009 09:38:26 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 09:38:39 -0700 From: Brett Tate To: Christer Holmberg , SIPCORE Date: Mon, 26 Oct 2009 09:38:34 -0700 Thread-Topic: draft-ietf-sipcore-info-events-02: empty content Thread-Index: AcpWWsJOSa6fthkWSbG0CfGyDDCvIg== Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> 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 Subject: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:38:27 -0000 Are INFO bodies required for an info-package? And if so, are 0 length bodi= es acceptable to meet the requirement? I ask in case there are packages (such as for "flash-hook") where "Info-Pac= kage: flash-hook" can signal the INFO needs without otherwise really needin= g a body. Thanks, Brett From pkyzivat@cisco.com Mon Oct 26 09:41:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5302928C19A for ; Mon, 26 Oct 2009 09:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtKDpGygXb+K for ; Mon, 26 Oct 2009 09:41:00 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 24E6028C17A for ; Mon, 26 Oct 2009 09:41:00 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPtt5UqrR7H+/2dsb2JhbADBI5cIhD8E X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="198853999" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2009 16:41:13 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QGfC5U005339; Mon, 26 Oct 2009 16:41:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:41:13 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:41:12 -0400 Message-ID: <4AE5D136.5080804@cisco.com> Date: Mon, 26 Oct 2009 12:41:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 16:41:12.0729 (UTC) FILETIME=[20E3C090:01CA565B] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:41:01 -0000 Christer Holmberg wrote: > Hi, > >>>>> The encoding of the e-mail got a little messed up, so I may have missed something. >>>>> >>>>> I agree that the draft is not describing body handling for non-INFO body parts. I was only talking about multiparts with C- >>>>> D 'info-package', ie multiparts which contain body parts associated with the I-P. >>>>> >>>>> Assume that the Info Package Y specification defines the usage of body parts 'application/aaa' and 'application/bbb'. The >>>>> specification says that both body parts can be sent in a single INFO request, inside a multipart. My proposal was that the >>>>> I-P specification would say what type is used for THAT multipart - because who else will know what type to use? >>>> It first must specify *the* top level part. In your case it will >>>> presumably have decided that it needs some sort of multipart for that, >>>> and will indeed specify which variety/varieties of multipart make sense >>>> for it. >>> Then, take the following example: >>> >>> An INFO request contains only a SINGLE body part (application/aaa), associated with the I-P. >>> >>> The I-P specification says that C-D 'foo' is used for 'application/aaa'. And, since there is only one single body part, the SIP header C-T will indicate 'application/aaa' and the SIP header C-D will indicate 'foo'. >>> >>> Now, WHERE are you going to put the "top level" part, which indicates 'info-package'? >>> >>> Are you going to create a multipart for that single body part, so that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' inside the multipart? >> We have said that the body part associated with an I-P is determined by >> the C-D of info-package. So that is a given when writing the >> specification for the I-P. > > Yes. > >> *If* the I-P wants to receive a single body part, and it wants that to >> have C-D of foo, then it is out of luck. It can then, if it wishes, >> specify that it should receive a multipart (with C-D of info-package) >> containing a single body part of C-T application/aaa and C-D of foo. > > Which is kinda overkill - especially since I think a single body part is going to be the most common INFO use-case. Its only overkill if somebody actually does it. Its a theoretical possibility, but not one I would expect to be used. I can only imagine it being used if there were a case where the disposition can vary, and with a single body part I find that unlikely. > Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a multipart with C-D 'multi-part'. So, you are proposing a case where sometimes the I-P consists of a single, non-multipart, part, and other times it needs that part, and also needs another part, and so then requires a multipart to contain them both. Right? > Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request. In such a case, I have no fundamental objection to using C-D of info-package in both cases, though that might not be the way I would prefer to define it. > So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart I thought I was agreeing with you as I read all the above, > with C-D 'multi-part'. until I got to this part. Did you mean C-T of multipart??? But actually I think I don't agree anyway. I think we should just stop talking about "I-P body part*s*" entirely. It is confusing the discussion immensely. I-P always has *one* body part, which can be of any C-T. I proposed some words for where that body part may reside within the INFO message. Of course that one body part may be a multipart, but we really don't need to say anything about that. Thanks, Paul > Regards, > > Christer > > > > From pkyzivat@cisco.com Mon Oct 26 09:48:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CCC3A6921 for ; Mon, 26 Oct 2009 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0tBvffKO6f9 for ; Mon, 26 Oct 2009 09:48:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 35BCD3A6AF1 for ; Mon, 26 Oct 2009 09:48:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACZv5UpAZnwN/2dsb2JhbADBDJcKhD8E X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="64934916" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Oct 2009 16:48:52 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QGmqt6022415; Mon, 26 Oct 2009 16:48:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:48:52 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 12:48:51 -0400 Message-ID: <4AE5D303.5030402@cisco.com> Date: Mon, 26 Oct 2009 12:49:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 16:48:51.0827 (UTC) FILETIME=[32888C30:01CA565C] Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:48:50 -0000 Brett Tate wrote: > Are INFO bodies required for an info-package? And if so, are 0 length bodies acceptable to meet the requirement? I seem to recall this being discussed before. I think the answer was that a body is required, though I don't know why. I think it should be ok for there not to be a body, though the cases where that would be useful are few. AFAIK there is no distinction between a zero length body and no body. Thanks, Paul > I ask in case there are packages (such as for "flash-hook") where "Info-Package: flash-hook" can signal the INFO needs without otherwise really needing a body. > > Thanks, > Brett > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Mon Oct 26 10:20:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D6B3A67D9 for ; Mon, 26 Oct 2009 10:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2nSl89siPf3 for ; Mon, 26 Oct 2009 10:20:44 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id C95CC28C1E9 for ; Mon, 26 Oct 2009 10:20:40 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 10:20:54 -0700 From: Brett Tate To: Paul Kyzivat Date: Mon, 26 Oct 2009 10:20:48 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content Thread-Index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCg Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> In-Reply-To: <4AE5D303.5030402@cisco.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 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:20:44 -0000 Thanks for the response. Reply inline. > Brett Tate wrote: > > Are INFO bodies required for an info-package? And if so, are > > 0 length bodies acceptable to meet the requirement? >=20 > I seem to recall this being discussed before. > I think the answer was that a body is required, though I don't=20 > know why. If I recall correctly, body usage was desired to prevent packages being def= ined to use headers instead of bodies to communicate their needs. Although= I did not try very hard, I was unable to find explicit text within the dra= ft requiring a body. > AFAIK there is no distinction between a zero length body and no body. It has been argued both ways over the years. If the draft is going to requ= ire a body, it should likely be explicit if 0 length bodies do not meet the= requirement. From christer.holmberg@ericsson.com Mon Oct 26 10:29:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3093A6915 for ; Mon, 26 Oct 2009 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i85rbiBS9w4y for ; Mon, 26 Oct 2009 10:29:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 868F53A6ABD for ; Mon, 26 Oct 2009 10:29:37 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-6e-4ae5dc8d2966 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B3.86.24026.D8CD5EA4; Mon, 26 Oct 2009 18:29:49 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:29:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 18:28:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipcore-info-events-02: empty content thread-index: AcpWWsJOSa6fthkWSbG0CfGyDDCvIgABu4e1 References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "SIPCORE" X-OriginalArrivalTime: 26 Oct 2009 17:29:49.0576 (UTC) FILETIME=[EB774880:01CA5661] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:29:38 -0000 Hi, >Are INFO bodies required for an info-package? And if so, are 0 length = bodies acceptable to meet the requirement? > >I ask in case there are packages (such as for "flash-hook") where = "Info-Package: flash-hook" can signal the INFO needs without otherwise = really needing a body. =20 The current assumption is that all data associated with the I-P will be = carried in the message body. =20 But, if there is no data, e.g. in your example where the Info Package = name "says it all", I see no reason to require a dummy body just in = order to have a body... =20 Regards, =20 Christer =20 From christer.holmberg@ericsson.com Mon Oct 26 10:35:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2013A6B4C for ; Mon, 26 Oct 2009 10:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn97n88QJzsf for ; Mon, 26 Oct 2009 10:35:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 497503A6B14 for ; Mon, 26 Oct 2009 10:34:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-b2-4ae5ddc765f3 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C3.C6.24026.7CDD5EA4; Mon, 26 Oct 2009 18:35:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:33:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 18:30:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content thread-index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0= References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 17:33:41.0898 (UTC) FILETIME=[75F0CEA0:01CA5662] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:35:50 -0000 Hi, =20 >>>Are INFO bodies required for an info-package? And if so, are >>>0 length bodies acceptable to meet the requirement? >> >>I seem to recall this being discussed before. >>I think the answer was that a body is required, though I don't >>know why. > >If I recall correctly, body usage was desired to prevent packages being = defined to use headers instead of bodies to communicate their needs. =20 =20 That is correct. If there is data associated with the I-P, it MUST be = carried in a body. You cannot "re-use" headers. =20 >Although I did not try very hard, I was unable to find explicit text = within the draft requiring a body. If there is no information in addtion to the I-P name, you don't need a = body.=20 Whether such packages makes sense is another issue :) >>AFAIK there is no distinction between a zero length body and no body. > >It has been argued both ways over the years. If the draft is going to = require a body, it should likely be explicit if 0 length bodies do not = meet the requirement. I am not sure I understand. In my opinion C-L 0 means no body. For example, if you use TCP, you MUST set the C-L value. And, if there = is no body, you use C-L 0. Regards, Christer From jmpolk@cisco.com Mon Oct 26 10:41:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E47913A6B3F; Mon, 26 Oct 2009 10:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofKZCSce-2TB; Mon, 26 Oct 2009 10:41:16 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9E3CD3A6867; Mon, 26 Oct 2009 10:41:15 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAJl85UqrR7H+/2dsb2JhbACIGrk8lx6EPwQ X-IronPort-AV: E=Sophos;i="4.44,627,1249257600"; d="scan'208";a="418142095" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 17:41:26 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QHfLfG019430; Mon, 26 Oct 2009 17:41:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:41:23 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.13.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:41:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 12:41:12 -0500 To: "Miguel A. Garcia" , "Thomson, Martin" From: "James M. Polk" In-Reply-To: <4AE555C3.9000109@ericsson.com> References: <4AE555C3.9000109@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Oct 2009 17:41:21.0731 (UTC) FILETIME=[8805C130:01CA5663] Cc: geopriv@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:41:18 -0000 Miguel I saw Martin's note to the WG just after I sent this note to the WG... bad timing, eh? ;-) comments in-line below At 02:54 AM 10/26/2009, Miguel A. Garcia wrote: >James, > >Actually, Martin Thomson has been pushing and submitting this draft. >We (the authors) do not agree with all the content in there, for >which we had little time to react. So, please, take this document as >a mechanism to generate discussion more than as the reflected >consensus among the authors. > >Now, I will give you my personal thoughts below, which, as I said, >might not match other authors'. > > >On 26/10/2009 7:40, James M. Polk wrote: >>Miguel >> >>>old SIP and your targeted Geopriv WGs> >> >>I have concerns about your "Indirect Presence Publication with SIP" draft. >>http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01.txt >> >> >>Currently, and pretty much since whatever version of >>http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt >>has existed in whatever WG it happened to reside in at the time, >>Location Conveyance using SIP has included the use of PUBLISH to convey >>location as a message body, or as a location URI since about, or before >>2005. I fail to see or read what you want in your doc that cannot be >>covered in SIP Location Conveyance. > >I understand that the Geolocation header has quite a few >similarities with what is proposed in the draft. I don't think the >Geolocation header has means to indicate the presence server "you >should de-reference the location and insert it in a presence >document to be offered to watchers". hmmm... it's this a policy choice between the presentity and the presence server (i.e., what to have the PS pass on as a reference, and what the PS dereferences to pass on only as a value)? How can't that be a policy between the PA and PS (including which references to leave as references, and which are dereferenced and sent by the PS as a value)? In that sense, this mechanism (policy notification of which URIs it receives from the PA need to be dereferenced) ought to be general, and not limited to location. I can see one argument being "the PA should include with the URI reference whether or not to do this deference", but that can lead to mistakes - as then each URI the PS receives has to look for the indication -- which is always an extension to how the URI is sent to the PS in the first place. That's clumbersome IMO. Therefore, IMO, this shouldn't be - a new SIP header - with or without a new option-tag - an indication to each way a PS receives a URI but, rather, more general. The issue that has to be watched out for is when 2 or more URIs get sent to the PS and only a subset needs this dereference treatment. >>I cannot figure out how you claim usage of the Geolocation is too limiting. > >I have several criticism to the use of a SIP header to convey this >information. Indirect location is just a particular case of a >general solution, which is, a presentity wants to publish some >information by reference not by value. Location is the more straight >forward example, but we should try to find a general solution. I'm not really understanding this example. If a PA wants to have a watcher get a URI, then the PA sends a URI to the PS. If the PA wants to have the watcher get a value, the PA sends a value to the PS *or* the PA sends a URI to the PS and the PS dereferences the URI to be able to send a value to a watcher. To me this is a function the PS knows to do when it receives certain URIs (i.e., reference types). Receiving a Location URI could be one such situation. I wonder if there is another issue -- shouldn't the PS determine when to send the reference vs. a value mostly based on who is asking for the information? >So, if we agree to pursue a general solution for publication of >presence information by reference, then I find difficult to think of >a solution based on a new or existing SIP header. Instead, we should >be looking at the XML body, either to an extension to the existing >one or a new XML body that. You're proposing have this indication solely in a message body? This appears to me to be overkill just to get a flag from a PA to a PS. I could be wrong though... >If we don't agree with pursuing a general solution, then we should >carefully look at the existing Geolocation header. > >> >>Additionally, I was forced to change the Location: header to the >>Geolocation: header due the SIP WG's conclusion it would be confused , I left how who would be confused -- the issue is RFC 2616 (HTTP) has a "Location" header already, and that's why I had to change Location Conveyance to a Geolocation header. I didn't like it, but have gotten used to it. >>therefore I do not believe you will be able to progress this forward for >>that additional reason as a Location header-value. > >I agree with you, as I said, I don't even think the correct solution >is to use a header at all. I think the chosen name "Location" is >quite unfortunate due to historical reasons. yes to the last part. >/Miguel > >> >>James >> >>BTW -- you use a really old reference for the Location Conveyance ID. It >>is on the -01 version in SIPCORE now, about to be -02. >> > >-- >Miguel A. Garcia >+34-91-339-3608 >Ericsson Spain From jmpolk@cisco.com Mon Oct 26 10:49:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B979128C343; Mon, 26 Oct 2009 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLqWyCzLVAB6; Mon, 26 Oct 2009 10:49:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3684E28C328; Mon, 26 Oct 2009 10:49:09 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAHN95UqrRN+K/2dsb2JhbACIGrkwlx6EPwQ X-IronPort-AV: E=Sophos;i="4.44,627,1249257600"; d="scan'208";a="261590126" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2009 17:49:22 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9QHnM3L010287; Mon, 26 Oct 2009 17:49:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:49:22 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.13.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:49:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 12:49:20 -0500 To: Brian Rosen , Miguel Garcia , "Thomson, Martin" From: "James M. Polk" In-Reply-To: References: <4AE555C3.9000109@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 26 Oct 2009 17:49:22.0293 (UTC) FILETIME=[A675B250:01CA5664] Cc: geopriv@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:49:20 -0000 At 08:43 AM 10/26/2009, Brian Rosen wrote: >I agree that we need a generalized way to indicate indirect presence >publish, and would not want to see a specialized mechanism for location. > >I do think we could add a parameter to Geolocation which was instructions to >the presence server to fetch the location and include it in the presence >notifications, which would be much better than a new header just for that, >but a generalized indirect publish would be better IMO. yeah -- I can add a Geolocation header parameter that is only valid in PUBLISH to have the PS dereference the location URI and only send values to watchers. That said -- I'm wondering if this is such a general purpose mechanism in which the PA will always know the watcher needs to get a location value? I can imagine a policy in the PS determining whether the watcher gets a location URI or a value, perhaps based on who the watcher is. Therefore, unless corrected, I'm more inclined to make this indication (from PA to PS) up to the local policy within the PS as to whether it wants to do this function, or pass on the location URI. Is this agreeable? That said - my other note on this questions whether this ought to go in every different way a reference is sent from a PA to PS (i.e., extending each way a reference is done). Location Conveyance is really easy because this is still an ID, but other specs are more concrete. James >Brian > > >On 10/26/09 3:54 AM, "Miguel Garcia" wrote: > > > James, > > > > Actually, Martin Thomson has been pushing and submitting this draft. We > > (the authors) do not agree with all the content in there, for which we > > had little time to react. So, please, take this document as a mechanism > > to generate discussion more than as the reflected consensus among the > > authors. > > > > Now, I will give you my personal thoughts below, which, as I said, might > > not match other authors'. > > > > > > On 26/10/2009 7:40, James M. Polk wrote: > >> Miguel > >> > >> >> old SIP and your targeted Geopriv WGs> > >> > >> I have concerns about your "Indirect Presence Publication with SIP" draft. > >> > http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01. > >> txt > >> > >> > >> Currently, and pretty much since whatever version of > >> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01 > >> .txt > >> has existed in whatever WG it happened to reside in at the time, > >> Location Conveyance using SIP has included the use of PUBLISH to convey > >> location as a message body, or as a location URI since about, or before > >> 2005. I fail to see or read what you want in your doc that cannot be > >> covered in SIP Location Conveyance. > > > > I understand that the Geolocation header has quite a few similarities > > with what is proposed in the draft. I don't think the Geolocation header > > has means to indicate the presence server "you should de-reference the > > location and insert it in a presence document to be offered to watchers". > > > >> > >> I cannot figure out how you claim usage of the Geolocation is > too limiting. > > > > I have several criticism to the use of a SIP header to convey this > > information. Indirect location is just a particular case of a general > > solution, which is, a presentity wants to publish some information by > > reference not by value. Location is the more straight forward example, > > but we should try to find a general solution. > > > > So, if we agree to pursue a general solution for publication of presence > > information by reference, then I find difficult to think of a solution > > based on a new or existing SIP header. Instead, we should be looking at > > the XML body, either to an extension to the existing one or a new XML > > body that. > > > > If we don't agree with pursuing a general solution, then we should > > carefully look at the existing Geolocation header. > > > >> > >> Additionally, I was forced to change the Location: header to the > >> Geolocation: header due the SIP WG's conclusion it would be confused , > >> therefore I do not believe you will be able to progress this forward for > >> that additional reason as a Location header-value. > > > > I agree with you, as I said, I don't even think the correct solution is > > to use a header at all. I think the chosen name "Location" is quite > > unfortunate due to historical reasons. > > > > /Miguel > > > >> > >> James > >> > >> BTW -- you use a really old reference for the Location Conveyance ID. It > >> is on the -01 version in SIPCORE now, about to be -02. > >> > >> From christer.holmberg@ericsson.com Mon Oct 26 10:52:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA6D28C203 for ; Mon, 26 Oct 2009 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSL5uFOsDlLP for ; Mon, 26 Oct 2009 10:52:02 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7F51C28C0FB for ; Mon, 26 Oct 2009 10:52:01 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-05-4ae5e1cd5f98 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 86.82.31706.DC1E5EA4; Mon, 26 Oct 2009 18:52:13 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:52:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 18:52:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWWya3EhbHqde6SjiEMWKTbA1M/gAB2uhc References: <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 17:52:13.0480 (UTC) FILETIME=[0C7EC280:01CA5665] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:52:03 -0000 Hi, =20 >>>>>> The encoding of the e-mail got a little messed up, so I may have = missed something. >>>>>> >>>>>> I agree that the draft is not describing body handling for = non-INFO body parts. I was only talking about multiparts with C- >>>>>> D 'info-package', ie multiparts which contain body parts = associated with the I-P. >>>>>> >>>>>> Assume that the Info Package Y specification defines the usage of = body parts 'application/aaa' and 'application/bbb'. The >>>>>> specification says that both body parts can be sent in a single = INFO request, inside a multipart. My proposal was that the >>>>>> I-P specification would say what type is used for THAT multipart = - because who else will know what type to use? >>>>> It first must specify *the* top level part. In your case it will >>>>> presumably have decided that it needs some sort of multipart for = that, >>>>> and will indeed specify which variety/varieties of multipart make = sense >>>>> for it. >>>> Then, take the following example: >>>> >>>> An INFO request contains only a SINGLE body part (application/aaa), = associated with the I-P. >>>> >>>> The I-P specification says that C-D 'foo' is used for = 'application/aaa'. And, since there is only one single body part, the = SIP header C-T will indicate 'application/aaa' and the SIP header C-D = will indicate >>>>'foo'. >>>> >>>> Now, WHERE are you going to put the "top level" part, which = indicates 'info-package'? >>>> >>>> Are you going to create a multipart for that single body part, so = that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' = inside the multipart? >>> We have said that the body part associated with an I-P is determined = by >>> the C-D of info-package. So that is a given when writing the >>> specification for the I-P. >> >> Yes. >> >>> *If* the I-P wants to receive a single body part, and it wants that = to >>> have C-D of foo, then it is out of luck. It can then, if it wishes, >>> specify that it should receive a multipart (with C-D of = info-package) >>> containing a single body part of C-T application/aaa and C-D of foo. >> >>Which is kinda overkill - especially since I think a single body part = is going to be the most common INFO use-case. > >Its only overkill if somebody actually does it. >Its a theoretical possibility, but not one I would expect to be used. >I can only imagine it being used if there were a case where the >disposition can vary, and with a single body part I find that unlikely. An I-P COULD define different disposition alternatives for a body part. = But, it is probably not a good idea - unless the body part will always = be inside a multipart with C-D 'info-package'. >>Now, the easiest solution is of course to specify that C-D = 'info-package' shall be used for this body part. BUT, then C-D = 'info-package' shall be used also if the body part would be placed = inside a multipart >>with C-D 'multi-part'. > >So, you are proposing a case where sometimes the I-P consists of a >single, non-multipart, part, and other times it needs that part, and >also needs another part, and so then requires a multipart to contain >them both. Right? Yes. Assume that the I-P specification allows the usage of two different body = parts (app/aaa and app/bbb). But, that may not mean that the body parts = will always be used together. So, if only one of them it used (and there = is no other body part in the INFO) there would be no need for multipart. = But, if both are used in the same INFO there would be a need for = multipart. But, in all cases the C-D value for app/aaa and app/bee should be the = same. And, in this case the C-D value would have to be 'info-package', = since they can be used as the only body part of the message. >>Again, my point is that a single body part (non-multipart) should have = the same C-D value no matter where it is located in the INFO request. > >In such a case, I have no fundamental objection to using C-D of = info-package in both cases, though that might not be the way I would >prefer to define it. I think the easiest thing is to say that any body part, no matter = whether it's inside of a multipart or not, can have C-D 'info-package'. = And, if anohter C-D value is used, the body part MUST be inside a = multipart with C-D 'info-package'. But, the body inside that multipart = could also have C-D 'info-package' - especially if the body part could = also be used without a multipart. >>So, I think that we should allow non-'info-package' C-D values for I-P = body parts ONLY if they will ALWAYS be located inside a multipart > >I thought I was agreeing with you as I read all the above, > >> with C-D 'multi-part'. > >until I got to this part. Did you mean C-T of multipart??? Yes :) >But actually I think I don't agree anyway. I think we should just stop >talking about "I-P body part*s*" entirely. It is confusing the >discussion immensely. > >I-P always has *one* body part, which can be of any C-T. Yes. Or, to be clear: I-P always has one "top level" body part. Inside an I-P = multipart there may of course be multiple body parts associated with the = I-P. >I proposed some words for where that body part may reside within the = INFO message. > >Of course that one body part may be a multipart, but we really don't = need to say anything about that. We do need to say that if an I-P uses non-'info-package' C-D values for = body parts they MUST always be located inside a multipart with C-D = 'info-package'. Regards, Christer =20 From brett@broadsoft.com Mon Oct 26 11:02:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05A13A6B23 for ; Mon, 26 Oct 2009 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvZ-x3SquJlM for ; Mon, 26 Oct 2009 11:02:38 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 253EC3A6B12 for ; Mon, 26 Oct 2009 11:02:38 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 11:02:51 -0700 From: Brett Tate To: Christer Holmberg , Paul Kyzivat Date: Mon, 26 Oct 2009 11:02:45 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content Thread-Index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8A== Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> 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 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:02:39 -0000 > >>AFAIK there is no distinction between a zero length body and no body. > > > >It has been argued both ways over the years. If the draft is going to > require a body, it should likely be explicit if 0 length bodies do not > meet the requirement. >=20 > I am not sure I understand. In my opinion C-L 0 means no body. >=20 > For example, if you use TCP, you MUST set the C-L value. And, if there > is no body, you use C-L 0. The debate usually relates to the validity of Content-Type, and other Conte= nt-* headers present when Content-Length is 0. The following is a snippet = from Henning's reply to my question years ago (9/28/2000). Sorry, I don't = recall how to link to the old "sip@lists.bell-labs.com" email threads for r= eference. "technically, there is nothing wrong with=20 Content-Type: text/plain Content-Length: 0 Who says that a text object cannot have zero length?" From christer.holmberg@ericsson.com Mon Oct 26 11:10:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7EC3A6B54 for ; Mon, 26 Oct 2009 11:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE0YcoD1UGK9 for ; Mon, 26 Oct 2009 11:10:17 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 13BE13A69A1 for ; Mon, 26 Oct 2009 11:10:04 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-50-4ae5e6096c97 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C9.03.31706.906E5EA4; Mon, 26 Oct 2009 19:10:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 19:10:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 19:07:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content thread-index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8AABDvT2 References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 18:10:05.0342 (UTC) FILETIME=[8B5FEBE0:01CA5667] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:10:18 -0000 Hi, >>>>AFAIK there is no distinction between a zero length body and no = body. >>> >>>It has been argued both ways over the years. If the draft is going = to >>>require a body, it should likely be explicit if 0 length bodies do = not >>>meet the requirement. >> >>I am not sure I understand. In my opinion C-L 0 means no body. >> >>For example, if you use TCP, you MUST set the C-L value. And, if there >>is no body, you use C-L 0. > >The debate usually relates to the validity of Content-Type, and other = Content-* headers present when Content-Length is 0. The following is a = snippet from Henning's reply to my question years ago=20 >(9/28/2000). Sorry, I don't recall how to link to the old = "sip@lists.bell-labs.com" email threads for reference. > >"technically, there is nothing wrong with > >Content-Type: text/plain >Content-Length: 0 > >Who says that a text object cannot have zero length?" Ok, so it can have zero length... But, I see no reason to mandate such thing for Info Packages.=20 Regards, Christer =20 From brett@broadsoft.com Mon Oct 26 11:38:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC25528C203 for ; Mon, 26 Oct 2009 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlj9GRSLheMf for ; Mon, 26 Oct 2009 11:38:13 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 2632728C19A for ; Mon, 26 Oct 2009 11:38:13 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 11:38:27 -0700 From: Brett Tate To: Christer Holmberg , Paul Kyzivat Date: Mon, 26 Oct 2009 11:38:20 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content Thread-Index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8AABDvT2AAAgT+A= Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB2F9@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> 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 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 18:38:13 -0000 > Ok, so it can have zero length... >=20 > But, I see no reason to mandate such thing for Info Packages. Sounds good to me. An info package can be defined without the need to use = bodies. From pkyzivat@cisco.com Mon Oct 26 13:19:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A905228C145 for ; Mon, 26 Oct 2009 13:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8ApUQNC9M6f for ; Mon, 26 Oct 2009 13:19:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F3AB228C13B for ; Mon, 26 Oct 2009 13:19:39 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAMeh5UqQ/uCWe2dsb2JhbACbOQEBFiQGpX+XO4Q/BA X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="52816049" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 20:19:52 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QKJqkU005935; Mon, 26 Oct 2009 20:19:52 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:19:52 +0100 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:19:51 +0100 Message-ID: <4AE60463.6010109@cisco.com> Date: Mon, 26 Oct 2009 16:19:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 20:19:51.0842 (UTC) FILETIME=[AC7D8820:01CA5679] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:19:46 -0000 Christer Holmberg wrote: Trimming out some of the older stuff... >>> Now, the easiest solution is of course to specify that C-D 'info-package' shall be used for this body part. BUT, then C-D 'info-package' shall be used also if the body part would be placed inside a multipart >>with C-D 'multi-part'. >> So, you are proposing a case where sometimes the I-P consists of a >> single, non-multipart, part, and other times it needs that part, and >> also needs another part, and so then requires a multipart to contain >> them both. Right? > > Yes. > > Assume that the I-P specification allows the usage of two different body parts (app/aaa and app/bbb). But, that may not mean that the body parts will always be used together. So, if only one of them it used (and there is no other body part in the INFO) there would be no need for multipart. But, if both are used in the same INFO there would be a need for multipart. > > But, in all cases the C-D value for app/aaa and app/bee should be the same. And, in this case the C-D value would have to be 'info-package', since they can be used as the only body part of the message. In that scenario I would be inclined to specify use of the multipart all the time. But that is a judgment call. Ultimately the I-P can define it either way. >>> Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request. >> In such a case, I have no fundamental objection to using C-D of info-package in both cases, though that might not be the way I would >> prefer to define it. > > I think the easiest thing is to say that any body part, no matter whether it's inside of a multipart or not, can have C-D 'info-package'. And, if anohter C-D value is used, the body part MUST be inside a multipart with C-D 'info-package'. But, the body inside that multipart could also have C-D 'info-package' - especially if the body part could also be used without a multipart. I think that is true, but its confusing to say. This document need only say how the C-D of info-package is used to select the part associated with the I-P of the INFO message. What C-D info-package means in any other context can be left unspecified. >>> So, I think that we should allow non-'info-package' C-D values for I-P body parts ONLY if they will ALWAYS be located inside a multipart >> I thought I was agreeing with you as I read all the above, >> >>> with C-D 'multi-part'. >> until I got to this part. Did you mean C-T of multipart??? > > Yes :) > >> But actually I think I don't agree anyway. I think we should just stop >> talking about "I-P body part*s*" entirely. It is confusing the >> discussion immensely. >> >> I-P always has *one* body part, which can be of any C-T. > > Yes. > > Or, to be clear: I-P always has one "top level" body part. Inside an I-P multipart there may of course be multiple body parts associated with the I-P. > >> I proposed some words for where that body part may reside within the INFO message. >> >> Of course that one body part may be a multipart, but we really don't need to say anything about that. > > We do need to say that if an I-P uses non-'info-package' C-D values for body parts they MUST always be located inside a multipart with C-D 'info-package'. I don't think we need to say that. IMO it is clearer to *not* say it. > Regards, > > Christer > > > > From drage@alcatel-lucent.com Mon Oct 26 13:51:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E423A692E; Mon, 26 Oct 2009 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mapelAQswMx; Mon, 26 Oct 2009 13:51:11 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 73D8E3A67CC; Mon, 26 Oct 2009 13:51:11 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9QKon5Q004277 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Oct 2009 21:50:49 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 26 Oct 2009 21:50:49 +0100 From: "DRAGE, Keith (Keith)" To: "James M. Polk" , Brian Rosen , Miguel Garcia , "Thomson, Martin" Date: Mon, 26 Oct 2009 21:50:47 +0100 Thread-Topic: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish Thread-Index: AcpWZTOBB5RyY6gfSOCsp++2SC6rPgAGK5Vw Message-ID: References: <4AE555C3.9000109@ericsson.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] [Geopriv] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:51:13 -0000 Please only make further enhancements to location conveyance after seeking = endorsement of the sipcore list. Primarily we need to concentrate on getting out what we have. regards Keith=20 > -----Original Message----- > From: geopriv-bounces@ietf.org=20 > [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk > Sent: Monday, October 26, 2009 5:49 PM > To: Brian Rosen; Miguel Garcia; Thomson, Martin > Cc: geopriv@ietf.org; sipcore@ietf.org > Subject: Re: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish >=20 > At 08:43 AM 10/26/2009, Brian Rosen wrote: > >I agree that we need a generalized way to indicate indirect presence=20 > >publish, and would not want to see a specialized mechanism=20 > for location. > > > >I do think we could add a parameter to Geolocation which was=20 > >instructions to the presence server to fetch the location=20 > and include=20 > >it in the presence notifications, which would be much better=20 > than a new=20 > >header just for that, but a generalized indirect publish=20 > would be better IMO. >=20 > yeah -- I can add a Geolocation header parameter that is only=20 > valid in PUBLISH to have the PS dereference the location URI=20 > and only send values to watchers. >=20 > That said -- I'm wondering if this is such a general purpose=20 > mechanism in which the PA will always know the watcher needs=20 > to get a location value? I can imagine a policy in the PS=20 > determining whether the watcher gets a location URI or a=20 > value, perhaps based on who the watcher is. >=20 > Therefore, unless corrected, I'm more inclined to make this=20 > indication (from PA to PS) up to the local policy within the=20 > PS as to whether it wants to do this function, or pass on the=20 > location URI. >=20 > Is this agreeable? >=20 > That said - my other note on this questions whether this=20 > ought to go in every different way a reference is sent from a=20 > PA to PS (i.e., extending each way a reference is done). =20 > Location Conveyance is really easy because this is still an=20 > ID, but other specs are more concrete. >=20 > James >=20 >=20 > >Brian > > > > > >On 10/26/09 3:54 AM, "Miguel Garcia"=20 > wrote: > > > > > James, > > > > > > Actually, Martin Thomson has been pushing and submitting=20 > this draft.=20 > > > We (the authors) do not agree with all the content in there, for=20 > > > which we had little time to react. So, please, take this=20 > document as=20 > > > a mechanism to generate discussion more than as the reflected=20 > > > consensus among the authors. > > > > > > Now, I will give you my personal thoughts below, which,=20 > as I said,=20 > > > might not match other authors'. > > > > > > > > > On 26/10/2009 7:40, James M. Polk wrote: > > >> Miguel > > >> > > >> crosses both=20 > > >> the old SIP and your targeted Geopriv WGs> > > >> > > >> I have concerns about your "Indirect Presence=20 > Publication with SIP" draft. > > >>=20 > >=20 > http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indir > ect-publish-01. > > >> txt > > >> > > >> > > >> Currently, and pretty much since whatever version of > > >>=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-convey > > ance-01 > > >> .txt > > >> has existed in whatever WG it happened to reside in at the time,=20 > > >> Location Conveyance using SIP has included the use of PUBLISH to=20 > > >> convey location as a message body, or as a location URI since=20 > > >> about, or before 2005. I fail to see or read what you=20 > want in your=20 > > >> doc that cannot be covered in SIP Location Conveyance. > > > > > > I understand that the Geolocation header has quite a few=20 > > > similarities with what is proposed in the draft. I don't=20 > think the=20 > > > Geolocation header has means to indicate the presence server "you=20 > > > should de-reference the location and insert it in a=20 > presence document to be offered to watchers". > > > > > >> > > >> I cannot figure out how you claim usage of the Geolocation is > > too limiting. > > > > > > I have several criticism to the use of a SIP header to=20 > convey this=20 > > > information. Indirect location is just a particular case of a=20 > > > general solution, which is, a presentity wants to publish some=20 > > > information by reference not by value. Location is the=20 > more straight=20 > > > forward example, but we should try to find a general solution. > > > > > > So, if we agree to pursue a general solution for publication of=20 > > > presence information by reference, then I find difficult=20 > to think of=20 > > > a solution based on a new or existing SIP header.=20 > Instead, we should=20 > > > be looking at the XML body, either to an extension to the=20 > existing=20 > > > one or a new XML body that. > > > > > > If we don't agree with pursuing a general solution, then=20 > we should=20 > > > carefully look at the existing Geolocation header. > > > > > >> > > >> Additionally, I was forced to change the Location: header to the > > >> Geolocation: header due the SIP WG's conclusion it would be=20 > > >> confused , therefore I do not believe you will be able=20 > to progress=20 > > >> this forward for that additional reason as a Location=20 > header-value. > > > > > > I agree with you, as I said, I don't even think the=20 > correct solution=20 > > > is to use a header at all. I think the chosen name "Location" is=20 > > > quite unfortunate due to historical reasons. > > > > > > /Miguel > > > > > >> > > >> James > > >> > > >> BTW -- you use a really old reference for the Location=20 > Conveyance=20 > > >> ID. It is on the -01 version in SIPCORE now, about to be -02. > > >> > > >> >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > = From christer.holmberg@ericsson.com Mon Oct 26 14:08:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 046D23A6A8E for ; Mon, 26 Oct 2009 14:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34Q5MI-8M+5O for ; Mon, 26 Oct 2009 14:08:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A6B363A69D0 for ; Mon, 26 Oct 2009 14:08:31 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-23-4ae60fdb0eb0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5E.CC.04191.BDF06EA4; Mon, 26 Oct 2009 22:08:44 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 22:07:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 22:06:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content thread-index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8AABDvT2AAAgT+AABh30ew== References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2F9@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 21:07:42.0839 (UTC) FILETIME=[5BBCE870:01CA5680] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:08:33 -0000 >>Ok, so it can have zero length... > >>But, I see no reason to mandate such thing for Info Packages. > >Sounds good to me. An info package can be defined without the need to = use bodies. =20 We could say something like this: =20 "Any information associated with the Info Package, apart from the Info = Package name, MUST be transported in the message body of the request." =20 Then we don't require a body, in case there would be a package where the = package name is enough. =20 Regards, =20 Christer From christer.holmberg@ericsson.com Mon Oct 26 14:53:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1444C28C166 for ; Mon, 26 Oct 2009 14:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn2kuYdMeYvC for ; Mon, 26 Oct 2009 14:53:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A772C28C150 for ; Mon, 26 Oct 2009 14:53:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-14-4ae61a58bbe5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3C.AD.04191.85A16EA4; Mon, 26 Oct 2009 22:53:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 22:52:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 22:52:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: VS: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWea2Rr3Fw57VwR5uPmMm5mGsU3QABxW7z References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> <4AE604 63.6010109@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 21:52:22.0058 (UTC) FILETIME=[98AD48A0:01CA5686] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:53:18 -0000 Hi, =20 >>Assume that the I-P specification allows the usage of two different = body parts (app/aaa and app/bbb). But, that may not mean that the body = parts will always be used together. So, if only one of them it used (and = there is no other body part in the INFO) there would be no=20 >>need for multipart. But, if both are used in the same INFO there would = be a need for multipart. >> >>But, in all cases the C-D value for app/aaa and app/bee should be the = same. And, in this case the C-D value would have to be 'info-package', = since they can be used as the only body part of the message. > >In that scenario I would be inclined to specify use of the multipart = all the time. But that is a judgment call. Ultimately the I-P can define = it either way. Sure. But, keep in mind that the sender may not know whether someone = else will insert a non-I-P body into the message, so the original body = part may end up in a multipart, and that is one of the reasons why I = think that body parts associated with the I-P must have the same C-D = value no matter where they are "located" in the message body structure. >>>> Again, my point is that a single body part (non-multipart) should = have the same C-D value no matter where it is located in the INFO = request. >>>In such a case, I have no fundamental objection to using C-D of = info-package in both cases, though that might not be the way I would = refer to define it. >> >>I think the easiest thing is to say that any body part, no matter = whether it's inside of a multipart or not, can have C-D 'info-package'. = And, if anohter C-D value is used, the body part MUST be inside a = multipart with C-D 'info-package'. But, the body inside that multipart = >>could also have C-D 'info-package' - especially if the body part could = also be used without a multipart. > >I think that is true, but its confusing to say. >This document need only say how the C-D of info-package is used to >select the part associated with the I-P of the INFO message. What C-D >info-package means in any other context can be left unspecified. In my opinion C-D 'info-package' ALWAYS means "this body part is = associated with the Info Package". >>We do need to say that if an I-P uses non-'info-package' C-D values = for body parts they MUST always be located inside a multipart with C-D = 'info-package'. > >I don't think we need to say that. IMO it is clearer to *not* say it. We DO need to prevent users from putting those on the "top level". What about? "In the message body of the INFO request, the main body part associated = with the I-P MUST use a C-D 'info-package' value, in order to = distinguish the body part associated with the I-P from possible other = body parts in the request. If there is a need to include multiple body = parts associated with the I-P, or to include a body part for which the = I-P specification defines a non-'info-package' C-D value, such body = parts MUST be collected inside a multipart body part with a C-D = 'info-package' value. The I-P specification MUST describe what type = multipart is to be used in such cases. An I-P specification SHOULD always specifiy a C-D 'info-package' value = to be used for each individual body part associated with that I-P, = unless another value is required in order for the remote application to = be able to process the body part information correctly." We could probably add some examples also. Regards, Christer From brett@broadsoft.com Mon Oct 26 15:00:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CACC28C2BB for ; Mon, 26 Oct 2009 15:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRChS2N2T4nZ for ; Mon, 26 Oct 2009 15:00:53 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 7F5F328C19B for ; Mon, 26 Oct 2009 15:00:50 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 26 Oct 2009 15:01:04 -0700 From: Brett Tate To: Christer Holmberg , Paul Kyzivat Date: Mon, 26 Oct 2009 15:00:58 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content Thread-Index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8AABDvT2AAAgT+AABh30ewAAWbQQ Message-ID: <747A6506A991724FB09B129B79D5FEB613ABABB3CE@EXMBXCLUS01.citservers.local> References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2F9@EXMBXCLUS01.citservers.local> 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 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:00:54 -0000 Hi Christer, Concerning the topic of INFO headers versus body, I don't have a strong opi= nion. I'm actually more in favor of the draft not being overly restrictive= concerning what headers or bodies might be needed for the INFO packages. The mention text appears to conflict with potential Info-Package parameters= . However without such restrictions, vendors might be tempted to start sho= ving package data within Info-Package header as parameters when a body migh= t be more appropriate. :) > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, October 26, 2009 5:06 PM > To: Brett Tate; Paul Kyzivat > Cc: SIPCORE > Subject: RE: [sipcore] draft-ietf-sipcore-info-events-02: empty content >=20 >=20 > >>Ok, so it can have zero length... > > > >>But, I see no reason to mandate such thing for Info Packages. > > > >Sounds good to me. An info package can be defined without the need to > use bodies. >=20 > We could say something like this: >=20 > "Any information associated with the Info Package, apart from the Info > Package name, MUST be transported in the message body of the request." >=20 > Then we don't require a body, in case there would be a package where > the package name is enough. >=20 > Regards, >=20 > Christer >=20 From christer.holmberg@ericsson.com Mon Oct 26 15:22:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB0B3A69D1 for ; Mon, 26 Oct 2009 15:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O-lkagVgxWw for ; Mon, 26 Oct 2009 15:22:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5BE2A3A69AF for ; Mon, 26 Oct 2009 15:22:29 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-f5-4ae621317f42 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 74.3C.24026.13126EA4; Mon, 26 Oct 2009 23:22:41 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 23:21:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 23:21:50 +0100 Message-ID: In-Reply-To: <747A6506A991724FB09B129B79D5FEB613ABABB3CE@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-info-events-02: empty content thread-index: AcpWXDPfDx3h8je7R2isQo8enRWWgQAAUbCgAAEelw0AAD2u8AABDvT2AAAgT+AABh30ewAAWbQQAAIMk+A= References: <747A6506A991724FB09B129B79D5FEB613ABABB26F@EXMBXCLUS01.citservers.local> <4AE5D303.5030402@cisco.com> <747A6506A991724FB09B129B79D5FEB613ABABB295@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2CB@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB2F9@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB613ABABB3CE@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "Paul Kyzivat" X-OriginalArrivalTime: 26 Oct 2009 22:21:50.0839 (UTC) FILETIME=[B6F3D870:01CA568A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: empty content X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:22:30 -0000 Hi,=20 >Concerning the topic of INFO headers versus body, I don't have a strong opinion. I'm actually more in favor of the draft not being overly restrictive concerning what headers or bodies might be needed=20 >for the INFO packages. Previous versions of the draft did allow "re-use" of headers. However, there was a comment that an application may not always know whether specific headers will be included, and whether they would always contain the value intended by the application (the application may not have access to all SIP headers), so for that reason we decided that the information shall be in the body - even if in some cases the information could also be retreived from some SIP header. >The mention text appears to conflict with potential Info-Package parameters. Good point. The text should say "apart from the Info Package name and potential Info-Package header field parameters". >However without such restrictions, vendors might be tempted to start shoving package data within Info-Package header as parameters when a body might be more appropriate. :) Well, using header field values is not specific to Info Packages, so I guess we just need to trust that people do what is best for the protocol :) I guess we could say something that the parameters should contain information associated with the usage of the I-P, rather than pure application data. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, October 26, 2009 5:06 PM > To: Brett Tate; Paul Kyzivat > Cc: SIPCORE > Subject: RE: [sipcore] draft-ietf-sipcore-info-events-02: empty=20 > content >=20 >=20 > >>Ok, so it can have zero length... > > > >>But, I see no reason to mandate such thing for Info Packages. > > > >Sounds good to me. An info package can be defined without the need=20 > >to > use bodies. >=20 > We could say something like this: >=20 > "Any information associated with the Info Package, apart from the Info > Package name, MUST be transported in the message body of the request." >=20 > Then we don't require a body, in case there would be a package where=20 > the package name is enough. >=20 > Regards, >=20 > Christer >=20 From christer.holmberg@ericsson.com Mon Oct 26 15:37:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFCD28C3F9 for ; Mon, 26 Oct 2009 15:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdBUJXY6lwf5 for ; Mon, 26 Oct 2009 15:37:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4955028C3E4 for ; Mon, 26 Oct 2009 15:37:35 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-74-4ae624bb2faf Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F0.DE.04191.BB426EA4; Mon, 26 Oct 2009 23:37:47 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 23:37:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA568C.F0AD6DC8" Date: Mon, 26 Oct 2009 23:37:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipcore-info-events-02: WGLC comment and questions - Brett thread-index: AcpWRmKHGMuKpE6vRvC/3lg3UdC4/wAH1ez6 References: <747A6506A991724FB09B129B79D5FEB613ABABB1B8@EXMBXCLUS01.citservers.local> From: "Christer Holmberg" To: "Brett Tate" , "SIPCORE" X-OriginalArrivalTime: 26 Oct 2009 22:37:47.0453 (UTC) FILETIME=[F1238ED0:01CA568C] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-info-events-02: WGLC comment and questions - Brett X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:37:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA568C.F0AD6DC8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Brett, =20 ------------------ >Section 3.2 paragraph 2: Concerning "during the dialog establishment, and during a target refresh", how should it be interpreted in relation to PRACK and ACK discussed within the next sentence? More=20 >specifically, is indication of Recv-Info limited to call setup or can it be performed during the re-INVITE process? =20 It can be performed during a re-INVITE process. That should be covered with "during a target refresh", which can occur at any time. =20 ------------------ >Section 3.2 paragraph 3: "to INFO" should likely be "to receive INFO". The last sentence potentially could be reworded to avoid "This" ambiguity. =20 Yes. =20 ------------------ >Section 3.5: It is unclear if OPTIONS within dialog can be used to communicate a Recv-Info change similar to target refresh requests like UPDATE. =20 OPTIONS is only used for general queries - not for specific dialog queries, and not to update dialog information. =20 So, if you send OPTIONS inside a dialog, the packages in the response may not be the same packages that you have indicated support of for that particular dialog. =20 ------------------ >Section 3.5 paragraph 1: The strength of "SHALL" is likely too strong and potentially conflicts with the drafts table 2. In case it matters, RFC 3261 tables 2 and 3 indicated "m*" for various OPTIONS=20 >headers. For compliance, is this "SHALL" going to cause devices that use OPTIONS as a device ping (outside of dialog) to be required to add Recv-Info if they support this draft? =20 In my opinion, if we put a "SHOULD" we should indicate when something does NOT apply. Otherwise the text is useless when it comes to things like conformance testing etc... =20 ------------------ >Section 4.4 and table 2: Concerning the 469, should it be optional (or mandatory) to return Recv-Info? =20 Good point. I think that the 469 shall contain Recv-Info (in the same way as 420 contains Supported). =20 ------------------ >Section 5.1 figure 1: Retry-After needs a 500 next to the 503. =20 Ok. =20 ------------------ >Section 6.1 table 2: ACK responses should have "-" instead of "o". =20 Yes. =20 ------------------ >Section 6.1 table 2: Because of rfc4320, the "Recv-Info 1xx" row should likely only have "-" everywhere except INV. =20 Yes. =20 ------------------ >Section 6.1 table 2: Is there really a current reason for "Recv-Info r" row? If so or not, why would UPD have an "o" when INV has a "-"? =20 I think INV should also have it. I can't think of any specific reason why we would need the "r" row at this point. But, does it harm? Maybe there will be a future use-case at some point... =20 In addition, if we agree on the MUST for 469, I guess we should add a row for 469 with "m". =20 ------------------ >Section 11.4 bullet 2: Since it doesn't follow the related rfc4485 section 4.4 "SHOULD", why are the parameter names and values case-sensitive? =20 You are right. 4485 says "Header field parameter names MUST be case insensitive". =20 ------------------ =20 A big thank you for your comments I give! :) =20 Regards, =20 Christer =20 =20 ------_=_NextPart_001_01CA568C.F0AD6DC8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-ietf-sipcore-info-events-02: WGLC = comment and questions
Hi Brett,
 
------------------

>Section 3.2 paragraph 2: = Concerning "during=20 the dialog establishment, and during a target refresh", how should it be = interpreted in relation to PRACK and ACK discussed within the next=20 sentence?  More
>specifically, is indication of = Recv-Info limited=20 to call setup or can it be performed during the re-INVITE = process?
 
It can be performed during a re-INVITE = process. That=20 should be covered with "during a target refresh", which can occur at any = time.
 
------------------

>Section 3.2 = paragraph 3:=20 "to INFO" should likely be "to receive INFO".  The last sentence=20 potentially could be reworded to avoid "This" ambiguity.
 
Yes.
 
------------------

>Section 3.5: It is unclear if = OPTIONS within=20 dialog can be used to communicate a Recv-Info change similar to target = refresh=20 requests like UPDATE.
 
OPTIONS is only used for = general queries -=20 not for specific dialog queries, and not to update dialog=20 information.
 
So, if you send OPTIONS inside a dialog, = the packages=20 in the response may not be the same packages that you have indicated = support of=20 for that particular dialog.
 
------------------

>Section 3.5 paragraph 1: The = strength of=20 "SHALL" is likely too strong and potentially conflicts with the drafts = table=20 2.  In case it matters, RFC 3261 tables 2 and 3 indicated "m*" for = various=20 OPTIONS
>headers.  For compliance, is this = "SHALL"=20 going to cause devices that use OPTIONS as a device ping (outside of = dialog) to=20 be required to add Recv-Info if they support this draft?
 
In my opinion, if we put a "SHOULD" = we should=20 indicate when something does NOT apply. Otherwise the text is useless = when it=20 comes to things like conformance testing etc...
 
------------------

>Section 4.4 and table 2: = Concerning the 469,=20 should it be optional (or mandatory) to return Recv-Info?
 
Good = point. I think=20 that the 469 shall contain Recv-Info (in the same way as 420 = contains=20 Supported).
 
------------------

>Section 5.1 figure 1: Retry-After = needs a=20 500 next to the 503.
 
Ok.
 
------------------

>Section 6.1 table = 2: ACK=20 responses should have "-" instead of "o".
 
Yes.
 
------------------
<= FONT=20 face=3DArial size=3D2>

>Section 6.1 table 2: Because of = rfc4320, the=20 "Recv-Info 1xx" row should likely only have "-" everywhere except = INV.
 
Yes.
 
------------------

>Section 6.1 table = 2: Is there=20 really a current reason for "Recv-Info r" row?  If so or not, why = would UPD=20 have an "o" when INV has a "-"?
 
I = think INV should=20 also have it. I can't think of any specific reason why we would need the = "r" row=20 at this point. But, does it harm? Maybe there will be a future use-case = at some=20 point...
 
In = addition, if we=20 agree on the MUST for 469, I guess we should add a row for 469 with=20 "m".
 
------------------

>Section 11.4 bullet = 2: Since=20 it doesn't follow the related rfc4485 section 4.4 "SHOULD", why are the=20 parameter names and values case-sensitive?
 
You are right. 4485 says "Header field = parameter names=20 MUST be case insensitive".
 
------------------
 
A big thank you for your comments I give!=20 :)
 
Regards,
 
Christer
 
 


------_=_NextPart_001_01CA568C.F0AD6DC8-- From pkyzivat@cisco.com Mon Oct 26 16:24:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C593A69CF for ; Mon, 26 Oct 2009 16:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNqP+Fov4Vmv for ; Mon, 26 Oct 2009 16:24:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 397753A692E for ; Mon, 26 Oct 2009 16:24:55 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACPN5UqrR7H+/2dsb2JhbADBVJdghD8E X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="261768125" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2009 23:24:45 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QNOeFt028949; Mon, 26 Oct 2009 23:24:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 19:24:43 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 19:24:43 -0400 Message-ID: <4AE62FA6.5060800@cisco.com> Date: Mon, 26 Oct 2009 19:24:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> <4AE604 63.6010109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2009 23:24:43.0134 (UTC) FILETIME=[7F6A61E0:01CA5693] Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:24:56 -0000 Christer Holmberg wrote: > Hi, > >>> Assume that the I-P specification allows the usage of two different body parts (app/aaa and app/bbb). But, that may not mean that the body parts will always be used together. So, if only one of them it used (and there is no other body part in the INFO) there would be no >>> need for multipart. But, if both are used in the same INFO there would be a need for multipart. >>> >>> But, in all cases the C-D value for app/aaa and app/bee should be the same. And, in this case the C-D value would have to be 'info-package', since they can be used as the only body part of the message. >> In that scenario I would be inclined to specify use of the multipart all the time. But that is a judgment call. Ultimately the I-P can define it either way. > > Sure. But, keep in mind that the sender may not know whether someone else will insert a non-I-P body into the message, so the original body part may end up in a multipart, and that is one of the reasons why I think that body parts associated with the I-P must have the same C-D value no matter where they are "located" in the message body structure. All you need to know is the rule for finding the *while* I-P body part. That has nothing to do with whether the I-P is multipart or not, or is always the same type or not. Once you have found it, *then* you need to consult the specs for your I-P to figure out what to do next. You need no more *generic* instructions on this part. >>>>> Again, my point is that a single body part (non-multipart) should have the same C-D value no matter where it is located in the INFO request. >>>> In such a case, I have no fundamental objection to using C-D of info-package in both cases, though that might not be the way I would refer to define it. >>> I think the easiest thing is to say that any body part, no matter whether it's inside of a multipart or not, can have C-D 'info-package'. And, if anohter C-D value is used, the body part MUST be inside a multipart with C-D 'info-package'. But, the body inside that multipart >>could also have C-D 'info-package' - especially if the body part could also be used without a multipart. >> I think that is true, but its confusing to say. >> This document need only say how the C-D of info-package is used to >> select the part associated with the I-P of the INFO message. What C-D >> info-package means in any other context can be left unspecified. > > In my opinion C-D 'info-package' ALWAYS means "this body part is associated with the Info Package". What if it isn't in an INFO message? All the C-D values have some contextual definition. For instance "render" clearly means something different in a sip message than it does in an email message. (For rather stupid reasons we are using "render" for the C-D of the multipart that holds otherwise unrelated parts of a sip message.) For example, I might sometime decide to put part/all of an INFO message into a sipfrag, and make that a body part on some other message, perhaps MESSAGE or another INFO. The sipfrag may or may not have the message header that denotes it as an INFO message. The key is that it really doesn't matter. When processing the MESSAGE, the C-D in the sipfrag is not in a context where it is relevant to processing of the MESSAGE. If the body were reconstituted into a full INFO message, and then that message were decoded, then the C-D would be significant. Once it has been removed from the context where we have defined what it means, its meaning has to be taken from context. >>> We do need to say that if an I-P uses non-'info-package' C-D values for body parts they MUST always be located inside a multipart with C-D 'info-package'. >> I don't think we need to say that. IMO it is clearer to *not* say it. > > We DO need to prevent users from putting those on the "top level". We need to do our part here to define what C-D of info-package means at the top level and within a top level multipart of C-D "render". Anything else falls outside the specification of INFO, and might be valid based on references from headers and/or specific other C-D values. This doc doesn't need to specify everything else. For instance, some body part may be referenced from some other extension header that is not understood by the recipient. Whether the message containing that is valid or not will be determined by the body_handling spec, not the INFO spec. > What about? > > "In the message body of the INFO request, the main body part associated with the I-P MUST use a C-D 'info-package' value, in order to distinguish the body part associated with the I-P from possible other body parts in the request. I'm ok with the above. > If there is a need to include multiple body parts associated with the I-P, or to include a body part for which the I-P specification defines a non-'info-package' C-D value, such body parts MUST be collected inside a multipart body part with a C-D 'info-package' value. The I-P specification MUST describe what type multipart is to be used in such cases. None of the above sentence needs to be normative. The prior statement is sufficiently normative. This statement could be reworded in to something non-normative. For example: "NOTE: If an I-P specification has need to allow inclusion of multiple body parts, and/or body part(s) containing a C-D other than info-package, it can specify that the body part associated with I-P can be a multipart type." > An I-P specification SHOULD always specifiy a C-D 'info-package' value to be used for each individual body part associated with that I-P, unless another value is required in order for the remote application to be able to process the body part information correctly." I don't find the above sentence to be at all helpful. > We could probably add some examples also. Yes. It seems people program to the examples, so best to give them good ones. Thanks, Paul > Regards, > > Christer > > From dean.willis@softarmor.com Mon Oct 26 17:41:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9673A6963 for ; Mon, 26 Oct 2009 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bk-hskIRal4X for ; Mon, 26 Oct 2009 17:41:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1A49A3A6778 for ; Mon, 26 Oct 2009 17:41:39 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9R0fJNu007990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 19:41:20 -0500 Message-Id: <9E1F03AB-FE8A-481C-A0B2-7F14D8B1F3AD@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 19:41:13 -0500 References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.c! o m> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:41:40 -0000 On Oct 26, 2009, at 8:25 AM, Christer Holmberg wrote: > Hi, > >>> The encoding of the e-mail got a little messed up, so I may have >>> missed something. >>> >>> I agree that the draft is not describing body handling for non- >>> INFO body parts. I was only talking about multiparts with C- >>> D 'info-package', ie multiparts which contain body parts >>> associated with the I-P. >>> >>> Assume that the Info Package Y specification defines the usage of >>> body parts 'application/aaa' and 'application/bbb'. The >>> specification says that both body parts can be sent in a single >>> INFO request, inside a multipart. My proposal was that the >>> I-P specification would say what type is used for THAT multipart - >>> because who else will know what type to use? >> >> It first must specify *the* top level part. In your case it will >> presumably have decided that it needs some sort of multipart for >> that, >> and will indeed specify which variety/varieties of multipart make >> sense >> for it. > > Then, take the following example: > > An INFO request contains only a SINGLE body part (application/aaa), > associated with the I-P. We're with you so far. > > The I-P specification says that C-D 'foo' is used for 'application/ > aaa'. Then the I-P specification is broken and we should spank the author, the reviewers, and everybody else who let it slip past. Since it is a singular body part, it is also the top-level body part, and MUST have a C-D of "info-package". Otherwise, we have no way of knowing of the body part is intended as the package payload, or is instead a parasitic payload. > And, since there is only one single body part, the SIP header C-T > will indicate 'application/aaa' and the SIP header C-D will indicate > 'foo'. > Not "foo". It will be "info-package". > Now, WHERE are you going to put the "top level" part, which > indicates 'info-package'? Suitably lubricated, into an appropriate orifice. Or maybe skip the lube. > > Are you going to create a multipart for that single body part, so > that you can put C-D 'info-packag' in the SIP header, and C-D 'foo' > inside the multipart? Somehow I think we're totally failing to communicate here. -- Dean From dean.willis@softarmor.com Mon Oct 26 17:53:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03FEB3A69D6 for ; Mon, 26 Oct 2009 17:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIMx7R3lqPss for ; Mon, 26 Oct 2009 17:53:40 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3C0DA3A685C for ; Mon, 26 Oct 2009 17:53:40 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9R0rOS8008037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Oct 2009 19:53:25 -0500 Message-Id: <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 19:53:18 -0500 References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:53:41 -0000 On Oct 26, 2009, at 10:41 AM, Christer Holmberg wrote: > > > Again, my point is that a single body part (non-multipart) should > have the same C-D value no matter where it is located in the INFO > request. > What if you have an INFO package that needs to convey two image/jpegs one for display to the user's left eye and one for the other's right eye? Or any other use case that requires two different components that need to be differentiated between within the package specification? If there is only one body part in the I-P specification , this question does not arise; hence the suitability of marking the singular body part C-D as info-package. But when the I-P specification uses a multipart, we need a way to distinguish the parts. If two or more parts have the same MIM type, we can't differentiate based on type. My current thinking is to use a combination of content type and content disposition. Perhaps this is inadequate, and we need a more explicit mechanism? -- Dean From pkyzivat@cisco.com Mon Oct 26 18:01:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674963A688F for ; Mon, 26 Oct 2009 18:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-39q3rXqou1 for ; Mon, 26 Oct 2009 18:01:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id AA7043A6778 for ; Mon, 26 Oct 2009 18:01:33 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGfj5UpAZnwN/2dsb2JhbADBJJdqhD8E X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="218097852" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2009 01:01:47 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9R11kx4018519; Tue, 27 Oct 2009 01:01:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:01:46 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:01:46 -0400 Message-ID: <4AE6467B.3010206@cisco.com> Date: Mon, 26 Oct 2009 21:01:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> In-Reply-To: <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 01:01:46.0470 (UTC) FILETIME=[0E64F060:01CA56A1] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:01:34 -0000 Dean Willis wrote: > What if you have an INFO package that needs to convey two image/jpegs > one for display to the user's left eye and one for the other's right > eye? I love it!!! Great example. Paul From jmpolk@cisco.com Mon Oct 26 18:35:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0950C3A67C0; Mon, 26 Oct 2009 18:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGMip-ogtiI5; Mon, 26 Oct 2009 18:35:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AA39F3A67FF; Mon, 26 Oct 2009 18:35:23 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAJrr5UqrR7H+/2dsb2JhbACIGrhxl26EPwQ X-IronPort-AV: E=Sophos;i="4.44,629,1249257600"; d="scan'208";a="261807248" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 01:35:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9R1ZbIE004266; Tue, 27 Oct 2009 01:35:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:35:36 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.13.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:35:35 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Oct 2009 20:35:32 -0500 To: "DRAGE, Keith (Keith)" , Brian Rosen , Miguel Garcia , "Thomson, Martin" From: "James M. Polk" In-Reply-To: References: <4AE555C3.9000109@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Oct 2009 01:35:35.0358 (UTC) FILETIME=[C7B4ADE0:01CA56A5] Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] [Geopriv] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:35:25 -0000 At 03:50 PM 10/26/2009, DRAGE, Keith (Keith) wrote: >Please only make further enhancements to location conveyance after >seeking endorsement of the sipcore list. fair -- I was just imagining how it could be done, not that I was going to do this. I'm more concerned about a newly proposed SIP header that recreates at least part of what the SIP Geolocation header can do. >Primarily we need to concentrate on getting out what we have. I agree. James >regards > >Keith > > > -----Original Message----- > > From: geopriv-bounces@ietf.org > > [mailto:geopriv-bounces@ietf.org] On Behalf Of James M. Polk > > Sent: Monday, October 26, 2009 5:49 PM > > To: Brian Rosen; Miguel Garcia; Thomson, Martin > > Cc: geopriv@ietf.org; sipcore@ietf.org > > Subject: Re: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish > > > > At 08:43 AM 10/26/2009, Brian Rosen wrote: > > >I agree that we need a generalized way to indicate indirect presence > > >publish, and would not want to see a specialized mechanism > > for location. > > > > > >I do think we could add a parameter to Geolocation which was > > >instructions to the presence server to fetch the location > > and include > > >it in the presence notifications, which would be much better > > than a new > > >header just for that, but a generalized indirect publish > > would be better IMO. > > > > yeah -- I can add a Geolocation header parameter that is only > > valid in PUBLISH to have the PS dereference the location URI > > and only send values to watchers. > > > > That said -- I'm wondering if this is such a general purpose > > mechanism in which the PA will always know the watcher needs > > to get a location value? I can imagine a policy in the PS > > determining whether the watcher gets a location URI or a > > value, perhaps based on who the watcher is. > > > > Therefore, unless corrected, I'm more inclined to make this > > indication (from PA to PS) up to the local policy within the > > PS as to whether it wants to do this function, or pass on the > > location URI. > > > > Is this agreeable? > > > > That said - my other note on this questions whether this > > ought to go in every different way a reference is sent from a > > PA to PS (i.e., extending each way a reference is done). > > Location Conveyance is really easy because this is still an > > ID, but other specs are more concrete. > > > > James > > > > > > >Brian > > > > > > > > >On 10/26/09 3:54 AM, "Miguel Garcia" > > wrote: > > > > > > > James, > > > > > > > > Actually, Martin Thomson has been pushing and submitting > > this draft. > > > > We (the authors) do not agree with all the content in there, for > > > > which we had little time to react. So, please, take this > > document as > > > > a mechanism to generate discussion more than as the reflected > > > > consensus among the authors. > > > > > > > > Now, I will give you my personal thoughts below, which, > > as I said, > > > > might not match other authors'. > > > > > > > > > > > > On 26/10/2009 7:40, James M. Polk wrote: > > > >> Miguel > > > >> > > > >> > crosses both > > > >> the old SIP and your targeted Geopriv WGs> > > > >> > > > >> I have concerns about your "Indirect Presence > > Publication with SIP" draft. > > > >> > > > > > http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indir > > ect-publish-01. > > > >> txt > > > >> > > > >> > > > >> Currently, and pretty much since whatever version of > > > >> > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-convey > > > ance-01 > > > >> .txt > > > >> has existed in whatever WG it happened to reside in at the time, > > > >> Location Conveyance using SIP has included the use of PUBLISH to > > > >> convey location as a message body, or as a location URI since > > > >> about, or before 2005. I fail to see or read what you > > want in your > > > >> doc that cannot be covered in SIP Location Conveyance. > > > > > > > > I understand that the Geolocation header has quite a few > > > > similarities with what is proposed in the draft. I don't > > think the > > > > Geolocation header has means to indicate the presence server "you > > > > should de-reference the location and insert it in a > > presence document to be offered to watchers". > > > > > > > >> > > > >> I cannot figure out how you claim usage of the Geolocation is > > > too limiting. > > > > > > > > I have several criticism to the use of a SIP header to > > convey this > > > > information. Indirect location is just a particular case of a > > > > general solution, which is, a presentity wants to publish some > > > > information by reference not by value. Location is the > > more straight > > > > forward example, but we should try to find a general solution. > > > > > > > > So, if we agree to pursue a general solution for publication of > > > > presence information by reference, then I find difficult > > to think of > > > > a solution based on a new or existing SIP header. > > Instead, we should > > > > be looking at the XML body, either to an extension to the > > existing > > > > one or a new XML body that. > > > > > > > > If we don't agree with pursuing a general solution, then > > we should > > > > carefully look at the existing Geolocation header. > > > > > > > >> > > > >> Additionally, I was forced to change the Location: header to the > > > >> Geolocation: header due the SIP WG's conclusion it would be > > > >> confused , therefore I do not believe you will be able > > to progress > > > >> this forward for that additional reason as a Location > > header-value. > > > > > > > > I agree with you, as I said, I don't even think the > > correct solution > > > > is to use a header at all. I think the chosen name "Location" is > > > > quite unfortunate due to historical reasons. > > > > > > > > /Miguel > > > > > > > >> > > > >> James > > > >> > > > >> BTW -- you use a really old reference for the Location > > Conveyance > > > >> ID. It is on the -01 version in SIPCORE now, about to be -02. > > > >> > > > >> > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www.ietf.org/mailman/listinfo/geopriv > > From drage@alcatel-lucent.com Mon Oct 26 19:34:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24CB3A67EF for ; Mon, 26 Oct 2009 19:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbHk-ifSYFzv for ; Mon, 26 Oct 2009 19:34:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 89BBB3A6890 for ; Mon, 26 Oct 2009 19:34:28 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9R2YdAZ017622 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Oct 2009 03:34:39 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 27 Oct 2009 03:34:39 +0100 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Tue, 27 Oct 2009 03:34:37 +0100 Thread-Topic: Comments on draft-ietf-sipcore-info-events-02 Thread-Index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 02:34:52 -0000 Various miscellaneous comments. I have not yet trawled through all the othe= r comments and discussion to find if these have already been made elsewhere= . I suspect I will find some other comments at a later time. 1) General. Please write responses in the format "200 (OK) response" rather= than "200 OK response". 2) General. Can we fix on the term of either "Info Package definition" or "= Info Package specification" and use it consistently (in full) throughout wh= ere we mean that term. 3) Section 3.2 A UA which supports the Info Package mechanism MUST indicate, using the Revc-Info header field, the set of Info Packages for which it is willing to receive an INFO request. =20 ^^^ Insert "an" as indicated. 4) Section 3.2: If a UA is not willing to receive INFO requests for any Info Packages, d= uring ^^^^^^^^ dialog establishment or later during the INVITE dialog usage, the UA ^^^^^^^ MUST indicate this by including a Recv-Info header field with a 'nil' value. =20 Insert "receive" as indicated. Replace "invite" with upper case as I believ= e this is the RFC 3261 convention. 5) Section 3.2 indicates: A UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info Package, and a dialog has been established with the remote UA. and section 4.2 indicates: For a specific dialog, a UA MUST NOT send INFO requests associated with Info Packages that the remote UA has not indicated that it is willing to receive. Are these not the same requirement. We need to eliminate one. 6) Section 3.2 indicates: Likewise, even if a UA uses the Recv-Info header field to indicate that it supports the Info Package mechanism, in addition the UA MUST still also explicitly indicate support of the INFO method using the Allow header field. I do not believe this should be a MUST, because it is surely already a MUST= in RFC 3261 - all we need to do is write an informative sentence that in a= ccordance with RFC 3261 the Allow header also indicates INFO requests. 7) Section 3.3: 3.3. Package Versioning The Info Package mechanism does not support package versioning. Specific Info Package payloads MAY contain version information, which is handled by the applications associated with the Info Package, but that is outside the scope of the Info Package mechanism. NOTE: Even if an Info Package name contains version numbering (e.g. foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name. As this is all part of the Info Package name, and needs to form part of the= Info Package specification if used, I think all the text here should be mo= ved to section 10.3, and this section header deleted. 8) Section 4.3 indicates: Info Package specifications MUST describe the application level information associated with the Info Package. Each body part MUST have a MIME type value, and the syntax and content of the body part, defined. Each body part, when associated with an Info Package, MUST have a Content-Disposition header field with an 'Info-Package' value assigned, in order to be able distinguish body parts associated with the Info Package from other body parts. Surely this is something where the MUST can only be met by the designer of = the package, and therefore it belongs in section 10. 9) Section 4.3: NOTE: Some SIP functions that are orthogonal to INFO may insert body parts unrelated to the Info Package. Change "may" to "can". 10) Section 4.3: However, when a body part in the INFO message is associated with an Info Package, it MUST always have a Content-Disposition header field with an 'Info-Package' value assigned. =20 Is this not just a repeat of the requirement earlier in the section (1 para= graph before the note). 11) Section 4.3: This document does not define Info Package specific rules on how body parts associated with Info Packages are to be inserted into multipart body parts, and what type of multiparts are used. If an Info Package requires special rules regarding the usage of multipart body parts, the specification for that Info Package MUST specify such rules. The MUST here has to be in section 10. This paragraph needs to remove the r= equirement, and refer to section 10 instead. 12) Section 4.4: If a UA receives an INFO request for legacy usage, for which no Info- Package is associated (the INFO request does not contain an Info- Package header field), the UA MUST send a 200 OK response. The UAS MAY send other responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx) as appropriate for the request. The second paragraph above contradicts the first above. I assume that means= that there is a hidden condition that is missing from the first paragraph.= Something along the lines of "that is otherwise syntactically correct and = well structured". 13) Section 4.4: If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 Bad INFO Package response Section 11.6. In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure. I assume that "(see Section 11.6)" or something similar is meant in the end= of the first sentence.=20 I believe we also need to define whether the response code applies to the t= ransaction or the dialog. It obviously has to be the transaction. 14) Section 4.6: The Info Package mechanism relies on the CSeq header field to detect if an INFO request is received out of order. Given that nowhere else in the document do we mention CSeq in this respect,= I don't see how it can. I suspect we mean something more like Many Info Packages can rely on the CSeq header field to detect if an INFO request is received out of order. 15) Section 4.6: If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, must be specified as part of the associated Info Package, and possible sequence numbers etc must be defined as application data. Change "must be specified" to "are specified". If we need a real MUST, then= it has to be in section 10 in any case, and I would expect more on this is= sue there. 16) Section 6.2: This document does not define values for Info-Package types. Individual Info Package specifications define these values. Such specifications MUST register the values with IANA. These values are Specification Required [RFC5226]. The MUST part of this paragraph belongs in section 10. It is not something = the implementor of the Inof-Package header field can directly comply with. 17) Section 7.3: One needs to consider the fate of the dialog usage of an INFO request is rejected. In some cases it may be acceptable that the whole dialog usage is terminated, while in other cases is is desirable to maintain the dialog usage. Change "may" to "can". 18) Section 8.2: NOTE on the Recv-Info production: if the header field value is "nil", the header field MUST NOT contain any other Info Packages, and the SIP message MUST NOT contain more than one Recv-Info header field. Please do not start a sentence containing RFC 2119 language with the word "= Note". It confuses the hell out of people who understand that everything fo= llowing that word is informative. In any case, the first half of this sente= nce is surely impossible in the ABNF and therefore the MUST is superfluous. 19) Section 9.3. As described in Section 4, an INFO request associated with an Info Package always contains an Info-Package header field. A legacy INFO request MUST NOT contain an Info-Package header field. The first sentence of the above is fine. However the second sentence is not= conformable by implementations of this specification. So I believe the "MU= ST" is incorrect and should be replaced by something more descriptive. 20) Section 10.1: If an Info Package extends or modifies the behavior described in this document, it MUST be described in the definition for that Info Package. Info Package definitions should not repeat procedures defined in this specification, unless needed for clarification or emphasis purpose. Change "it MUST" to "that behaviour MUST" As for the second sentence, assuming that we do not mean an RFC 2119 SHOULD= , which I believe we do not, reword as follows: "It is bad practice for Inf= o Package defintions to repeat procedures defined in this specification, un= less..." 21) Section 10.1: Info Packages MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Packages MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if applications associated with the Info Package requires it. Do we mean "Info Packages" here or "Info Package Definitions"? (twice) 22) Section 10.2: Annex A provides more information, and describes alternative mechanisms which one should consider for solving a specific use-case. reword to: Annex A provides more information, and describes alternative mechanisms which are considered as part of the process for solving a spe= cific use-case. 23) Section 10.3 The Info Package specification MUST define a for Info Package name (e.g. "Info Package for X"). Do we mean: The Info Package specification MUST define an Info Package name (e.g. "Info Package for X"). 24) Section 10.3 The specification MUST also define the header field value (e.g. "infoX") to be used to indicate support of this package in the Recv- Info and Info-Package header fields. Why do we allow the potential for a separate name for the package, and the = value that appears in the header fields. I see this causing mixed usage in = the IANA registrations. Surely it is simpler that whatever appears in the h= eader fields is by definition the package name. It works for event packages= surely. 25) Section 10.4 Note that Info Package parameters are only applicable for the Info Package(s) for which they have been explicitly defined. They MUST NOT be used for other Info Packages. I don't think we need the MUST here. By virtue of the fact that the Info Pa= ckage specification defines only one Info Package, it can only define param= eters to be associated with one Info Package. Yes other packages may define= a parameter with the same name, but we are not precluding that anyway. So = turn the second sentence into something informative rather than RFC 2119. 26) Section 10.4 NOTE: Info Package parameters defined for specific Info Packages may share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined. Change "may" to "can". 27) Section 10.5 SIP option tags MUST conform to the SIP Change Process [I-D.peterson-rai-rfc3427bis]. I don't believe we need the MUST here. We merely need a sentence that "the = registration requirements for option tags are defined in ...". As you have = only made this an informative reference in any case, that surely has to hap= pen. 28) Section 10.6 The Info Package specification MUST define what type of message body parts are associated with the Info Package, and MUST refer to specifications where the syntax, semantics and MIME type of the message body parts are described. The text above appears to preclude the Info Package specification defining = them itself. 29) Section 10.7 The specification MUST define whether there are SIP level restrictions in the usage of the Info Package. For example, an Info Package may require support of other SIP extensions (e.g. reliable provisional responses). Change "may" to "can". 30) Section 10.7 As the SIP stack may not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section 4.4, in most cases a 200 OK response will be sent for the INFO request. The application logic associated with the Info Package needs to handle situations which can occur due to overlapping requests. Change "may not" to "might not". 31) Section 10.9 The Info Package specification MUST contain an IANA Considerations section that includes definitions for the Info Package Name and, if needed, supported MIME types. I believe this is unduly onerous for Info Package definitions not published= by IETF and goes beyond what we require for media feature tags. They need = to fit their zpecification structure. I believe that all we need to say is = that the registration requirements for IANA need to be readily identifiable= to IANA by including them in a single part of the document to which IANAs = attention is drawn at the time of the registration request. 32) Section 10.11 The Info Package specification SHOULD contain a description of the application procedures associated with the Info Package, or alternatively refer to application procedures defined elsewhere. This SHOULD is inconsistent with section 4.3 which contains: Info Package specifications MUST describe the application level information associated with the Info Package. =20 I believe the MUST is correct. regards Keith From christer.holmberg@ericsson.com Mon Oct 26 22:54:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87E728C0FA for ; Mon, 26 Oct 2009 22:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kK+CfbyTVaPC for ; Mon, 26 Oct 2009 22:54:50 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8DD933A69F4 for ; Mon, 26 Oct 2009 22:54:49 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-79-4ae68b354335 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7D.B6.24026.53B86EA4; Tue, 27 Oct 2009 06:55:02 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 06:55:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 06:55:01 +0100 Message-ID: In-Reply-To: <4AE6467B.3010206@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWoRJvOOWDOyENTtGCGKZAbi2B3gAKH0fA References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 27 Oct 2009 05:55:01.0779 (UTC) FILETIME=[06040630:01CA56CA] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:54:50 -0000 >>What if you have an INFO package that needs to convey two image/jpegs=20 >>one for display to the user's left eye and one for the other's right=20 >>eye? > >I love it!!! Great example. That is what I tried to cover with the following text that I suggested in another reply: "An I-P specification SHOULD always specifiy a C-D 'info-package' value to be used for each individual body part associated with that I-P, unless another value is required in order for the remote application to be able to process the body part information correctly." So, in this case the two image/jpeg body parts could have different C-D 'right-eye'/'left-eye' values. And, they would need to be inside a multipart with C-D 'info-package'. Regards, Christer From christer.holmberg@ericsson.com Mon Oct 26 23:01:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15DDF3A684D for ; Mon, 26 Oct 2009 23:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ5BoZLeU2AH for ; Mon, 26 Oct 2009 23:01:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5062E3A6830 for ; Mon, 26 Oct 2009 23:01:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-73-4ae68ce008ad Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9A.88.04191.0EC86EA4; Tue, 27 Oct 2009 07:02:09 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:02:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 07:02:07 +0100 Message-ID: In-Reply-To: <9E1F03AB-FE8A-481C-A0B2-7F14D8B1F3AD@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWnjcUgyw1lewxQ2+qqwtrk+KuEgAK+csA References: <4ADE168F.7060303@cisco.com> <4ADE227C.5020500@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B2BC4@DEMCHP99E35MSX.ww902.siemens.net> <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.c! o m> <9E1F03AB-FE8A-481C-A0B2-7F14D8B1F3AD@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 27 Oct 2009 06:02:08.0789 (UTC) FILETIME=[04889450:01CA56CB] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 06:01:58 -0000 Hi,=20 >>>>The encoding of the e-mail got a little messed up, so I may have missed something. >>Then, take the following example: >> >>An INFO request contains only a SINGLE body part (application/aaa), associated with the I-P. >=20 >We're with you so far. >=20 >> >>The I-P specification says that C-D 'foo' is used for 'application/aaa'. >=20 >Then the I-P specification is broken and we should spank the=20 >author, the reviewers, and everybody else who let it slip=20 >past. Since it is a singular body part, it is also the=20 >top-level body part, and MUST have a C-D of "info-package".=20 >Otherwise, we have no way of knowing of the body part is=20 >intended as the package payload, or is instead a parasitic payload. I totally agree with you. But, my point is that 'application/aaa' would have C-D 'info-package' also if it was placed inside a multipart with C-D 'info-package'. So, that is why I think we need to say that ANY I-P body part that may be inserted on the "top level" of the request message MUST be assigned C-D 'info-package'. If other C-D values are defined for an I-P body part (e.g. the right vs left eye example) they must be placed inside an 'info-package' multipart. Regards, Christer From dean.willis@softarmor.com Mon Oct 26 23:25:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5440C3A689B for ; Mon, 26 Oct 2009 23:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMYa9X7CIgJR for ; Mon, 26 Oct 2009 23:25:41 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D4A843A687D for ; Mon, 26 Oct 2009 23:25:40 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9R6PNaj010507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 01:25:24 -0500 Message-Id: <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 01:25:18 -0500 References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 06:25:42 -0000 On Oct 27, 2009, at 12:55 AM, Christer Holmberg wrote: > > "An I-P specification SHOULD always specifiy a C-D 'info-package' > value > to be used for each individual body part associated with that I-P, > unless another value is required in order for the remote application > to > be able to process the body part information correctly." The preceding does not parse for me in the way that you seem to be suggesting it should. Either the specification requires a C-D of "info-package" or it requires a different C-D to be used. Does the following mean the same thing to you? ------ Each Info-Package specification MUST specify the Content-Disposition value for each MIME body part in the payload defined by that Info- Package specification. Info-Package specifications using a singular (not multipart) payload body MUST use a Content-Disposition of "info- package" (as this allows the Info-Package payload to be differentiated from other payloads carried as body parts on the INFO message). Info- Package specifications that use multipart bodies in their payload SHOULD use a Content-Disposition value of "info-package" for each part (as this preserves the context of extracted body-parts as being part of an Info-Package payload). However, where the application requires differentiating parts of a multipart body payload using Content-Disposition, an Info-Package specification MAY use other Content-Disposition values for those payload body parts. These Content- Disposition values MUST be appropriate to the payload body part and application in question, and when considered in the context of the Content-Type applicable to that payload body part, MUST enable the application to differentiate between payload body parts so as to appropriately use those parts. ------- If that's what you meant, then I disagree. I hold that a C-D of "info- package" should only be used at the container level, and that if the container is multipart, that the default should be to have meaningful C-D values for each part. Once a payload part has been separated from its multipart container it isn't all that important for us to be able to tell by inspection that it was part of an Info-Package payload, but it might be very useful for us to know that the payload is supposed to be rendered to the user. -- Dean From christer.holmberg@ericsson.com Mon Oct 26 23:29:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165A428C0FA for ; Mon, 26 Oct 2009 23:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K08YYx9ibqxI for ; Mon, 26 Oct 2009 23:29:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 748DF3A687D for ; Mon, 26 Oct 2009 23:29:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-a3-4ae693480088 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4E.38.24026.84396EA4; Tue, 27 Oct 2009 07:29:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 07:29:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 07:28:59 +0100 Message-ID: In-Reply-To: <4AE62FA6.5060800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: VS: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWk5HjqAzCm+BpSK2ssKZ5v4gCKQAN6ECA References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> <4AE604 63.6010109@cisco.com> <4AE62 FA6.5060800@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 27 Oct 2009 06:29:00.0675 (UTC) FILETIME=[C54ADD30:01CA56CE] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 06:29:17 -0000 Hi,=20 =20 >>In my opinion C-D 'info-package' ALWAYS means "this body part is associated with the Info Package". >=20 >What if it isn't in an INFO message? Protocol error, outside the scope, undefined... >All the C-D values have some contextual definition. For=20 >instance "render" clearly means something different in a sip=20 >message than it does in an email message. (For rather stupid=20 >reasons we are using "render" for the C-D of the multipart that holds otherwise unrelated=20 >parts of a sip message.) > >For example, I might sometime decide to put part/all of an=20 >INFO message into a sipfrag, and make that a body part on=20 >some other message, perhaps MESSAGE or another INFO. In that case the INFO message inside the sipfrag is part of the sipfrag body part payload. The draft doesn't specify what payloads contain - the individual I-P specifications will do that. And, in the case of MESSAGE you are not even using the I-P mechanism when sending the MESSAGE request (eventhough the included sipfrag payload of course LATER may be used for an INFO request). >The sipfrag may or may not have the message header that denotes=20 >it as an INFO message. The key is that it really doesn't=20 >matter. When processing the MESSAGE, the C-D in the sipfrag=20 >is not in a context where it is relevant to processing of the=20 >MESSAGE. If the body were reconstituted into a full INFO=20 >message, and then that message were decoded, then the C-D=20 >would be significant. I totally agree.=20 Payload is payload, and whatever is inside the payload is outside the scope of the info package base specification. =20 >Once it has been removed from the context where we have defined what it means, its meaning has to be taken from context. Whoever uses it needs to take care of that, but I don't think it has anything to do with the I-P mechanism as such. =20 >>>>We do need to say that if an I-P uses non-'info-package' C-D values for body parts they MUST always be located inside=20 >>>>a multipart with C-D 'info-package'. I don't think we need to say that. IMO it is clearer to=20 >>>>*not* say it. >>>=20 >>We DO need to prevent users from putting those on the "top level". > >We need to do our part here to define what C-D of info-package means at the top level and within a top level=20 >multipart of C-D "render". I don't agree to the C-D "render" part. The top level C-D is always 'info-package'. Again, it is totally ok to send another SIP message, which contains a sipfrag with an INFO message and C-D 'render'. But, that SIP message has nothing to do with the I-P mechanism as such. >>"In the message body of the INFO request, the main body part associated with the I-P MUST use a C-D 'info-package'=20 >>value, in order to distinguish the body part associated with the I-P from possible other body parts in the request." >=20 >I'm ok with the above. >=20 >>If there is a need to include multiple body parts associated with the I-P, or to include a body part for which=20 >>the I-P specification defines a non-'info-package' C-D value, such body parts MUST be collected inside a multipart body=20 >>part with a C-D 'info-package' value. The I-P specification MUST describe what type multipart is to be used in such cases. >=20 >None of the above sentence needs to be normative. The prior statement is sufficiently normative. This statement could be=20 >reworded in to something non-normative. For example: >=20 >"NOTE: If an I-P specification has need to allow inclusion of multiple body parts, and/or body part(s) containing a C-D=20 >other than info-package, it can specify that the body part associated with I-P can be a multipart type." I can probably live with that. =20 >>An I-P specification SHOULD always specifiy a C-D 'info-package' value to be used for each individual body part=20 >>associated with that I-P, unless another value is required in order for the remote application to be able to process the=20 >>body part information correctly." >=20 >I don't find the above sentence to be at all helpful. I think that it is VERY useful :) I really think that 'info-package' should be the default C-D value, unless there is a need to use something else (right eye vs left eye etc). Maybe it's clear to those of use being part of this discussion, but it needs to be clear to other readers also. Regards, Christer From john.elwell@siemens-enterprise.com Tue Oct 27 00:30:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B518F3A67E5 for ; Tue, 27 Oct 2009 00:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zr63Sx7hSLq for ; Tue, 27 Oct 2009 00:30:02 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 33BC43A6920 for ; Tue, 27 Oct 2009 00:30:02 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9R7Tj3d001543; Tue, 27 Oct 2009 08:29:45 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9R7Ti3L015072; Tue, 27 Oct 2009 08:29:44 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Tue, 27 Oct 2009 08:29:43 +0100 From: "Elwell, John" To: Christer Holmberg , Paul Kyzivat Date: Tue, 27 Oct 2009 08:29:41 +0100 Thread-Topic: VS: VS: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? Thread-Index: AcpWk5HjqAzCm+BpSK2ssKZ5v4gCKQAN6ECAAALebpA= Message-ID: <7402509E63C5A145A6095D46C179A5B7148B343B@DEMCHP99E35MSX.ww902.siemens.net> References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE 5D136.5080804@cisco.com> <4AE604 63.6010109@cisco.com> <4AE62 FA6.5060800@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , Adam Roach , SIPCORE , Gonzalo, Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 07:30:04 -0000 =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: 27 October 2009 06:29 > To: Paul Kyzivat > Cc: Adam Roach; Elwell, John; SIPCORE; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: RE: VS: VS: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > non-I-P body parts in INFO? >=20 >=20 > Hi,=20 > =20 > >>In my opinion C-D 'info-package' ALWAYS means "this body part is > associated with the Info Package". > >=20 > >What if it isn't in an INFO message? >=20 > Protocol error, outside the scope, undefined... >=20 > >All the C-D values have some contextual definition. For=20 > >instance "render" clearly means something different in a sip=20 > >message than it does in an email message. (For rather stupid=20 > >reasons we are using "render" for the C-D of the multipart that holds > otherwise unrelated=20 > >parts of a sip message.) > > > >For example, I might sometime decide to put part/all of an=20 > >INFO message into a sipfrag, and make that a body part on=20 > >some other message, perhaps MESSAGE or another INFO. >=20 > In that case the INFO message inside the sipfrag is part of=20 > the sipfrag > body part payload. The draft doesn't specify what payloads=20 > contain - the > individual I-P specifications will do that. >=20 > And, in the case of MESSAGE you are not even using the I-P mechanism > when sending the MESSAGE request (eventhough the included sipfrag > payload of course LATER may be used for an INFO request). >=20 >=20 > >The sipfrag may or may not have the message header that denotes=20 > >it as an INFO message. The key is that it really doesn't=20 > >matter. When processing the MESSAGE, the C-D in the sipfrag=20 > >is not in a context where it is relevant to processing of the=20 > >MESSAGE. If the body were reconstituted into a full INFO=20 > >message, and then that message were decoded, then the C-D=20 > >would be significant. >=20 > I totally agree.=20 >=20 > Payload is payload, and whatever is inside the payload is outside the > scope of the info package base specification. > =20 > >Once it has been removed from the context where we have=20 > defined what it > means, its meaning has to be taken from context. >=20 > Whoever uses it needs to take care of that, but I don't think it has > anything to do with the I-P mechanism as such. > =20 > >>>>We do need to say that if an I-P uses non-'info-package'=20 > C-D values > for body parts they MUST always be located inside=20 > >>>>a multipart with C-D 'info-package'. I don't think we need to say > that. IMO it is clearer to=20 > >>>>*not* say it. > >>>=20 > >>We DO need to prevent users from putting those on the "top level". > > > >We need to do our part here to define what C-D of=20 > info-package means at > the top level and within a top level=20 > >multipart of C-D "render". >=20 > I don't agree to the C-D "render" part. The top level C-D is always > 'info-package'. [JRE] I think Christer and Paul are talking about different things for "top= level". The very top level can be C-D render, and at a lower level, there = can be a top level info-package body part with C-D Info-Package. >=20 > Again, it is totally ok to send another SIP message, which contains a > sipfrag with an INFO message and C-D 'render'. But, that SIP=20 > message has > nothing to do with the I-P mechanism as such. >=20 >=20 > >>"In the message body of the INFO request, the main body part > associated with the I-P MUST use a C-D 'info-package'=20 > >>value, in order to distinguish the body part associated with the I-P > from possible other body parts in the request." > >=20 > >I'm ok with the above. > >=20 > >>If there is a need to include multiple body parts=20 > associated with the > I-P, or to include a body part for which=20 > >>the I-P specification defines a non-'info-package' C-D value, such > body parts MUST be collected inside a multipart body=20 > >>part with a C-D 'info-package' value. The I-P specification MUST > describe what type multipart is to be used in such cases. > >=20 > >None of the above sentence needs to be normative. The prior statement > is sufficiently normative. This statement could be=20 > >reworded in to something non-normative. For example: > >=20 > >"NOTE: If an I-P specification has need to allow inclusion=20 > of multiple > body parts, and/or body part(s) containing a C-D=20 > >other than info-package, it can specify that the body part associated > with I-P can be a multipart type." >=20 > I can probably live with that. > =20 > >>An I-P specification SHOULD always specifiy a C-D=20 > 'info-package' value > to be used for each individual body part=20 > >>associated with that I-P, unless another value is required in order > for the remote application to be able to process the=20 > >>body part information correctly." > >=20 > >I don't find the above sentence to be at all helpful. >=20 > I think that it is VERY useful :) I really think that 'info-package' > should be the default C-D value, unless there is a need to=20 > use something > else (right eye vs left eye etc). >=20 > Maybe it's clear to those of use being part of this discussion, but it > needs to be clear to other readers also. [JRE] I agree with Paul that the sentence is not helpful. I think less is m= ore in this case. John >=20 > Regards, >=20 > Christer >=20 > = From christer.holmberg@ericsson.com Tue Oct 27 01:26:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45803A6919 for ; Tue, 27 Oct 2009 01:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2z1m0QLOZiV for ; Tue, 27 Oct 2009 01:26:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 48E723A68C8 for ; Tue, 27 Oct 2009 01:26:32 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-c2-4ae6aec449eb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 85.84.04191.4CEA6EA4; Tue, 27 Oct 2009 09:26:45 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:26:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 09:26:27 +0100 Message-ID: In-Reply-To: <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWzketcygvmpgKTtmw8JdZ60ZIXAAAIxlg References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 27 Oct 2009 08:26:29.0378 (UTC) FILETIME=[2EA59620:01CA56DF] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:26:33 -0000 Hi,=20 >>"An I-P specification SHOULD always specifiy a C-D 'info-package' value >>to be used for each individual body part associated with that I-P,=20 >>unless another value is required in order for the remote application=20 >>to be able to process the body part information correctly." >=20 >The preceding does not parse for me in the way that you seem to be suggesting it should. >=20 >Either the specification requires a C-D of "info-package" or it requires a different C-D to be used. That is exactly what I am trying to say. >Does the following mean the same thing to you? >=20 >------ >Each Info-Package specification MUST specify the=20 >Content-Disposition value for each MIME body part in the=20 >payload defined by that Info- Package specification.=20 >Info-Package specifications using a singular (not multipart)=20 >payload body MUST use a Content-Disposition of "info-=20 >package" (as this allows the Info-Package payload to be=20 >differentiated from other payloads carried as body parts on=20 >the INFO message). Info- Package specifications that use=20 >multipart bodies in their payload SHOULD use a=20 >Content-Disposition value of "info-package" for each part=20 >(as this preserves the context of extracted body-parts as=20 >being part of an Info-Package payload). However, where the=20 >application requires differentiating parts of a multipart=20 >body payload using Content-Disposition, an Info-Package=20 >specification MAY use other Content-Disposition values for=20 >those payload body parts. These Content- Disposition values=20 >MUST be appropriate to the payload body part and application=20 >in question, and when considered in the context of the=20 >Content-Type applicable to that payload body part, MUST=20 >enable the application to differentiate between payload body=20 >parts so as to appropriately use those parts. >------- If that text is from the draft, please note that when I submitted the latest version I indicated that that part is still under discussion. So, we have not been discussing that specific text. We have been discussing how things should work, and then I will update the text based on the outcome. >If that's what you meant, then I disagree. I hold that a C-D=20 >of "info- package" should only be used at the container=20 >level, and that if the container is multipart, that the=20 >default should be to have meaningful C-D values for each=20 >part. There may be cases where a part is sometimes inside a container (e.g. if the INFO request also contains other parts), and sometimes the part is outside a container (e.g. If it is the only body part in the INFO request), but the part should have the same C-D value in either case. And, in cases where the part can be outside a container that value must be 'info-package'. >Once a payload part has been separated from its multipart container it isn't all that important for us to be=20 >able to tell by inspection that it was part of an Info-Package payload, but it might be very useful for us to=20 >know that the payload is supposed to be rendered to the user. The whole idea of INFO is to transport application data, so the application is the only one who needs to know what to do with the data. If that requires some other C-D value, then fine, but the SIP protocol does not need to know what will happen with the information. Regards, Christer From christer.holmberg@ericsson.com Tue Oct 27 01:29:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136C83A68C8 for ; Tue, 27 Oct 2009 01:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF4IDIdATpw8 for ; Tue, 27 Oct 2009 01:29:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id DF9C93A6876 for ; Tue, 27 Oct 2009 01:29:25 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-37-4ae6af720750 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 60.CB.31706.27FA6EA4; Tue, 27 Oct 2009 09:29:38 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:29:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 09:29:37 +0100 Message-ID: In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B343B@DEMCHP99E35MSX.ww902.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VS: VS: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpWk5HjqAzCm+BpSK2ssKZ5v4gCKQAN6ECAAALebpAAAicf0A== References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <4AE5D136.5080804@cisco.com> <4AE604 63.6010109@cisco.com> <4AE62 FA6.5060800 @cisco.com> <7402509E63C5A145A6095D46C179A5B7148B343B@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 27 Oct 2009 08:29:38.0283 (UTC) FILETIME=[9F3E33B0:01CA56DF] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 08:29:27 -0000 Hi, =20 >>>>An I-P specification SHOULD always specifiy a C-D >>>>'info-package' value to be used for each individual body part >>>>associated with that I-P, unless another value is required in order >>>>for the remote application to be able to process the >>>>body part information correctly." >>>=20 >>>I don't find the above sentence to be at all helpful. >>=20 >>I think that it is VERY useful :) I really think that 'info-package' >>should be the default C-D value, unless there is a need to use=20 >>something else (right eye vs left eye etc). >>=20 >>Maybe it's clear to those of use being part of this discussion, but it >>needs to be clear to other readers also. >[JRE] I agree with Paul that the sentence is not helpful. I think less is more in this case. Let's decide upon that once we have the whole text, ok? Regards, Christer From miguel.a.garcia@ericsson.com Tue Oct 27 02:05:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881F43A68C8; Tue, 27 Oct 2009 02:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xMKR6UVHhLP; Tue, 27 Oct 2009 02:05:55 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id ECD363A6929; Tue, 27 Oct 2009 02:05:54 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-c8-4ae6b7ffbac1 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 45.1F.31706.FF7B6EA4; Tue, 27 Oct 2009 10:06:07 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:06:07 +0100 Received: from [159.107.25.11] ([159.107.25.11]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:06:07 +0100 Message-ID: <4AE6B7FE.4090505@ericsson.com> Date: Tue, 27 Oct 2009 10:06:06 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "James M. Polk" References: <4AE555C3.9000109@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 09:06:07.0163 (UTC) FILETIME=[B7EAC8B0:01CA56E4] X-Brightmail-Tracker: AAAAAA== Cc: geopriv@ietf.org, sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 09:05:56 -0000 Hi James, some inline comments. On 26/10/2009 18:41, James M. Polk wrote: >>> Currently, and pretty much since whatever version of >>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt >>> >>> has existed in whatever WG it happened to reside in at the time, >>> Location Conveyance using SIP has included the use of PUBLISH to convey >>> location as a message body, or as a location URI since about, or before >>> 2005. I fail to see or read what you want in your doc that cannot be >>> covered in SIP Location Conveyance. >> >> I understand that the Geolocation header has quite a few similarities >> with what is proposed in the draft. I don't think the Geolocation >> header has means to indicate the presence server "you should >> de-reference the location and insert it in a presence document to be >> offered to watchers". > > hmmm... it's this a policy choice between the presentity and the > presence server (i.e., what to have the PS pass on as a reference, and > what the PS dereferences to pass on only as a value)? How can't that be > a policy between the PA and PS (including which references to leave as > references, and which are dereferenced and sent by the PS as a value)? At the moment the draft is not ambitious to have the PS passing the reference to the watcher. This might be something to look at it a bit later, but so far, the only ambition is that the PS de-references the location and adds it to the PIDF that is offered to watchers. > > In that sense, this mechanism (policy notification of which URIs it > receives from the PA need to be dereferenced) ought to be general, and > not limited to location. I can see one argument being "the PA should > include with the URI reference whether or not to do this deference", but > that can lead to mistakes - as then each URI the PS receives has to look > for the indication -- which is always an extension to how the URI is > sent to the PS in the first place. That's clumbersome IMO. > > Therefore, IMO, this shouldn't be > > - a new SIP header > - with or without a new option-tag > - an indication to each way a PS receives a URI > > but, rather, more general. > > The issue that has to be watched out for is when 2 or more URIs get sent > to the PS and only a subset needs this dereference treatment. I think I concur with you, except the level of ambition, as I said before. > > >>> I cannot figure out how you claim usage of the Geolocation is too >>> limiting. >> >> I have several criticism to the use of a SIP header to convey this >> information. Indirect location is just a particular case of a general >> solution, which is, a presentity wants to publish some information by >> reference not by value. Location is the more straight forward example, >> but we should try to find a general solution. > > I'm not really understanding this example. If a PA wants to have a > watcher get a URI, then the PA sends a URI to the PS. If the PA wants to > have the watcher get a value, the PA sends a value to the PS *or* the PA > sends a URI to the PS and the PS dereferences the URI to be able to send > a value to a watcher. > > To me this is a function the PS knows to do when it receives certain > URIs (i.e., reference types). Receiving a Location URI could be one such > situation. I agree with your analysis. > > I wonder if there is another issue -- shouldn't the PS determine when to > send the reference vs. a value mostly based on who is asking for the > information? This is discussed before, we are building from the ground, and the first step is to make the PS to dereference the location URI. Passing the URI is something for which don't have requirements at the moment, so will analyze whether is worth doing it once we have solved our main problem. > > >> So, if we agree to pursue a general solution for publication of >> presence information by reference, then I find difficult to think of a >> solution based on a new or existing SIP header. Instead, we should be >> looking at the XML body, either to an extension to the existing one or >> a new XML body that. > > You're proposing have this indication solely in a message body? > > This appears to me to be overkill just to get a flag from a PA to a PS. > > I could be wrong though... Well, at the moment all solution spaces are open. If we want to make something general enough, it cannot be done at the SIP level, so we should be looking at ways to do it at the XML level. Using and XML diff document (XML Patch operations) might be a way to move forward. We are currently investigating this track. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@cisco.com Tue Oct 27 05:30:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A7A3A68FE for ; Tue, 27 Oct 2009 05:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a76MxSsSKrsb for ; Tue, 27 Oct 2009 05:30:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9047C3A6782 for ; Tue, 27 Oct 2009 05:30:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB+F5kpAZnwM/2dsb2JhbADANJg5hD8E X-IronPort-AV: E=Sophos;i="4.44,633,1249257600"; d="scan'208";a="65079317" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Oct 2009 12:31:03 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RCV3IN012387; Tue, 27 Oct 2009 12:31:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 08:31:03 -0400 Received: from [10.86.241.14] ([10.86.241.14]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 08:31:02 -0400 Message-ID: <4AE6E7FF.4050005@cisco.com> Date: Tue, 27 Oct 2009 08:30:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 12:31:02.0841 (UTC) FILETIME=[58B65A90:01CA5701] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 12:30:50 -0000 Christer Holmberg wrote: >>> What if you have an INFO package that needs to convey two image/jpegs >>> one for display to the user's left eye and one for the other's right >>> eye? >> I love it!!! Great example. > > That is what I tried to cover with the following text that I suggested > in another reply: > > "An I-P specification SHOULD always specifiy a C-D 'info-package' value > to be used for each individual body part associated with that I-P, > unless another value is required in order for the remote application to > be able to process the body part information correctly." > > So, in this case the two image/jpeg body parts could have different C-D > 'right-eye'/'left-eye' values. And, they would need to be inside a > multipart with C-D 'info-package'. I think you are getting unnecessarily fixated on specifying *how* an individual I-P specification should employ multipart to achieve its objectives. Whatever you say will be redundant to other standards, and runs the risk of being inconsistent with them. IMO this document should only levy requirements on the *one* body part associated with the I-P. Going beyond that is simply preaching to the designer of the I-P. In Dean's example there are undoubted many ways to achieve the desired end. E.g., I'm sure there is some form of multipart where the recipient can associate a role with the *position* of the parts within the multipart. (Adam can fill in the details.) Thanks, Paul From christer.holmberg@ericsson.com Tue Oct 27 05:50:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68F63A6893 for ; Tue, 27 Oct 2009 05:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfxa0RuaII80 for ; Tue, 27 Oct 2009 05:50:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 953D23A67DF for ; Tue, 27 Oct 2009 05:50:19 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-60-4ae6ec8cea1d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 11.9F.04191.C8CE6EA4; Tue, 27 Oct 2009 13:50:20 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 13:49:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 13:49:26 +0100 Message-ID: In-Reply-To: <4AE6E7FF.4050005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpXAVxGYZ5racc+R42iba6KGc5yrAAAknNQ References: <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <4AE6E7FF.4050005@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 27 Oct 2009 12:49:28.0979 (UTC) FILETIME=[EC059E30:01CA5703] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 12:50:20 -0000 Hi,=20 >>>>What if you have an INFO package that needs to convey two=20 >>>>image/jpegs one for display to the user's left eye and one for the=20 >>>>other's right eye? >>>I love it!!! Great example. >>=20 >>That is what I tried to cover with the following text that=20 >>I suggested in another reply: >>=20 >>"An I-P specification SHOULD always specifiy a C-D 'info-package'=20 >>value to be used for each individual body part associated with that=20 >>I-P, unless another value is required in order for the remote=20 >>application to be able to process the body part information=20 >>correctly." >>=20 >>So, in this case the two image/jpeg body parts could have different=20 >>C-D 'right-eye'/'left-eye' values. And, they would need to=20 >>be inside a multipart with C-D 'info-package'. >=20 >I think you are getting unnecessarily fixated on specifying=20 >*how* an individual I-P specification should employ multipart=20 >to achieve its objectives. Whatever you say will be redundant=20 >to other standards, and runs the risk of being inconsistent with them. I only say that the body parts must be inside a multipart, which I thought we had agreed upon. Regards, Christer From pkyzivat@cisco.com Tue Oct 27 07:04:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240D028C20F for ; Tue, 27 Oct 2009 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inOApGHkbalC for ; Tue, 27 Oct 2009 07:04:31 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 327C028C1F2 for ; Tue, 27 Oct 2009 07:04:31 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIOa5kqrR7Ht/2dsb2JhbADBUJg6hD8E X-IronPort-AV: E=Sophos;i="4.44,633,1249257600"; d="scan'208";a="418902128" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2009 14:04:39 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9RE4dL1017390; Tue, 27 Oct 2009 14:04:39 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:04:38 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 10:04:38 -0400 Message-ID: <4AE6FDFA.7060804@cisco.com> Date: Tue, 27 Oct 2009 10:04:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <4AE6E7FF.4050005@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 14:04:38.0367 (UTC) FILETIME=[6BD39EF0:01CA570E] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:04:32 -0000 Christer Holmberg wrote: > Hi, > >>>>> What if you have an INFO package that needs to convey two >>>>> image/jpegs one for display to the user's left eye and one for the >>>>> other's right eye? >>>> I love it!!! Great example. >>> That is what I tried to cover with the following text that >>> I suggested in another reply: >>> >>> "An I-P specification SHOULD always specifiy a C-D 'info-package' >>> value to be used for each individual body part associated with that >>> I-P, unless another value is required in order for the remote >>> application to be able to process the body part information >>> correctly." >>> >>> So, in this case the two image/jpeg body parts could have different >>> C-D 'right-eye'/'left-eye' values. And, they would need to >>> be inside a multipart with C-D 'info-package'. >> I think you are getting unnecessarily fixated on specifying >> *how* an individual I-P specification should employ multipart >> to achieve its objectives. Whatever you say will be redundant >> to other standards, and runs the risk of being inconsistent with them. > > I only say that the body parts must be inside a multipart, which I > thought we had agreed upon. The thing is, there is nothing normative about that. There is no need for this draft to talk about multiple parts within the I-P at all. The attempt to talk about it is resulting in confusion. The confusion can be resolved with *more* words or *less* words. I'm suggesting that *less* words would be better here. Thanks, Paul From dean.willis@softarmor.com Tue Oct 27 07:31:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E4E3A68AB for ; Tue, 27 Oct 2009 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtOkAO4bs0rw for ; Tue, 27 Oct 2009 07:31:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A29AD3A6783 for ; Tue, 27 Oct 2009 07:31:05 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9REUjcr015507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 09:30:46 -0500 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 09:30:37 -0500 References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:31:07 -0000 On Oct 27, 2009, at 3:26 AM, Christer Holmberg wrote: >> > > The whole idea of INFO is to transport application data, so the > application is the only one who needs to know what to do with the > data. > If that requires some other C-D value, then fine, but the SIP protocol > does not need to know what will happen with the information. By this logic, the SIP protocol should therefore not say anything about the C-D value except when it needs to. And in this case, we have shown that SIP needs to say something only about the C-D value of the "container", either a singular body part or a multipart whose sub- parts are the payload package of the INFO request. -- Dean From christer.holmberg@ericsson.com Tue Oct 27 10:10:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9CA3A690D for ; Tue, 27 Oct 2009 10:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E14btmHtyP+N for ; Tue, 27 Oct 2009 10:10:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 6AF3E3A67E2 for ; Tue, 27 Oct 2009 10:10:01 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-f0-4ae72976a47f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EC.70.24026.67927EA4; Tue, 27 Oct 2009 18:10:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 18:10:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 18:10:13 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpXEhm6D+FFgs+/QUm1Slr3C+8oqAAFeB1Q References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 27 Oct 2009 17:10:14.0472 (UTC) FILETIME=[59766480:01CA5728] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:10:02 -0000 Hi,=20 >>The whole idea of INFO is to transport application data, so the=20 >>application is the only one who needs to know what to do with the=20 >>data. >>If that requires some other C-D value, then fine, but the SIP protocol >>does not need to know what will happen with the information. > >By this logic, the SIP protocol should therefore not say anything about the C-D value except when it needs to. And in this case, we have shown that SIP needs to say something only about the C-D value of=20 >the "container", either a singular body part or a multipart whose sub- parts are the payload package of the INFO request. Yes. But, I still think it is good to point out that if a body part can be used as a singular body part, the C-D must be 'info-package'. If a body part is ALWAYS inside a mulipart container the C-D value can be whatever. Regards, Christer From christer.holmberg@ericsson.com Tue Oct 27 10:20:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289903A6820 for ; Tue, 27 Oct 2009 10:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYCKAYRGSlRl for ; Tue, 27 Oct 2009 10:20:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E0DC23A6A53 for ; Tue, 27 Oct 2009 10:20:21 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-2a-4ae72be3a892 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C1.E1.04191.3EB27EA4; Tue, 27 Oct 2009 18:20:35 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 18:19:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 18:19:30 +0100 Message-ID: In-Reply-To: <4AE6FDFA.7060804@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpXDnZgJskCLPK5ShmBvlstHdl45AAGgkNw References: <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <4AE6E7FF.4050005@cisco.com> <4AE6FDFA.7060804@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 27 Oct 2009 17:19:31.0259 (UTC) FILETIME=[A55558B0:01CA5729] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, Adam Roach , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:20:23 -0000 Hi,=20 >>>>>> What if you have an INFO package that needs to convey two=20 >>>>>> image/jpegs one for display to the user's left eye and one for the=20 >>>>>> other's right eye? >>>>> I love it!!! Great example. >>>> That is what I tried to cover with the following text that I=20 >>>> suggested in another reply: >>>> >>>> "An I-P specification SHOULD always specifiy a C-D 'info-package'=20 >>>> value to be used for each individual body part associated with that >>>> I-P, unless another value is required in order for the remote=20 >>>> application to be able to process the body part information=20 >>>> correctly." >>>> >>>> So, in this case the two image/jpeg body parts could have different >>>> C-D 'right-eye'/'left-eye' values. And, they would need to be inside=20 >>>> a multipart with C-D 'info-package'. >>> I think you are getting unnecessarily fixated on specifying >>> *how* an individual I-P specification should employ multipart to=20 >>> achieve its objectives. Whatever you say will be redundant to other=20 >>> standards, and runs the risk of being inconsistent with them. >>=20 >> I only say that the body parts must be inside a multipart, which I=20 >> thought we had agreed upon. > >The thing is, there is nothing normative about that. There is no need for this draft to talk about multiple parts within the I-P at all. That means that users can put body parts associated with the I-P wherever they want in the message body structure. If we want to allow that, fine. >The attempt to talk about it is resulting in confusion. The confusion can be resolved with *more* words or *less* words. I'm suggesting that >*less* words would be better here. I agree that less is often better than more. But, I am not sure that the wording is the main issue at the moment, because it is still unclear to me whether we agree on the the general concept. But, could You suggest some wording, which covers everything that needs to be covered? Regards, Christer From drage@alcatel-lucent.com Tue Oct 27 10:37:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0FE43A69E3 for ; Tue, 27 Oct 2009 10:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJzl0afAbfqc for ; Tue, 27 Oct 2009 10:37:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 060873A67F3 for ; Tue, 27 Oct 2009 10:37:24 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9RHbbmB013024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Oct 2009 18:37:37 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 27 Oct 2009 18:37:37 +0100 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Tue, 27 Oct 2009 18:37:36 +0100 Thread-Topic: Comments on draft-ietf-sipcore-info-events-02 Thread-Index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3wAZ5oHQ Message-ID: References: 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:37:27 -0000 Some new comments and revision of one previous comment: 33) Section 1: Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages. Replace "invite" with upper case as I believe this is the RFC 3261 conventi= on. 34) Section 3.2: The indication of Info Packages can take place during the dialog establishment, and during a target refresh. This includes INVITE, UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx only). Note that the UAC is not required to indicate its set of Info Packages in the initial INVITE request. This I guess supports the text in the table in section 6.1: Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR ------------------------------------------------------------------------ Info-Package R - - - - - - - m* - - - - - Recv-Info R o - - o o o o - - o - - - Recv-Info 2xx o - - o o - o - - o - - - Recv-Info 1xx o - - o o - o - - o - - - Recv-Info r o - - - o - o - - o - - - but this leaves a lot of open questions in my mind as to the support of the= Recv-Info header in various methods, as follows: - what is the purpose in the REGISTER request, and does this have any= impact on a future dialog usage? Does it indicate willingness to support i= n all future INVITE dialogs. In the absence of any further text in the docu= ment I would rather take it out. If there really is some future usage, then= we need more text in the document that just the appearance in the table. - can't REFER or SUBSCRIBE be used as a target refresh request within= an INVITE dialog usage. I don't particularly want to add a usage, but I th= ink this points to a lack of precision of the section 3.2 text, which in so= me ways I would like to contain RFC 2119 language as well. I think personal= ly I would prefer to limit the Recv-Info header usage to only the INVITE tr= ansaction and the UPDATE transaction and be very precise on that. I see no = real use for its appearance in PRACK, ACK. - section 3.2 needs to deal with the OPTIONS usage, which I think is = valid. - if we have a 4xx - 6xx response to a reINVITE, wh y is the su= pport different that that for an UPDATE? 35) Section 5.1: For the supported header field tables I see no listing for the following he= aders: - Is a 415 response to INFO allowed containing the Accept header fiel= d? - Allow-Events (which I think is like Allow and appears in all reques= ts and 2xx responses). - Referred-By header (again which I thought could appear in all metho= ds). - Request-Disposition (again all methods). - Geolocation-Error (all responses). - Resource-Priority (allowed in all requests and responses, and neede= d if priority is applied on a per transaction basis rather than set for the= entire dialog, which is one of the options in RFC 4412). - Accept-Resource-Priority in 2xx and 417 responses. I would also comment on the following for which entries appear. - Organization. Given the semantics of this, it would be the same as = appears in the original INVITE that created the dialog. The use case mentio= ned in RFC 3261 does not apply to subsequent requests within a dialog. More= over I think it is harmful if people think they can use this header to carr= y information that really belongs in the application. Therefore I would exc= lude it. - Allow. RFC3261 allows this in all responses according to my interpr= etation, rather than specifically 2xx and 405 (which I agree do get special= mention). The entry for a 405 response should be m as it is mandatory, but= o for all other responses. - Privacy. Listed for requests only. I have an understanding that thi= s is also allowed in responses. - Reason. Listed for responses only. Currently it is allowed in reque= sts (BYE and CANCEL in particular) and not responses. There are proposals t= o extend it to responses but they have not been adopted yet. I suspect the = use cases for this header field in INFO are pretty much non-existent in any= case. - Can I check that the Accept header field is not needed for 2xx resp= onses. RFC 3261 provides for its usage in certain methods, but I am not sur= e about whether there is a use case in INFO. - Proxy-Authenticate. I though was also allowed for a 401 response as= well as a 407 response. - Does the Retry-After header also apply to 413 responses and 500 res= ponses, or are these responses not valid for INFO. Additional input on the following comment: > 13) Section 4.4: > > If a UA receives an INFO request associated with an Info > Package that > the UA has not indicated willingness to receive, the UA MUST send a > 469 Bad INFO Package response Section 11.6. In the terminology of > Multiple Dialog Usages [RFC5057], this represents a > Transaction Only > failure. > > I assume that "(see Section 11.6)" or something similar is > meant in the end of the first sentence. > > I believe we also need to define whether the response code > applies to the transaction or the dialog. It obviously has to > be the transaction. > I do note the following text in 7.3 7.3. Dialog Fate Sharing As described in [RFC5057], an INFO request is always part of an INVITE dialog usage. One needs to consider the fate of the dialog usage of an INFO request is rejected. In some cases it may be acceptable that the whole dialog usage is terminated, while in other cases is is desirable to maintain the dialog usage. However as we have a specific new response code that represents a failure o= f the INFO method extension rather than any specific package, I believe the= actions for 469 in respect of the dialog usage should be defined in this d= ocument. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, October 27, 2009 2:35 AM > To: sipcore@ietf.org > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > Various miscellaneous comments. I have not yet trawled > through all the other comments and discussion to find if > these have already been made elsewhere. I suspect I will find > some other comments at a later time. > > 1) General. Please write responses in the format "200 (OK) > response" rather than "200 OK response". > > 2) General. Can we fix on the term of either "Info Package > definition" or "Info Package specification" and use it > consistently (in full) throughout where we mean that term. > > 3) Section 3.2 > > A UA which supports the Info Package mechanism MUST indicate, using > the Revc-Info header field, the set of Info Packages for > which it is > willing to receive an INFO request. > ^^^ > > Insert "an" as indicated. > > 4) Section 3.2: > > If a UA is not willing to receive INFO requests for any > Info Packages, during > ^^^^^^^^ > dialog establishment or later during the INVITE dialog > usage, the UA > ^^^^^^^ > MUST indicate this by including a Recv-Info header field > with a 'nil' > value. > > Insert "receive" as indicated. Replace "invite" with upper > case as I believe this is the RFC 3261 convention. > > 5) Section 3.2 indicates: > > A UA MUST NOT send an INFO request associated with an Info Package > until it has received an indication that the remote UA is > willing to > receive INFO requests for that Info Package, and a dialog has been > established with the remote UA. > > and section 4.2 indicates: > > For a specific dialog, a UA > MUST NOT send INFO requests associated with Info Packages that the > remote UA has not indicated that it is willing to receive. > > Are these not the same requirement. We need to eliminate one. > > 6) Section 3.2 indicates: > > Likewise, even if a UA uses the Recv-Info header > field to indicate that it supports the Info Package mechanism, in > addition the UA MUST still also explicitly indicate support of the > INFO method using the Allow header field. > > I do not believe this should be a MUST, because it is surely > already a MUST in RFC 3261 - all we need to do is write an > informative sentence that in accordance with RFC 3261 the > Allow header also indicates INFO requests. > > 7) Section 3.3: > > 3.3. Package Versioning > > The Info Package mechanism does not support package versioning. > Specific Info Package payloads MAY contain version > information, which > is handled by the applications associated with the Info > Package, but > that is outside the scope of the Info Package mechanism. > > NOTE: Even if an Info Package name contains version numbering (e.g. > foo_v2), the Info Package mechanism does not distinguish a version > number from the rest of the Info Package name. > > As this is all part of the Info Package name, and needs to > form part of the Info Package specification if used, I think > all the text here should be moved to section 10.3, and this > section header deleted. > > 8) Section 4.3 indicates: > > Info Package specifications MUST describe the application level > information associated with the Info Package. Each body part MUST > have a MIME type value, and the syntax and content of the > body part, > defined. > > Each body part, when associated with an Info Package, MUST have a > Content-Disposition header field with an 'Info-Package' value > assigned, in order to be able distinguish body parts > associated with > the Info Package from other body parts. > > Surely this is something where the MUST can only be met by > the designer of the package, and therefore it belongs in section 10. > > 9) Section 4.3: > > NOTE: Some SIP functions that are orthogonal to INFO may > insert body > parts unrelated to the Info Package. > > Change "may" to "can". > > 10) Section 4.3: > > However, when a body part in the INFO message is associated with an > Info Package, it MUST always have a Content-Disposition > header field > with an 'Info-Package' value assigned. > > Is this not just a repeat of the requirement earlier in the > section (1 paragraph before the note). > > 11) Section 4.3: > > This document does not define Info Package specific rules > on how body > parts associated with Info Packages are to be inserted > into multipart > body parts, and what type of multiparts are used. If an > Info Package > requires special rules regarding the usage of multipart body parts, > the specification for that Info Package MUST specify such rules. > > The MUST here has to be in section 10. This paragraph needs > to remove the requirement, and refer to section 10 instead. > > 12) Section 4.4: > > If a UA receives an INFO request for legacy usage, for > which no Info- > Package is associated (the INFO request does not contain an Info- > Package header field), the UA MUST send a 200 OK response. > > The UAS MAY send other responses, such as Request Failure (4xx), > Server Failure (5xx) and Global Failure (6xx) as > appropriate for the > request. > > The second paragraph above contradicts the first above. I > assume that means that there is a hidden condition that is > missing from the first paragraph. Something along the lines > of "that is otherwise syntactically correct and well structured". > > 13) Section 4.4: > > If a UA receives an INFO request associated with an Info > Package that > the UA has not indicated willingness to receive, the UA MUST send a > 469 Bad INFO Package response Section 11.6. In the terminology of > Multiple Dialog Usages [RFC5057], this represents a > Transaction Only > failure. > > I assume that "(see Section 11.6)" or something similar is > meant in the end of the first sentence. > > I believe we also need to define whether the response code > applies to the transaction or the dialog. It obviously has to > be the transaction. > > 14) Section 4.6: > > The Info Package mechanism relies on the CSeq header field > to detect > if an INFO request is received out of order. > > Given that nowhere else in the document do we mention CSeq in > this respect, I don't see how it can. I suspect we mean > something more like > > Many Info Packages can rely on the CSeq header field to detect > if an INFO request is received out of order. > > 15) Section 4.6: > > If specific applications need additional mechanisms for order of > delivery, those mechanisms, and related procedures, must > be specified > as part of the associated Info Package, and possible > sequence numbers > etc must be defined as application data. > > Change "must be specified" to "are specified". If we need a > real MUST, then it has to be in section 10 in any case, and I > would expect more on this issue there. > > 16) Section 6.2: > > This document does not define values for Info-Package types. > Individual Info Package specifications define these values. Such > specifications MUST register the values with IANA. These > values are > Specification Required [RFC5226]. > > The MUST part of this paragraph belongs in section 10. It is > not something the implementor of the Inof-Package header > field can directly comply with. > > 17) Section 7.3: > > One needs to consider the fate of the dialog usage of an > INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > Change "may" to "can". > > 18) Section 8.2: > > NOTE on the Recv-Info production: if the header field > value is "nil", > the header field MUST NOT contain any other Info Packages, and the > SIP message MUST NOT contain more than one Recv-Info header field. > > Please do not start a sentence containing RFC 2119 language > with the word "Note". It confuses the hell out of people who > understand that everything following that word is > informative. In any case, the first half of this sentence is > surely impossible in the ABNF and therefore the MUST is superfluous. > > 19) Section 9.3. > > As described in Section 4, an INFO request associated with an Info > Package always contains an Info-Package header field. A > legacy INFO > request MUST NOT contain an Info-Package header field. > > The first sentence of the above is fine. However the second > sentence is not conformable by implementations of this > specification. So I believe the "MUST" is incorrect and > should be replaced by something more descriptive. > > 20) Section 10.1: > > If an Info Package extends or modifies the behavior > described in this > document, it MUST be described in the definition for that Info > Package. Info Package definitions should not repeat procedures > defined in this specification, unless needed for clarification or > emphasis purpose. > > Change "it MUST" to "that behaviour MUST" > > As for the second sentence, assuming that we do not mean an > RFC 2119 SHOULD, which I believe we do not, reword as > follows: "It is bad practice for Info Package defintions to > repeat procedures defined in this specification, unless..." > > 21) Section 10.1: > > Info Packages MUST NOT weaken any behavior designated with "SHOULD" > or "MUST" in this specification. However, Info Packages MAY > strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" > strength if applications associated with the Info Package requires > it. > > Do we mean "Info Packages" here or "Info Package Definitions"? (twice) > > 22) Section 10.2: > > Annex A provides more information, and describes alternative > mechanisms which one should consider for solving a > specific use-case. > > reword to: > > Annex A provides more information, and describes alternative > mechanisms which are considered as part of the process for > solving a specific use-case. > > 23) Section 10.3 > > The Info Package specification MUST define a for Info Package name > (e.g. "Info Package for X"). > > Do we mean: > > The Info Package specification MUST define an Info Package name > (e.g. "Info Package for X"). > > 24) Section 10.3 > > The specification MUST also define the header field value (e.g. > "infoX") to be used to indicate support of this package in > the Recv- > Info and Info-Package header fields. > > Why do we allow the potential for a separate name for the > package, and the value that appears in the header fields. I > see this causing mixed usage in the IANA registrations. > Surely it is simpler that whatever appears in the header > fields is by definition the package name. It works for event > packages surely. > > 25) Section 10.4 > > Note that Info Package parameters are only applicable for the Info > Package(s) for which they have been explicitly defined. They MUST > NOT be used for other Info Packages. > > I don't think we need the MUST here. By virtue of the fact > that the Info Package specification defines only one Info > Package, it can only define parameters to be associated with > one Info Package. Yes other packages may define a parameter > with the same name, but we are not precluding that anyway. So > turn the second sentence into something informative rather > than RFC 2119. > > 26) Section 10.4 > > NOTE: Info Package parameters defined for specific Info > Packages may > share the name with parameters defined for other Info Packages, but > the parameter semantics are specific to the Info Package for which > they are defined. > > Change "may" to "can". > > 27) Section 10.5 > > SIP option tags MUST conform to the SIP Change Process > [I-D.peterson-rai-rfc3427bis]. > > I don't believe we need the MUST here. We merely need a > sentence that "the registration requirements for option tags > are defined in ...". As you have only made this an > informative reference in any case, that surely has to happen. > > 28) Section 10.6 > > The Info Package specification MUST define what type of > message body > parts are associated with the Info Package, and MUST refer to > specifications where the syntax, semantics and MIME type of the > message body parts are described. > > The text above appears to preclude the Info Package > specification defining them itself. > > 29) Section 10.7 > > The specification MUST define whether there are SIP level > restrictions in the usage of the Info Package. For > example, an Info > Package may require support of other SIP extensions (e.g. reliable > provisional responses). > > Change "may" to "can". > > 30) Section 10.7 > > As the SIP stack may not be aware of Info Package specific > restrictions, it cannot be assumed that overlapping > requests would be > rejected. As defined in Section 4.4, in most cases a 200 > OK response > will be sent for the INFO request. The application logic > associated > with the Info Package needs to handle situations which can > occur due > to overlapping requests. > > Change "may not" to "might not". > > 31) Section 10.9 > > The Info Package specification MUST contain an IANA Considerations > section that includes definitions for the Info Package Name and, if > needed, supported MIME types. > > I believe this is unduly onerous for Info Package definitions > not published by IETF and goes beyond what we require for > media feature tags. They need to fit their zpecification > structure. I believe that all we need to say is that the > registration requirements for IANA need to be readily > identifiable to IANA by including them in a single part of > the document to which IANAs attention is drawn at the time of > the registration request. > > 32) Section 10.11 > > The Info Package specification SHOULD contain a description of the > application procedures associated with the Info Package, or > alternatively refer to application procedures defined elsewhere. > > This SHOULD is inconsistent with section 4.3 which contains: > > Info Package specifications MUST describe the application level > information associated with the Info Package. > > I believe the MUST is correct. > > > regards > > Keith > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Oct 27 10:42:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4E33A6839 for ; Tue, 27 Oct 2009 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuC4iZ8eM3KU for ; Tue, 27 Oct 2009 10:42:21 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 751183A67F3 for ; Tue, 27 Oct 2009 10:42:20 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-74-4ae73109fbf4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id BD.85.31706.90137EA4; Tue, 27 Oct 2009 18:42:33 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 18:42:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 18:42:32 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-info-events-02 thread-index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3wAZ5oHQAAXAFGA= References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 27 Oct 2009 17:42:33.0454 (UTC) FILETIME=[DD2F90E0:01CA572C] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:42:24 -0000 Is that all you have to say??????? Just kidding. I am half way with your initial comments, and they were very good :)=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 27. lokakuuta 2009 19:38 To: sipcore@ietf.org Cc: draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 Some new comments and revision of one previous comment: 33) Section 1: Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages. Replace "invite" with upper case as I believe this is the RFC 3261 convention. 34) Section 3.2: The indication of Info Packages can take place during the dialog establishment, and during a target refresh. This includes INVITE, UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx only). Note that the UAC is not required to indicate its set of Info Packages in the initial INVITE request. This I guess supports the text in the table in section 6.1: Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR ------------------------------------------------------------------------ Info-Package R - - - - - - - m* - - - - - Recv-Info R o - - o o o o - - o - - - Recv-Info 2xx o - - o o - o - - o - - - Recv-Info 1xx o - - o o - o - - o - - - Recv-Info r o - - - o - o - - o - - - but this leaves a lot of open questions in my mind as to the support of the Recv-Info header in various methods, as follows: - what is the purpose in the REGISTER request, and does this have any impact on a future dialog usage? Does it indicate willingness to support in all future INVITE dialogs. In the absence of any further text in the document I would rather take it out. If there really is some future usage, then we need more text in the document that just the appearance in the table. - can't REFER or SUBSCRIBE be used as a target refresh request within an INVITE dialog usage. I don't particularly want to add a usage, but I think this points to a lack of precision of the section 3.2 text, which in some ways I would like to contain RFC 2119 language as well. I think personally I would prefer to limit the Recv-Info header usage to only the INVITE transaction and the UPDATE transaction and be very precise on that. I see no real use for its appearance in PRACK, ACK. - section 3.2 needs to deal with the OPTIONS usage, which I think is valid. - if we have a 4xx - 6xx response to a reINVITE, wh y is the support different that that for an UPDATE? 35) Section 5.1: For the supported header field tables I see no listing for the following headers: - Is a 415 response to INFO allowed containing the Accept header field? - Allow-Events (which I think is like Allow and appears in all requests and 2xx responses). - Referred-By header (again which I thought could appear in all methods). - Request-Disposition (again all methods). - Geolocation-Error (all responses). - Resource-Priority (allowed in all requests and responses, and needed if priority is applied on a per transaction basis rather than set for the entire dialog, which is one of the options in RFC 4412). - Accept-Resource-Priority in 2xx and 417 responses. I would also comment on the following for which entries appear. - Organization. Given the semantics of this, it would be the same as appears in the original INVITE that created the dialog. The use case mentioned in RFC 3261 does not apply to subsequent requests within a dialog. Moreover I think it is harmful if people think they can use this header to carry information that really belongs in the application. Therefore I would exclude it. - Allow. RFC3261 allows this in all responses according to my interpretation, rather than specifically 2xx and 405 (which I agree do get special mention). The entry for a 405 response should be m as it is mandatory, but o for all other responses. - Privacy. Listed for requests only. I have an understanding that this is also allowed in responses. - Reason. Listed for responses only. Currently it is allowed in requests (BYE and CANCEL in particular) and not responses. There are proposals to extend it to responses but they have not been adopted yet. I suspect the use cases for this header field in INFO are pretty much non-existent in any case. - Can I check that the Accept header field is not needed for 2xx responses. RFC 3261 provides for its usage in certain methods, but I am not sure about whether there is a use case in INFO. - Proxy-Authenticate. I though was also allowed for a 401 response as well as a 407 response. - Does the Retry-After header also apply to 413 responses and 500 responses, or are these responses not valid for INFO. Additional input on the following comment: > 13) Section 4.4: > > If a UA receives an INFO request associated with an Info Package=20 > that > the UA has not indicated willingness to receive, the UA MUST send a > 469 Bad INFO Package response Section 11.6. In the terminology of > Multiple Dialog Usages [RFC5057], this represents a Transaction=20 > Only > failure. > > I assume that "(see Section 11.6)" or something similar is meant in=20 > the end of the first sentence. > > I believe we also need to define whether the response code applies to=20 > the transaction or the dialog. It obviously has to be the transaction. > I do note the following text in 7.3 7.3. Dialog Fate Sharing As described in [RFC5057], an INFO request is always part of an INVITE dialog usage. One needs to consider the fate of the dialog usage of an INFO request is rejected. In some cases it may be acceptable that the whole dialog usage is terminated, while in other cases is is desirable to maintain the dialog usage. However as we have a specific new response code that represents a failure of the INFO method extension rather than any specific package, I believe the actions for 469 in respect of the dialog usage should be defined in this document. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, October 27, 2009 2:35 AM > To: sipcore@ietf.org > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > Various miscellaneous comments. I have not yet trawled > through all the other comments and discussion to find if > these have already been made elsewhere. I suspect I will find > some other comments at a later time. > > 1) General. Please write responses in the format "200 (OK) > response" rather than "200 OK response". > > 2) General. Can we fix on the term of either "Info Package > definition" or "Info Package specification" and use it > consistently (in full) throughout where we mean that term. > > 3) Section 3.2 > > A UA which supports the Info Package mechanism MUST indicate, using > the Revc-Info header field, the set of Info Packages for > which it is > willing to receive an INFO request. > ^^^ > > Insert "an" as indicated. > > 4) Section 3.2: > > If a UA is not willing to receive INFO requests for any > Info Packages, during > ^^^^^^^^ > dialog establishment or later during the INVITE dialog > usage, the UA > ^^^^^^^ > MUST indicate this by including a Recv-Info header field > with a 'nil' > value. > > Insert "receive" as indicated. Replace "invite" with upper > case as I believe this is the RFC 3261 convention. > > 5) Section 3.2 indicates: > > A UA MUST NOT send an INFO request associated with an Info Package > until it has received an indication that the remote UA is > willing to > receive INFO requests for that Info Package, and a dialog has been > established with the remote UA. > > and section 4.2 indicates: > > For a specific dialog, a UA > MUST NOT send INFO requests associated with Info Packages that the > remote UA has not indicated that it is willing to receive. > > Are these not the same requirement. We need to eliminate one. > > 6) Section 3.2 indicates: > > Likewise, even if a UA uses the Recv-Info header > field to indicate that it supports the Info Package mechanism, in > addition the UA MUST still also explicitly indicate support of the > INFO method using the Allow header field. > > I do not believe this should be a MUST, because it is surely > already a MUST in RFC 3261 - all we need to do is write an > informative sentence that in accordance with RFC 3261 the > Allow header also indicates INFO requests. > > 7) Section 3.3: > > 3.3. Package Versioning > > The Info Package mechanism does not support package versioning. > Specific Info Package payloads MAY contain version > information, which > is handled by the applications associated with the Info > Package, but > that is outside the scope of the Info Package mechanism. > > NOTE: Even if an Info Package name contains version numbering (e.g. > foo_v2), the Info Package mechanism does not distinguish a version > number from the rest of the Info Package name. > > As this is all part of the Info Package name, and needs to > form part of the Info Package specification if used, I think > all the text here should be moved to section 10.3, and this > section header deleted. > > 8) Section 4.3 indicates: > > Info Package specifications MUST describe the application level > information associated with the Info Package. Each body part MUST > have a MIME type value, and the syntax and content of the > body part, > defined. > > Each body part, when associated with an Info Package, MUST have a > Content-Disposition header field with an 'Info-Package' value > assigned, in order to be able distinguish body parts > associated with > the Info Package from other body parts. > > Surely this is something where the MUST can only be met by > the designer of the package, and therefore it belongs in section 10. > > 9) Section 4.3: > > NOTE: Some SIP functions that are orthogonal to INFO may > insert body > parts unrelated to the Info Package. > > Change "may" to "can". > > 10) Section 4.3: > > However, when a body part in the INFO message is associated with an > Info Package, it MUST always have a Content-Disposition > header field > with an 'Info-Package' value assigned. > > Is this not just a repeat of the requirement earlier in the > section (1 paragraph before the note). > > 11) Section 4.3: > > This document does not define Info Package specific rules > on how body > parts associated with Info Packages are to be inserted > into multipart > body parts, and what type of multiparts are used. If an > Info Package > requires special rules regarding the usage of multipart body parts, > the specification for that Info Package MUST specify such rules. > > The MUST here has to be in section 10. This paragraph needs > to remove the requirement, and refer to section 10 instead. > > 12) Section 4.4: > > If a UA receives an INFO request for legacy usage, for > which no Info- > Package is associated (the INFO request does not contain an Info- > Package header field), the UA MUST send a 200 OK response. > > The UAS MAY send other responses, such as Request Failure (4xx), > Server Failure (5xx) and Global Failure (6xx) as > appropriate for the > request. > > The second paragraph above contradicts the first above. I > assume that means that there is a hidden condition that is > missing from the first paragraph. Something along the lines > of "that is otherwise syntactically correct and well structured". > > 13) Section 4.4: > > If a UA receives an INFO request associated with an Info > Package that > the UA has not indicated willingness to receive, the UA MUST send a > 469 Bad INFO Package response Section 11.6. In the terminology of > Multiple Dialog Usages [RFC5057], this represents a > Transaction Only > failure. > > I assume that "(see Section 11.6)" or something similar is > meant in the end of the first sentence. > > I believe we also need to define whether the response code > applies to the transaction or the dialog. It obviously has to > be the transaction. > > 14) Section 4.6: > > The Info Package mechanism relies on the CSeq header field > to detect > if an INFO request is received out of order. > > Given that nowhere else in the document do we mention CSeq in > this respect, I don't see how it can. I suspect we mean > something more like > > Many Info Packages can rely on the CSeq header field to detect > if an INFO request is received out of order. > > 15) Section 4.6: > > If specific applications need additional mechanisms for order of > delivery, those mechanisms, and related procedures, must > be specified > as part of the associated Info Package, and possible > sequence numbers > etc must be defined as application data. > > Change "must be specified" to "are specified". If we need a > real MUST, then it has to be in section 10 in any case, and I > would expect more on this issue there. > > 16) Section 6.2: > > This document does not define values for Info-Package types. > Individual Info Package specifications define these values. Such > specifications MUST register the values with IANA. These > values are > Specification Required [RFC5226]. > > The MUST part of this paragraph belongs in section 10. It is > not something the implementor of the Inof-Package header > field can directly comply with. > > 17) Section 7.3: > > One needs to consider the fate of the dialog usage of an > INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > Change "may" to "can". > > 18) Section 8.2: > > NOTE on the Recv-Info production: if the header field > value is "nil", > the header field MUST NOT contain any other Info Packages, and the > SIP message MUST NOT contain more than one Recv-Info header field. > > Please do not start a sentence containing RFC 2119 language > with the word "Note". It confuses the hell out of people who > understand that everything following that word is > informative. In any case, the first half of this sentence is > surely impossible in the ABNF and therefore the MUST is superfluous. > > 19) Section 9.3. > > As described in Section 4, an INFO request associated with an Info > Package always contains an Info-Package header field. A > legacy INFO > request MUST NOT contain an Info-Package header field. > > The first sentence of the above is fine. However the second > sentence is not conformable by implementations of this > specification. So I believe the "MUST" is incorrect and > should be replaced by something more descriptive. > > 20) Section 10.1: > > If an Info Package extends or modifies the behavior > described in this > document, it MUST be described in the definition for that Info > Package. Info Package definitions should not repeat procedures > defined in this specification, unless needed for clarification or > emphasis purpose. > > Change "it MUST" to "that behaviour MUST" > > As for the second sentence, assuming that we do not mean an > RFC 2119 SHOULD, which I believe we do not, reword as > follows: "It is bad practice for Info Package defintions to > repeat procedures defined in this specification, unless..." > > 21) Section 10.1: > > Info Packages MUST NOT weaken any behavior designated with "SHOULD" > or "MUST" in this specification. However, Info Packages MAY > strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" > strength if applications associated with the Info Package requires > it. > > Do we mean "Info Packages" here or "Info Package Definitions"? (twice) > > 22) Section 10.2: > > Annex A provides more information, and describes alternative > mechanisms which one should consider for solving a > specific use-case. > > reword to: > > Annex A provides more information, and describes alternative > mechanisms which are considered as part of the process for > solving a specific use-case. > > 23) Section 10.3 > > The Info Package specification MUST define a for Info Package name > (e.g. "Info Package for X"). > > Do we mean: > > The Info Package specification MUST define an Info Package name > (e.g. "Info Package for X"). > > 24) Section 10.3 > > The specification MUST also define the header field value (e.g. > "infoX") to be used to indicate support of this package in > the Recv- > Info and Info-Package header fields. > > Why do we allow the potential for a separate name for the > package, and the value that appears in the header fields. I > see this causing mixed usage in the IANA registrations. > Surely it is simpler that whatever appears in the header > fields is by definition the package name. It works for event > packages surely. > > 25) Section 10.4 > > Note that Info Package parameters are only applicable for the Info > Package(s) for which they have been explicitly defined. They MUST > NOT be used for other Info Packages. > > I don't think we need the MUST here. By virtue of the fact > that the Info Package specification defines only one Info > Package, it can only define parameters to be associated with > one Info Package. Yes other packages may define a parameter > with the same name, but we are not precluding that anyway. So > turn the second sentence into something informative rather > than RFC 2119. > > 26) Section 10.4 > > NOTE: Info Package parameters defined for specific Info > Packages may > share the name with parameters defined for other Info Packages, but > the parameter semantics are specific to the Info Package for which > they are defined. > > Change "may" to "can". > > 27) Section 10.5 > > SIP option tags MUST conform to the SIP Change Process > [I-D.peterson-rai-rfc3427bis]. > > I don't believe we need the MUST here. We merely need a > sentence that "the registration requirements for option tags > are defined in ...". As you have only made this an > informative reference in any case, that surely has to happen. > > 28) Section 10.6 > > The Info Package specification MUST define what type of > message body > parts are associated with the Info Package, and MUST refer to > specifications where the syntax, semantics and MIME type of the > message body parts are described. > > The text above appears to preclude the Info Package > specification defining them itself. > > 29) Section 10.7 > > The specification MUST define whether there are SIP level > restrictions in the usage of the Info Package. For > example, an Info > Package may require support of other SIP extensions (e.g. reliable > provisional responses). > > Change "may" to "can". > > 30) Section 10.7 > > As the SIP stack may not be aware of Info Package specific > restrictions, it cannot be assumed that overlapping > requests would be > rejected. As defined in Section 4.4, in most cases a 200 > OK response > will be sent for the INFO request. The application logic > associated > with the Info Package needs to handle situations which can > occur due > to overlapping requests. > > Change "may not" to "might not". > > 31) Section 10.9 > > The Info Package specification MUST contain an IANA Considerations > section that includes definitions for the Info Package Name and, if > needed, supported MIME types. > > I believe this is unduly onerous for Info Package definitions > not published by IETF and goes beyond what we require for > media feature tags. They need to fit their zpecification > structure. I believe that all we need to say is that the > registration requirements for IANA need to be readily > identifiable to IANA by including them in a single part of > the document to which IANAs attention is drawn at the time of > the registration request. > > 32) Section 10.11 > > The Info Package specification SHOULD contain a description of the > application procedures associated with the Info Package, or > alternatively refer to application procedures defined elsewhere. > > This SHOULD is inconsistent with section 4.3 which contains: > > Info Package specifications MUST describe the application level > information associated with the Info Package. > > I believe the MUST is correct. > > > regards > > Keith > > _______________________________________________ > 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 jmpolk@cisco.com Tue Oct 27 11:19:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC9B28C127; Tue, 27 Oct 2009 11:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMuIaoBuYL+y; Tue, 27 Oct 2009 11:19:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 911FF3A68B0; Tue, 27 Oct 2009 11:19:11 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgEAAbW5kqrR7Hu/2dsb2JhbACIG7knmFaEPwQ X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="262258641" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 18:19:26 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9RIJQIY005144; Tue, 27 Oct 2009 18:19:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:19:26 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.171]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:19:25 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Oct 2009 13:19:23 -0500 To: "Miguel A. Garcia" From: "James M. Polk" In-Reply-To: <4AE6B7FE.4090505@ericsson.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Oct 2009 18:19:25.0206 (UTC) FILETIME=[037E2360:01CA5732] Cc: geopriv@ietf.org, sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:19:12 -0000 Miguel comments in-line At 04:06 AM 10/27/2009, Miguel A. Garcia wrote: >Hi James, > >some inline comments. > >On 26/10/2009 18:41, James M. Polk wrote: > >>>>Currently, and pretty much since whatever version of >>>>http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt >>>> >>>>has existed in whatever WG it happened to reside in at the time, >>>>Location Conveyance using SIP has included the use of PUBLISH to convey >>>>location as a message body, or as a location URI since about, or before >>>>2005. I fail to see or read what you want in your doc that cannot be >>>>covered in SIP Location Conveyance. >>> >>>I understand that the Geolocation header has quite a few similarities >>>with what is proposed in the draft. I don't think the Geolocation >>>header has means to indicate the presence server "you should >>>de-reference the location and insert it in a presence document to be >>>offered to watchers". >> >>hmmm... it's this a policy choice between the presentity and the >>presence server (i.e., what to have the PS pass on as a reference, and >>what the PS dereferences to pass on only as a value)? How can't that be >>a policy between the PA and PS (including which references to leave as >>references, and which are dereferenced and sent by the PS as a value)? > >At the moment the draft is not ambitious to have the PS passing the >reference to the watcher. This might be something to look at it a >bit later, but so far, the only ambition is that the PS >de-references the location and adds it to the PIDF that is offered to watchers. watchers SUBSCRIBE to a PS to get presentity state information, right? If true, then the NOTIFY can carry the Geolocation header-value with a location URI as the answer to the watcher for (geographically) where the presentity is - provided it has been authorized to receive such information. This isn't hard. This to, can be added to SIP Location Conveyance (if the SIPCORE WG agrees with this addition). >>In that sense, this mechanism (policy notification of which URIs it >>receives from the PA need to be dereferenced) ought to be general, and >>not limited to location. I can see one argument being "the PA should >>include with the URI reference whether or not to do this deference", but >>that can lead to mistakes - as then each URI the PS receives has to look >>for the indication -- which is always an extension to how the URI is >>sent to the PS in the first place. That's clumbersome IMO. >> >>Therefore, IMO, this shouldn't be >> >>- a new SIP header >>- with or without a new option-tag >>- an indication to each way a PS receives a URI >> >>but, rather, more general. >> >>The issue that has to be watched out for is when 2 or more URIs get sent >>to the PS and only a subset needs this dereference treatment. > >I think I concur with you, except the level of ambition, as I said before. > >> >> >>>>I cannot figure out how you claim usage of the Geolocation is too >>>>limiting. >>> >>>I have several criticism to the use of a SIP header to convey this >>>information. Indirect location is just a particular case of a general >>>solution, which is, a presentity wants to publish some information by >>>reference not by value. Location is the more straight forward example, >>>but we should try to find a general solution. >> >>I'm not really understanding this example. If a PA wants to have a >>watcher get a URI, then the PA sends a URI to the PS. If the PA wants to >>have the watcher get a value, the PA sends a value to the PS *or* the PA >>sends a URI to the PS and the PS dereferences the URI to be able to send >>a value to a watcher. >> >>To me this is a function the PS knows to do when it receives certain >>URIs (i.e., reference types). Receiving a Location URI could be one such >>situation. > >I agree with your analysis. > >> >>I wonder if there is another issue -- shouldn't the PS determine when to >>send the reference vs. a value mostly based on who is asking for the >>information? > >This is discussed before, we are building from the ground, and the >first step is to make the PS to dereference the location URI. >Passing the URI is something for which don't have requirements at >the moment, so will analyze whether is worth doing it once we have >solved our main problem. it seems - since you do not have requirements to send the watcher a location URI for a presentity's location that the PS dereferencing will always happen. If true, then this appears to me to be a fixed policy - for the time being (i.e., until something else tells the PS to do something different) - to *always* dereference any location URI it receives from a presentity in a PUBLISH. To me, the PS doesn't need to be told to do anything, since only one action can occur (i.e., to dereference). If you agree with the above, why do you need a flag telling the PS to do anything other than a default action (i.e., to dereference the location URI) and send the location value to authorized watchers? It feels like you are forcing this to be an explicit instruction instead of a default implicit action to always be done until told to do something else (like send a location URI - which could require a flag at some future date). Why not have the following rule cover what you want the recommended policy be to dereference any location URI received in a Geolocation header-value (in a PUBLISH) from a presentity, to give to authorized watchers. This seems to cover what you want. And when you reach consensus on the requirement to send a watcher the location URI instead of a location value, that will need to be indicated with further work. >>>So, if we agree to pursue a general solution for publication of >>>presence information by reference, then I find difficult to think of a >>>solution based on a new or existing SIP header. Instead, we should be >>>looking at the XML body, either to an extension to the existing one or >>>a new XML body that. >> >>You're proposing have this indication solely in a message body? >> >>This appears to me to be overkill just to get a flag from a PA to a PS. >> >>I could be wrong though... > >Well, at the moment all solution spaces are open. If we want to make >something general enough, it cannot be done at the SIP level, so we >should be looking at ways to do it at the XML level. Using and XML >diff document (XML Patch operations) might be a way to move forward. >We are currently investigating this track. As stated above, I believe you are wanting a default action for the PS to dereference location URIs to provide location values to watchers, without a choice in the matter (of giving out a location URI to a watcher instead). This seems like a policy choice that can be stated as a recommendation or a should (both 2119 strength) in an existing document, until you determine the time has come for the requirement to send a watcher the location URI instead of a value. James >/Miguel > >-- >Miguel A. Garcia >+34-91-339-3608 >Ericsson Spain From adam@estacado.net Tue Oct 27 14:00:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D6D63A681F for ; Tue, 27 Oct 2009 14:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CildFKAko16t for ; Tue, 27 Oct 2009 14:00:08 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 63BF828C241 for ; Tue, 27 Oct 2009 14:00:07 -0700 (PDT) Received: from [172.16.3.231] (dn3-231.estacado.net [172.16.3.231]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9RKx1SS010418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 15:59:01 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE75F15.9070504@estacado.net> Date: Tue, 27 Oct 2009 15:59:01 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Oscar Novo \(JO/LMF\)" Subject: [sipcore] SIPCORE Preliminary Agenda Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:00:11 -0000 [as chair] A preliminary agenda for the upcoming SIPCORE face-to-face meeting in Hiroshima has been posted: http://www.ietf.org/proceedings/09nov/agenda/sipcore.html Comments are welcome. /a From drage@alcatel-lucent.com Tue Oct 27 17:38:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D4E28C17B for ; Tue, 27 Oct 2009 17:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECDAcesYk7RV for ; Tue, 27 Oct 2009 17:38:12 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id AD6EE28C170 for ; Tue, 27 Oct 2009 17:38:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9S0bNhT001448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Oct 2009 01:37:24 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 28 Oct 2009 01:37:24 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Elwell, John" , SIPCORE Date: Wed, 28 Oct 2009 01:37:22 +0100 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording Thread-Index: AcpNEK0P0zMXEv0WSfWdH9WrSAXuTwEMClcAAAQmAfAAC0Dp0AANYe8wAAENTmAAIr50AAFIc1Hg Message-ID: References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: Adam Roach , Gonzalo Camarillo , "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:38:13 -0000 Is it just me, or are we making this all way more complicated that it shoul= d be. Let us start from two principles. 1) If we find ourselves trying to describe body handling issues in the info= -event draft, then either the body handling RFC is broken, or we are going = beyond the scope of something that should be generic. 2) If an info-package has need of multiple data streams that are somehow se= nt in the same INFO message, then that should be done at the application le= vel and not multiplexed at the SIP level. In my view the multiple MIME bodi= es are more at the SIP level than at the application level. There will alwa= ys be some relationship description between the two data streams that multi= part MIME cannot describe because it is application specific. So I would suggest we stick to the rules of: One body per INFO message.=20 One Info-package per INFO message.=20 The one body in potential multipart must be clearly labelled as belonging t= o the Info-package. Other bodies in multipart bodies belong to other dialog= usages. I can envisage an entity that works under the rule - everytime you= send a message include a Geolocation and associated body. I would allow the stand MIME multipart/alt etc because to me that is someth= ing that come down below the application level, e.g. two alternative transf= er syntaxs or something like that. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Wednesday, October 21, 2009 12:42 PM > To: Elwell, John; SIPCORE > Cc: Adam Roach; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > receive Info-Package wording >=20 > =20 > Hi, > =20 > >>>2. In several places in the document (e.g., Abstract,=20 > section 1), it=20 > >>>talks about receiving Info Packages, but I think that > is=20 > >>>incorrect. Shouldn't it really be worded along the lines=20 > of receiving=20 > >>>information within the context of an Info Package? (c.f.,=20 > RFC 3265,=20 > >>>where we don't receive event packages in NOTIFY >requests,=20 > we receive=20 > >>>events). > >>>=20 > >>>I guess an alternative is to talk about "receiving information=20 > >>>associated with an Info Package". It would be more words, though.. > >>>[JRE] Yes, that would work, but I am open to suggestions=20 > to shorten=20 > >>>it, as long as we don't resort to inaccurate formulations > like=20 > >>>we have at present. > >>=20 > >>Or, we could somewhere in the beginning of the document=20 > clarify that=20 > >>"receive Info Package" means to receive an INFO associated with an=20 > >>Info Package, or something like that... > >[JRE] If this would make the document more readable (in terms of=20 > >avoiding long formulations in many places in the document),=20 > it would at=20 > >least be an improvement on what we have at present. >=20 > What about if we talked about "indicating for which Info=20 > Packages a UA is willing to receive INFO requests"? >=20 > Then it is more clear that the user does not receive an Info=20 > Package, bur rather an INFO request associated with an Info Package. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Tue Oct 27 17:42:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C8728C154 for ; Tue, 27 Oct 2009 17:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02brx3j1UeJA for ; Tue, 27 Oct 2009 17:42:16 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 403D028C119 for ; Tue, 27 Oct 2009 17:42:16 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9S0fxrl020654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 19:42:00 -0500 Message-Id: <9582AECE-FF96-4D02-9AF6-2E6188E762F5@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 19:41:52 -0500 References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:42:17 -0000 On Oct 27, 2009, at 12:10 PM, Christer Holmberg wrote: > > > But, I still think it is good to point out that if a body part can be > used as a singular body part, the C-D must be 'info-package'. If a > body > part is ALWAYS inside a mulipart container the C-D value can be > whatever. How about: The top-level container of the INFO Payload body MUST have a content- distribution of info-package. Lower-level parts in a multi-part SHOULD use content-distribution values appropriate to the application, and their values SHOULD be specified by the info-package specification. -- Dean From dean.willis@softarmor.com Tue Oct 27 17:47:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A080B28C15D for ; Tue, 27 Oct 2009 17:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sTuD9p99I5m for ; Tue, 27 Oct 2009 17:47:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C80B628C178 for ; Tue, 27 Oct 2009 17:47:24 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9S0l9p9020683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Oct 2009 19:47:10 -0500 Message-Id: <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> From: Dean Willis To: "DRAGE, Keith (Keith)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Oct 2009 19:47:03 -0500 References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> X-Mailer: Apple Mail (2.936) Cc: Adam Roach , "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:47:25 -0000 On Oct 27, 2009, at 7:37 PM, DRAGE, Keith (Keith) wrote: > Is it just me, or are we making this all way more complicated that > it should be. > > Let us start from two principles. > > 1) If we find ourselves trying to describe body handling issues in > the info-event draft, then either the body handling RFC is broken, > or we are going beyond the scope of something that should be generic. > > 2) If an info-package has need of multiple data streams that are > somehow sent in the same INFO message, then that should be done at > the application level and not multiplexed at the SIP level. In my > view the multiple MIME bodies are more at the SIP level than at the > application level. There will always be some relationship > description between the two data streams that multipart MIME cannot > describe because it is application specific. > > So I would suggest we stick to the rules of: > > One body per INFO message. We have described use cases where a multipart body per INFO is required, because the INFO payload itself has multiple parts defined by the package. For example, a location body(or link) and an image body(or link) for geotagged imagery. > > One Info-package per INFO message. > We agree there. > The one body in potential multipart must be clearly labelled as > belonging to the Info-package. Other bodies in multipart bodies > belong to other dialog usages. I can envisage an entity that works > under the rule - everytime you send a message include a Geolocation > and associated body. I mostly agree, but instead believe that there must be a singular object that is marked as info-package, and that it may have sub- components with other markings that are marked for other dispositions but are still part of the package specification's payload. This container might be related, alternative, or any other multiplicative MIME structure. In other words, it's a tree, and everything below the C-D "info- package" node on the tree is party of the info-package payload. -- Dean From drage@alcatel-lucent.com Tue Oct 27 17:48:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946FC28C178 for ; Tue, 27 Oct 2009 17:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG4mk-2J88Dv for ; Tue, 27 Oct 2009 17:48:20 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id BDCD028C16D for ; Tue, 27 Oct 2009 17:48:19 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9S0mXG8021145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Oct 2009 01:48:33 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 28 Oct 2009 01:48:33 +0100 From: "DRAGE, Keith (Keith)" To: "DRAGE, Keith (Keith)" , "sipcore@ietf.org" Date: Wed, 28 Oct 2009 01:48:29 +0100 Thread-Topic: Comments on draft-ietf-sipcore-info-events-02 Thread-Index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3wAZ5oHQABRie3A= Message-ID: References: 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 00:48:22 -0000 One new comment 36) Subclause 6.1. The table specifies: Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR ------------------------------------------------------------------------ Info-Package R - - - - - - - m* - - - - - Recv-Info R o - - o o o o - - o - - - Recv-Info 2xx o - - o o - o - - o - - - Recv-Info 1xx o - - o o - o - - o - - - Recv-Info r o - - - o - o - - o - - - But section 3.1 lists: A UA which supports the Info Package mechanism MUST indicate, using the Revc-Info header field, the set of Info Packages for which it is willing to receive INFO request. A UA can list multiple Info Packages in a single Recv-Info header field, and the UA can use multiple Recv-Info header fields. and If a UA is not willing to receive INFO requests for any Info Packages, d= uring dialog establishment or later during the invite INVITE dialog usage, the= UA MUST indicate this by including a Recv-Info header field with a 'nil' value. This informs other UAs that the UA still supports the Info Package mechanism. Even if I only support legacy usage, I don't seem to find any text that wai= ves the requirement for implementations that support this i-d to support th= e Recv-Info requirements. It is only the implementations that support and a= re conformant to RFC 2976 that will not include this header field. That mea= ns that if Recv-Info is allowed in a message, and I support this extension,= I must include the header field, even if its value is "nil". Surely that w= ould make all the entries in the table above "m". regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Tuesday, October 27, 2009 5:38 PM > To: sipcore@ietf.org > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > Some new comments and revision of one previous comment: > > 33) Section 1: > > Use of the INFO method does not constitute a separate dialog usage. > INFO messages are always part of, and share the fate of, an invite > dialog usage [RFC5057]. INFO messages cannot be sent as part of > other dialog usages. > > Replace "invite" with upper case as I believe this is the RFC > 3261 convention. > > 34) Section 3.2: > > The indication of Info Packages can take place during the dialog > establishment, and during a target refresh. This includes INVITE, > UPDATE, PRACK, ACK, and their non-failure responses > (101-199 and 2xx > only). Note that the UAC is not required to indicate its > set of Info > Packages in the initial INVITE request. > > This I guess supports the text in the table in section 6.1: > > > Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD > SUB NOT RFR > -------------------------------------------------------------- > ---------- > Info-Package R - - - - - - - m* - - > - - - > Recv-Info R o - - o o o o - - o > - - - > Recv-Info 2xx o - - o o - o - - o > - - - > Recv-Info 1xx o - - o o - o - - o > - - - > Recv-Info r o - - - o - o - - o > - - - > > but this leaves a lot of open questions in my mind as to the > support of the Recv-Info header in various methods, as follows: > > - what is the purpose in the REGISTER request, and does > this have any impact on a future dialog usage? Does it > indicate willingness to support in all future INVITE dialogs. > In the absence of any further text in the document I would > rather take it out. If there really is some future usage, > then we need more text in the document that just the > appearance in the table. > > - can't REFER or SUBSCRIBE be used as a target refresh > request within an INVITE dialog usage. I don't particularly > want to add a usage, but I think this points to a lack of > precision of the section 3.2 text, which in some ways I would > like to contain RFC 2119 language as well. I think personally > I would prefer to limit the Recv-Info header usage to only > the INVITE transaction and the UPDATE transaction and be very > precise on that. I see no real use for its appearance in PRACK, ACK. > > - section 3.2 needs to deal with the OPTIONS usage, > which I think is valid. > > - if we have a 4xx - 6xx response to a reINVITE, wh > y is the support different that that for an UPDATE? > > 35) Section 5.1: > > For the supported header field tables I see no listing for > the following headers: > > - Is a 415 response to INFO allowed containing the > Accept header field? > > - Allow-Events (which I think is like Allow and appears > in all requests and 2xx responses). > > - Referred-By header (again which I thought could > appear in all methods). > > - Request-Disposition (again all methods). > > - Geolocation-Error (all responses). > > - Resource-Priority (allowed in all requests and > responses, and needed if priority is applied on a per > transaction basis rather than set for the entire dialog, > which is one of the options in RFC 4412). > > - Accept-Resource-Priority in 2xx and 417 responses. > > I would also comment on the following for which entries appear. > > - Organization. Given the semantics of this, it would > be the same as appears in the original INVITE that created > the dialog. The use case mentioned in RFC 3261 does not apply > to subsequent requests within a dialog. Moreover I think it > is harmful if people think they can use this header to carry > information that really belongs in the application. Therefore > I would exclude it. > > - Allow. RFC3261 allows this in all responses according > to my interpretation, rather than specifically 2xx and 405 > (which I agree do get special mention). The entry for a 405 > response should be m as it is mandatory, but o for all other > responses. > > - Privacy. Listed for requests only. I have an > understanding that this is also allowed in responses. > > - Reason. Listed for responses only. Currently it is > allowed in requests (BYE and CANCEL in particular) and not > responses. There are proposals to extend it to responses but > they have not been adopted yet. I suspect the use cases for > this header field in INFO are pretty much non-existent in any case. > > - Can I check that the Accept header field is not > needed for 2xx responses. RFC 3261 provides for its usage in > certain methods, but I am not sure about whether there is a > use case in INFO. > > - Proxy-Authenticate. I though was also allowed for a > 401 response as well as a 407 response. > > - Does the Retry-After header also apply to 413 > responses and 500 responses, or are these responses not valid > for INFO. > > > > > Additional input on the following comment: > > > 13) Section 4.4: > > > > If a UA receives an INFO request associated with an Info Package > > that > > the UA has not indicated willingness to receive, the UA > MUST send a > > 469 Bad INFO Package response Section 11.6. In the > terminology of > > Multiple Dialog Usages [RFC5057], this represents a Transaction > > Only > > failure. > > > > I assume that "(see Section 11.6)" or something similar is meant in > > the end of the first sentence. > > > > I believe we also need to define whether the response code > applies to > > the transaction or the dialog. It obviously has to be the > transaction. > > > > I do note the following text in 7.3 > > 7.3. Dialog Fate Sharing > > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. > > One needs to consider the fate of the dialog usage of an > INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > However as we have a specific new response code that > represents a failure of the INFO method extension rather than > any specific package, I believe the actions for 469 in > respect of the dialog usage should be defined in this document. > > > regards > > Keith > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > > Sent: Tuesday, October 27, 2009 2:35 AM > > To: sipcore@ietf.org > > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > > Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > > > Various miscellaneous comments. I have not yet trawled > > through all the other comments and discussion to find if > > these have already been made elsewhere. I suspect I will find > > some other comments at a later time. > > > > 1) General. Please write responses in the format "200 (OK) > > response" rather than "200 OK response". > > > > 2) General. Can we fix on the term of either "Info Package > > definition" or "Info Package specification" and use it > > consistently (in full) throughout where we mean that term. > > > > 3) Section 3.2 > > > > A UA which supports the Info Package mechanism MUST > indicate, using > > the Revc-Info header field, the set of Info Packages for > > which it is > > willing to receive an INFO request. > > ^^^ > > > > Insert "an" as indicated. > > > > 4) Section 3.2: > > > > If a UA is not willing to receive INFO requests for any > > Info Packages, during > > ^^^^^^^^ > > dialog establishment or later during the INVITE dialog > > usage, the UA > > ^^^^^^^ > > MUST indicate this by including a Recv-Info header field > > with a 'nil' > > value. > > > > Insert "receive" as indicated. Replace "invite" with upper > > case as I believe this is the RFC 3261 convention. > > > > 5) Section 3.2 indicates: > > > > A UA MUST NOT send an INFO request associated with an > Info Package > > until it has received an indication that the remote UA is > > willing to > > receive INFO requests for that Info Package, and a > dialog has been > > established with the remote UA. > > > > and section 4.2 indicates: > > > > For a specific dialog, a UA > > MUST NOT send INFO requests associated with Info > Packages that the > > remote UA has not indicated that it is willing to receive. > > > > Are these not the same requirement. We need to eliminate one. > > > > 6) Section 3.2 indicates: > > > > Likewise, even if a UA uses the Recv-Info header > > field to indicate that it supports the Info Package mechanism, in > > addition the UA MUST still also explicitly indicate > support of the > > INFO method using the Allow header field. > > > > I do not believe this should be a MUST, because it is surely > > already a MUST in RFC 3261 - all we need to do is write an > > informative sentence that in accordance with RFC 3261 the > > Allow header also indicates INFO requests. > > > > 7) Section 3.3: > > > > 3.3. Package Versioning > > > > The Info Package mechanism does not support package versioning. > > Specific Info Package payloads MAY contain version > > information, which > > is handled by the applications associated with the Info > > Package, but > > that is outside the scope of the Info Package mechanism. > > > > NOTE: Even if an Info Package name contains version > numbering (e.g. > > foo_v2), the Info Package mechanism does not distinguish > a version > > number from the rest of the Info Package name. > > > > As this is all part of the Info Package name, and needs to > > form part of the Info Package specification if used, I think > > all the text here should be moved to section 10.3, and this > > section header deleted. > > > > 8) Section 4.3 indicates: > > > > Info Package specifications MUST describe the application level > > information associated with the Info Package. Each body > part MUST > > have a MIME type value, and the syntax and content of the > > body part, > > defined. > > > > Each body part, when associated with an Info Package, MUST have a > > Content-Disposition header field with an 'Info-Package' value > > assigned, in order to be able distinguish body parts > > associated with > > the Info Package from other body parts. > > > > Surely this is something where the MUST can only be met by > > the designer of the package, and therefore it belongs in section 10. > > > > 9) Section 4.3: > > > > NOTE: Some SIP functions that are orthogonal to INFO may > > insert body > > parts unrelated to the Info Package. > > > > Change "may" to "can". > > > > 10) Section 4.3: > > > > However, when a body part in the INFO message is > associated with an > > Info Package, it MUST always have a Content-Disposition > > header field > > with an 'Info-Package' value assigned. > > > > Is this not just a repeat of the requirement earlier in the > > section (1 paragraph before the note). > > > > 11) Section 4.3: > > > > This document does not define Info Package specific rules > > on how body > > parts associated with Info Packages are to be inserted > > into multipart > > body parts, and what type of multiparts are used. If an > > Info Package > > requires special rules regarding the usage of multipart > body parts, > > the specification for that Info Package MUST specify such rules. > > > > The MUST here has to be in section 10. This paragraph needs > > to remove the requirement, and refer to section 10 instead. > > > > 12) Section 4.4: > > > > If a UA receives an INFO request for legacy usage, for > > which no Info- > > Package is associated (the INFO request does not contain an Info- > > Package header field), the UA MUST send a 200 OK response. > > > > The UAS MAY send other responses, such as Request Failure (4xx), > > Server Failure (5xx) and Global Failure (6xx) as > > appropriate for the > > request. > > > > The second paragraph above contradicts the first above. I > > assume that means that there is a hidden condition that is > > missing from the first paragraph. Something along the lines > > of "that is otherwise syntactically correct and well structured". > > > > 13) Section 4.4: > > > > If a UA receives an INFO request associated with an Info > > Package that > > the UA has not indicated willingness to receive, the UA > MUST send a > > 469 Bad INFO Package response Section 11.6. In the > terminology of > > Multiple Dialog Usages [RFC5057], this represents a > > Transaction Only > > failure. > > > > I assume that "(see Section 11.6)" or something similar is > > meant in the end of the first sentence. > > > > I believe we also need to define whether the response code > > applies to the transaction or the dialog. It obviously has to > > be the transaction. > > > > 14) Section 4.6: > > > > The Info Package mechanism relies on the CSeq header field > > to detect > > if an INFO request is received out of order. > > > > Given that nowhere else in the document do we mention CSeq in > > this respect, I don't see how it can. I suspect we mean > > something more like > > > > Many Info Packages can rely on the CSeq header field to detect > > if an INFO request is received out of order. > > > > 15) Section 4.6: > > > > If specific applications need additional mechanisms for order of > > delivery, those mechanisms, and related procedures, must > > be specified > > as part of the associated Info Package, and possible > > sequence numbers > > etc must be defined as application data. > > > > Change "must be specified" to "are specified". If we need a > > real MUST, then it has to be in section 10 in any case, and I > > would expect more on this issue there. > > > > 16) Section 6.2: > > > > This document does not define values for Info-Package types. > > Individual Info Package specifications define these values. Such > > specifications MUST register the values with IANA. These > > values are > > Specification Required [RFC5226]. > > > > The MUST part of this paragraph belongs in section 10. It is > > not something the implementor of the Inof-Package header > > field can directly comply with. > > > > 17) Section 7.3: > > > > One needs to consider the fate of the dialog usage of an > > INFO request > > is rejected. In some cases it may be acceptable that the whole > > dialog usage is terminated, while in other cases is is > desirable to > > maintain the dialog usage. > > > > Change "may" to "can". > > > > 18) Section 8.2: > > > > NOTE on the Recv-Info production: if the header field > > value is "nil", > > the header field MUST NOT contain any other Info > Packages, and the > > SIP message MUST NOT contain more than one Recv-Info > header field. > > > > Please do not start a sentence containing RFC 2119 language > > with the word "Note". It confuses the hell out of people who > > understand that everything following that word is > > informative. In any case, the first half of this sentence is > > surely impossible in the ABNF and therefore the MUST is superfluous. > > > > 19) Section 9.3. > > > > As described in Section 4, an INFO request associated > with an Info > > Package always contains an Info-Package header field. A > > legacy INFO > > request MUST NOT contain an Info-Package header field. > > > > The first sentence of the above is fine. However the second > > sentence is not conformable by implementations of this > > specification. So I believe the "MUST" is incorrect and > > should be replaced by something more descriptive. > > > > 20) Section 10.1: > > > > If an Info Package extends or modifies the behavior > > described in this > > document, it MUST be described in the definition for that Info > > Package. Info Package definitions should not repeat procedures > > defined in this specification, unless needed for clarification or > > emphasis purpose. > > > > Change "it MUST" to "that behaviour MUST" > > > > As for the second sentence, assuming that we do not mean an > > RFC 2119 SHOULD, which I believe we do not, reword as > > follows: "It is bad practice for Info Package defintions to > > repeat procedures defined in this specification, unless..." > > > > 21) Section 10.1: > > > > Info Packages MUST NOT weaken any behavior designated > with "SHOULD" > > or "MUST" in this specification. However, Info Packages MAY > > strengthen "SHOULD", "MAY", or "RECOMMENDED" > requirements to "MUST" > > strength if applications associated with the Info > Package requires > > it. > > > > Do we mean "Info Packages" here or "Info Package > Definitions"? (twice) > > > > 22) Section 10.2: > > > > Annex A provides more information, and describes alternative > > mechanisms which one should consider for solving a > > specific use-case. > > > > reword to: > > > > Annex A provides more information, and describes alternative > > mechanisms which are considered as part of the process for > > solving a specific use-case. > > > > 23) Section 10.3 > > > > The Info Package specification MUST define a for Info > Package name > > (e.g. "Info Package for X"). > > > > Do we mean: > > > > The Info Package specification MUST define an Info Package name > > (e.g. "Info Package for X"). > > > > 24) Section 10.3 > > > > The specification MUST also define the header field value (e.g. > > "infoX") to be used to indicate support of this package in > > the Recv- > > Info and Info-Package header fields. > > > > Why do we allow the potential for a separate name for the > > package, and the value that appears in the header fields. I > > see this causing mixed usage in the IANA registrations. > > Surely it is simpler that whatever appears in the header > > fields is by definition the package name. It works for event > > packages surely. > > > > 25) Section 10.4 > > > > Note that Info Package parameters are only applicable > for the Info > > Package(s) for which they have been explicitly defined. > They MUST > > NOT be used for other Info Packages. > > > > I don't think we need the MUST here. By virtue of the fact > > that the Info Package specification defines only one Info > > Package, it can only define parameters to be associated with > > one Info Package. Yes other packages may define a parameter > > with the same name, but we are not precluding that anyway. So > > turn the second sentence into something informative rather > > than RFC 2119. > > > > 26) Section 10.4 > > > > NOTE: Info Package parameters defined for specific Info > > Packages may > > share the name with parameters defined for other Info > Packages, but > > the parameter semantics are specific to the Info Package > for which > > they are defined. > > > > Change "may" to "can". > > > > 27) Section 10.5 > > > > SIP option tags MUST conform to the SIP Change Process > > [I-D.peterson-rai-rfc3427bis]. > > > > I don't believe we need the MUST here. We merely need a > > sentence that "the registration requirements for option tags > > are defined in ...". As you have only made this an > > informative reference in any case, that surely has to happen. > > > > 28) Section 10.6 > > > > The Info Package specification MUST define what type of > > message body > > parts are associated with the Info Package, and MUST refer to > > specifications where the syntax, semantics and MIME type of the > > message body parts are described. > > > > The text above appears to preclude the Info Package > > specification defining them itself. > > > > 29) Section 10.7 > > > > The specification MUST define whether there are SIP level > > restrictions in the usage of the Info Package. For > > example, an Info > > Package may require support of other SIP extensions > (e.g. reliable > > provisional responses). > > > > Change "may" to "can". > > > > 30) Section 10.7 > > > > As the SIP stack may not be aware of Info Package specific > > restrictions, it cannot be assumed that overlapping > > requests would be > > rejected. As defined in Section 4.4, in most cases a 200 > > OK response > > will be sent for the INFO request. The application logic > > associated > > with the Info Package needs to handle situations which can > > occur due > > to overlapping requests. > > > > Change "may not" to "might not". > > > > 31) Section 10.9 > > > > The Info Package specification MUST contain an IANA > Considerations > > section that includes definitions for the Info Package > Name and, if > > needed, supported MIME types. > > > > I believe this is unduly onerous for Info Package definitions > > not published by IETF and goes beyond what we require for > > media feature tags. They need to fit their zpecification > > structure. I believe that all we need to say is that the > > registration requirements for IANA need to be readily > > identifiable to IANA by including them in a single part of > > the document to which IANAs attention is drawn at the time of > > the registration request. > > > > 32) Section 10.11 > > > > The Info Package specification SHOULD contain a > description of the > > application procedures associated with the Info Package, or > > alternatively refer to application procedures defined elsewhere. > > > > This SHOULD is inconsistent with section 4.3 which contains: > > > > Info Package specifications MUST describe the application level > > information associated with the Info Package. > > > > I believe the MUST is correct. > > > > > > regards > > > > Keith > > > > _______________________________________________ > > 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 christer.holmberg@ericsson.com Tue Oct 27 22:52:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4585228C196 for ; Tue, 27 Oct 2009 22:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igPep+z2RfD9 for ; Tue, 27 Oct 2009 22:52:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1D91228C18E for ; Tue, 27 Oct 2009 22:52:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-39-4ae7dc325428 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 96.14.24026.23CD7EA4; Wed, 28 Oct 2009 06:52:50 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 06:52:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 06:52:49 +0100 Message-ID: In-Reply-To: <9582AECE-FF96-4D02-9AF6-2E6188E762F5@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? thread-index: AcpXZ3kb+YHWCM0GQuSCSw/7OadFuQAKucig References: <4ADF1E49.5030804@cisco.com> <4ADF63CD.5050707@cisco.com> <4ADF9BFC.50007@cisco.com> <4AE0995A.9050906@estacado.net> <4AE0AA5F.3010308@estacado.net> <4AE2296D.7040503@cisco.com> <4AE28D37.6000902@estacado.net> <4AE34FD3.4070408@estacado.net> <4AE59FA1.2000006@cisco.com> <4AE5 BA15.7060907@cisco.com> <55F408CD-F088-4B93-8C73-94120BFFA36C@softarmor.com> <4AE6467B.3010206@cisco.com> <87213CB9-8BCD-41BD-8715-B566D5B8A8B7@softarmor.com> <9582AECE-FF96-4D02-9AF6-2E6188E762F5@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 28 Oct 2009 05:52:50.0162 (UTC) FILETIME=[E1FA9D20:01CA5792] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - non-I-P body parts in INFO? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 05:52:38 -0000 Hi,=20 >>But, I still think it is good to point out that if a body part can be=20 >>used as a singular body part, the C-D must be 'info-package'. If a=20 >>body part is ALWAYS inside a mulipart container the C-D=20 >>value can be whatever. >=20 >=20 >How about: >=20 >The top-level container of the INFO Payload body MUST have a content-=20 >distribution of info-package. Lower-level parts in a=20 >multi-part SHOULD use content-distribution values appropriate to the application, and =20 >their values SHOULD be specified by the info-package specification. Looks good. I am also ok using SHOULD, but we should add that otherwise the default value for SIP will be assumed. Also, will everyone understand what "top-level container" means? Is that terminology defined somewhere? Is it clear by definition that a "container" can also be a single body (ie not multipart)? Regards, Christer From christer.holmberg@ericsson.com Tue Oct 27 23:12:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5C03A67F2 for ; Tue, 27 Oct 2009 23:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7Z-WhvYI2tk for ; Tue, 27 Oct 2009 23:12:44 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7491D3A6824 for ; Tue, 27 Oct 2009 23:12:43 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-97-4ae7e0e842fb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 0E.F8.31706.8E0E7EA4; Wed, 28 Oct 2009 07:12:56 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 07:12:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 07:12:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-info-events-02 thread-index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3wAZ5oHQABRie3AAC4S6EA== References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 28 Oct 2009 06:12:56.0584 (UTC) FILETIME=[B1100080:01CA5795] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 06:12:46 -0000 Hi Keith, So, I guess we somewhere would need text saying that UAs that *only* support legacy INFO usages are not mandated to use the Recv-Info header? Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 28. lokakuuta 2009 2:48 > To: DRAGE, Keith (Keith); sipcore@ietf.org > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 >=20 > One new comment >=20 > 36) Subclause 6.1. The table specifies: >=20 > Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD=20 > SUB NOT RFR > -------------------------------------------------------------- > ---------- > Info-Package R - - - - - - - m* - - =20 > - - - > Recv-Info R o - - o o o o - - o =20 > - - - > Recv-Info 2xx o - - o o - o - - o =20 > - - - > Recv-Info 1xx o - - o o - o - - o =20 > - - - > Recv-Info r o - - - o - o - - o =20 > - - - >=20 > But section 3.1 lists: >=20 > A UA which supports the Info Package mechanism MUST indicate, using > the Revc-Info header field, the set of Info Packages for=20 > which it is > willing to receive INFO request. A UA can list multiple Info > Packages in a single Recv-Info header field, and the UA can use > multiple Recv-Info header fields. >=20 > and >=20 > If a UA is not willing to receive INFO requests for any=20 > Info Packages, during > dialog establishment or later during the invite INVITE=20 > dialog usage, the UA > MUST indicate this by including a Recv-Info header field=20 > with a 'nil' > value. This informs other UAs that the UA still supports the Info > Package mechanism. >=20 > Even if I only support legacy usage, I don't seem to find any=20 > text that waives the requirement for implementations that=20 > support this i-d to support the Recv-Info requirements. It is=20 > only the implementations that support and are conformant to=20 > RFC 2976 that will not include this header field. That means=20 > that if Recv-Info is allowed in a message, and I support this=20 > extension, I must include the header field, even if its value=20 > is "nil". Surely that would make all the entries in the table=20 > above "m". >=20 > regards >=20 > Keith >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > > Sent: Tuesday, October 27, 2009 5:38 PM > > To: sipcore@ietf.org > > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > > > Some new comments and revision of one previous comment: > > > > 33) Section 1: > > > > Use of the INFO method does not constitute a separate=20 > dialog usage. > > INFO messages are always part of, and share the fate of,=20 > an invite > > dialog usage [RFC5057]. INFO messages cannot be sent as part of > > other dialog usages. > > > > Replace "invite" with upper case as I believe this is the RFC > > 3261 convention. > > > > 34) Section 3.2: > > > > The indication of Info Packages can take place during the dialog > > establishment, and during a target refresh. This=20 > includes INVITE, > > UPDATE, PRACK, ACK, and their non-failure responses > > (101-199 and 2xx > > only). Note that the UAC is not required to indicate its set of=20 > > Info > > Packages in the initial INVITE request. > > > > This I guess supports the text in the table in section 6.1: > > > > > > Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD > > SUB NOT RFR > > -------------------------------------------------------------- > > ---------- > > Info-Package R - - - - - - - m* - - > > - - - > > Recv-Info R o - - o o o o - - o > > - - - > > Recv-Info 2xx o - - o o - o - - o > > - - - > > Recv-Info 1xx o - - o o - o - - o > > - - - > > Recv-Info r o - - - o - o - - o > > - - - > > > > but this leaves a lot of open questions in my mind as to=20 > the support=20 > > of the Recv-Info header in various methods, as follows: > > > > - what is the purpose in the REGISTER request, and does > > this have any impact on a future dialog usage? Does it indicate=20 > > willingness to support in all future INVITE dialogs. > > In the absence of any further text in the document I would=20 > rather take=20 > > it out. If there really is some future usage, then we need=20 > more text=20 > > in the document that just the appearance in the table. > > > > - can't REFER or SUBSCRIBE be used as a target refresh > > request within an INVITE dialog usage. I don't particularly want to=20 > > add a usage, but I think this points to a lack of precision of the=20 > > section 3.2 text, which in some ways I would like to=20 > contain RFC 2119=20 > > language as well. I think personally I would prefer to limit the=20 > > Recv-Info header usage to only the INVITE transaction and=20 > the UPDATE=20 > > transaction and be very precise on that. I see no real use for its=20 > > appearance in PRACK, ACK. > > > > - section 3.2 needs to deal with the OPTIONS usage, > > which I think is valid. > > > > - if we have a 4xx - 6xx response to a reINVITE, wh > > y is the support different that that for an UPDATE? > > > > 35) Section 5.1: > > > > For the supported header field tables I see no listing for the=20 > > following headers: > > > > - Is a 415 response to INFO allowed containing the > > Accept header field? > > > > - Allow-Events (which I think is like Allow and appears > > in all requests and 2xx responses). > > > > - Referred-By header (again which I thought could > > appear in all methods). > > > > - Request-Disposition (again all methods). > > > > - Geolocation-Error (all responses). > > > > - Resource-Priority (allowed in all requests and > > responses, and needed if priority is applied on a per transaction=20 > > basis rather than set for the entire dialog, which is one of the=20 > > options in RFC 4412). > > > > - Accept-Resource-Priority in 2xx and 417 responses. > > > > I would also comment on the following for which entries appear. > > > > - Organization. Given the semantics of this, it would > > be the same as appears in the original INVITE that created=20 > the dialog.=20 > > The use case mentioned in RFC 3261 does not apply to subsequent=20 > > requests within a dialog. Moreover I think it is harmful if people=20 > > think they can use this header to carry information that really=20 > > belongs in the application. Therefore I would exclude it. > > > > - Allow. RFC3261 allows this in all responses according > > to my interpretation, rather than specifically 2xx and 405 (which I=20 > > agree do get special mention). The entry for a 405 response=20 > should be=20 > > m as it is mandatory, but o for all other responses. > > > > - Privacy. Listed for requests only. I have an > > understanding that this is also allowed in responses. > > > > - Reason. Listed for responses only. Currently it is > > allowed in requests (BYE and CANCEL in particular) and not=20 > responses.=20 > > There are proposals to extend it to responses but they have=20 > not been=20 > > adopted yet. I suspect the use cases for this header field=20 > in INFO are=20 > > pretty much non-existent in any case. > > > > - Can I check that the Accept header field is not > > needed for 2xx responses. RFC 3261 provides for its usage=20 > in certain=20 > > methods, but I am not sure about whether there is a use=20 > case in INFO. > > > > - Proxy-Authenticate. I though was also allowed for a > > 401 response as well as a 407 response. > > > > - Does the Retry-After header also apply to 413 > > responses and 500 responses, or are these responses not valid for=20 > > INFO. > > > > > > > > > > Additional input on the following comment: > > > > > 13) Section 4.4: > > > > > > If a UA receives an INFO request associated with an=20 > Info Package=20 > > > that > > > the UA has not indicated willingness to receive, the UA > > MUST send a > > > 469 Bad INFO Package response Section 11.6. In the > > terminology of > > > Multiple Dialog Usages [RFC5057], this represents a=20 > Transaction=20 > > > Only > > > failure. > > > > > > I assume that "(see Section 11.6)" or something similar=20 > is meant in=20 > > > the end of the first sentence. > > > > > > I believe we also need to define whether the response code > > applies to > > > the transaction or the dialog. It obviously has to be the > > transaction. > > > > > > > I do note the following text in 7.3 > > > > 7.3. Dialog Fate Sharing > > > > As described in [RFC5057], an INFO request is always part of an > > INVITE dialog usage. > > > > One needs to consider the fate of the dialog usage of an INFO=20 > > request > > is rejected. In some cases it may be acceptable that the whole > > dialog usage is terminated, while in other cases is is=20 > desirable to > > maintain the dialog usage. > > > > However as we have a specific new response code that represents a=20 > > failure of the INFO method extension rather than any=20 > specific package,=20 > > I believe the actions for 469 in respect of the dialog=20 > usage should be=20 > > defined in this document. > > > > > > regards > > > > Keith > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE,=20 > Keith (Keith) > > > Sent: Tuesday, October 27, 2009 2:35 AM > > > To: sipcore@ietf.org > > > Cc: draft-ietf-sipcore-info-events@tools.ietf.org > > > Subject: [sipcore] Comments on draft-ietf-sipcore-info-events-02 > > > > > > Various miscellaneous comments. I have not yet trawled=20 > through all=20 > > > the other comments and discussion to find if these have=20 > already been=20 > > > made elsewhere. I suspect I will find some other comments=20 > at a later=20 > > > time. > > > > > > 1) General. Please write responses in the format "200 (OK) > > > response" rather than "200 OK response". > > > > > > 2) General. Can we fix on the term of either "Info Package > > > definition" or "Info Package specification" and use it=20 > consistently=20 > > > (in full) throughout where we mean that term. > > > > > > 3) Section 3.2 > > > > > > A UA which supports the Info Package mechanism MUST > > indicate, using > > > the Revc-Info header field, the set of Info Packages=20 > for which it=20 > > > is > > > willing to receive an INFO request. > > > ^^^ > > > > > > Insert "an" as indicated. > > > > > > 4) Section 3.2: > > > > > > If a UA is not willing to receive INFO requests for any Info=20 > > > Packages, during > > > ^^^^^^^^ > > > dialog establishment or later during the INVITE dialog=20 > usage, the=20 > > > UA > > > ^^^^^^^ > > > MUST indicate this by including a Recv-Info header=20 > field with a=20 > > > 'nil' > > > value. > > > > > > Insert "receive" as indicated. Replace "invite" with=20 > upper case as I=20 > > > believe this is the RFC 3261 convention. > > > > > > 5) Section 3.2 indicates: > > > > > > A UA MUST NOT send an INFO request associated with an > > Info Package > > > until it has received an indication that the remote UA=20 > is willing=20 > > > to > > > receive INFO requests for that Info Package, and a > > dialog has been > > > established with the remote UA. > > > > > > and section 4.2 indicates: > > > > > > For a specific dialog, a UA > > > MUST NOT send INFO requests associated with Info > > Packages that the > > > remote UA has not indicated that it is willing to receive. > > > > > > Are these not the same requirement. We need to eliminate one. > > > > > > 6) Section 3.2 indicates: > > > > > > Likewise, even if a UA uses the Recv-Info header > > > field to indicate that it supports the Info Package=20 > mechanism, in > > > addition the UA MUST still also explicitly indicate > > support of the > > > INFO method using the Allow header field. > > > > > > I do not believe this should be a MUST, because it is=20 > surely already=20 > > > a MUST in RFC 3261 - all we need to do is write an informative=20 > > > sentence that in accordance with RFC 3261 the Allow header also=20 > > > indicates INFO requests. > > > > > > 7) Section 3.3: > > > > > > 3.3. Package Versioning > > > > > > The Info Package mechanism does not support package versioning. > > > Specific Info Package payloads MAY contain version=20 > information,=20 > > > which > > > is handled by the applications associated with the=20 > Info Package,=20 > > > but > > > that is outside the scope of the Info Package mechanism. > > > > > > NOTE: Even if an Info Package name contains version > > numbering (e.g. > > > foo_v2), the Info Package mechanism does not distinguish > > a version > > > number from the rest of the Info Package name. > > > > > > As this is all part of the Info Package name, and needs=20 > to form part=20 > > > of the Info Package specification if used, I think all=20 > the text here=20 > > > should be moved to section 10.3, and this section header deleted. > > > > > > 8) Section 4.3 indicates: > > > > > > Info Package specifications MUST describe the application level > > > information associated with the Info Package. Each body > > part MUST > > > have a MIME type value, and the syntax and content of the body=20 > > > part, > > > defined. > > > > > > Each body part, when associated with an Info Package,=20 > MUST have a > > > Content-Disposition header field with an 'Info-Package' value > > > assigned, in order to be able distinguish body parts=20 > associated=20 > > > with > > > the Info Package from other body parts. > > > > > > Surely this is something where the MUST can only be met by the=20 > > > designer of the package, and therefore it belongs in section 10. > > > > > > 9) Section 4.3: > > > > > > NOTE: Some SIP functions that are orthogonal to INFO=20 > may insert=20 > > > body > > > parts unrelated to the Info Package. > > > > > > Change "may" to "can". > > > > > > 10) Section 4.3: > > > > > > However, when a body part in the INFO message is > > associated with an > > > Info Package, it MUST always have a Content-Disposition header=20 > > > field > > > with an 'Info-Package' value assigned. > > > > > > Is this not just a repeat of the requirement earlier in=20 > the section=20 > > > (1 paragraph before the note). > > > > > > 11) Section 4.3: > > > > > > This document does not define Info Package specific=20 > rules on how=20 > > > body > > > parts associated with Info Packages are to be inserted into=20 > > > multipart > > > body parts, and what type of multiparts are used. If an Info=20 > > > Package > > > requires special rules regarding the usage of multipart > > body parts, > > > the specification for that Info Package MUST specify=20 > such rules. > > > > > > The MUST here has to be in section 10. This paragraph needs to=20 > > > remove the requirement, and refer to section 10 instead. > > > > > > 12) Section 4.4: > > > > > > If a UA receives an INFO request for legacy usage, for=20 > which no=20 > > > Info- > > > Package is associated (the INFO request does not=20 > contain an Info- > > > Package header field), the UA MUST send a 200 OK response. > > > > > > The UAS MAY send other responses, such as Request=20 > Failure (4xx), > > > Server Failure (5xx) and Global Failure (6xx) as=20 > appropriate for=20 > > > the > > > request. > > > > > > The second paragraph above contradicts the first above. I assume=20 > > > that means that there is a hidden condition that is=20 > missing from the=20 > > > first paragraph. Something along the lines of "that is otherwise=20 > > > syntactically correct and well structured". > > > > > > 13) Section 4.4: > > > > > > If a UA receives an INFO request associated with an=20 > Info Package=20 > > > that > > > the UA has not indicated willingness to receive, the UA > > MUST send a > > > 469 Bad INFO Package response Section 11.6. In the > > terminology of > > > Multiple Dialog Usages [RFC5057], this represents a=20 > Transaction=20 > > > Only > > > failure. > > > > > > I assume that "(see Section 11.6)" or something similar=20 > is meant in=20 > > > the end of the first sentence. > > > > > > I believe we also need to define whether the response=20 > code applies=20 > > > to the transaction or the dialog. It obviously has to be the=20 > > > transaction. > > > > > > 14) Section 4.6: > > > > > > The Info Package mechanism relies on the CSeq header field to=20 > > > detect > > > if an INFO request is received out of order. > > > > > > Given that nowhere else in the document do we mention=20 > CSeq in this=20 > > > respect, I don't see how it can. I suspect we mean something more=20 > > > like > > > > > > Many Info Packages can rely on the CSeq header field to detect > > > if an INFO request is received out of order. > > > > > > 15) Section 4.6: > > > > > > If specific applications need additional mechanisms=20 > for order of > > > delivery, those mechanisms, and related procedures, must be=20 > > > specified > > > as part of the associated Info Package, and possible sequence=20 > > > numbers > > > etc must be defined as application data. > > > > > > Change "must be specified" to "are specified". If we need a real=20 > > > MUST, then it has to be in section 10 in any case, and I would=20 > > > expect more on this issue there. > > > > > > 16) Section 6.2: > > > > > > This document does not define values for Info-Package types. > > > Individual Info Package specifications define these=20 > values. Such > > > specifications MUST register the values with IANA. =20 > These values=20 > > > are > > > Specification Required [RFC5226]. > > > > > > The MUST part of this paragraph belongs in section 10. It is not=20 > > > something the implementor of the Inof-Package header field can=20 > > > directly comply with. > > > > > > 17) Section 7.3: > > > > > > One needs to consider the fate of the dialog usage of an INFO=20 > > > request > > > is rejected. In some cases it may be acceptable that the whole > > > dialog usage is terminated, while in other cases is is > > desirable to > > > maintain the dialog usage. > > > > > > Change "may" to "can". > > > > > > 18) Section 8.2: > > > > > > NOTE on the Recv-Info production: if the header field value is=20 > > > "nil", > > > the header field MUST NOT contain any other Info > > Packages, and the > > > SIP message MUST NOT contain more than one Recv-Info > > header field. > > > > > > Please do not start a sentence containing RFC 2119=20 > language with the=20 > > > word "Note". It confuses the hell out of people who=20 > understand that=20 > > > everything following that word is informative. In any case, the=20 > > > first half of this sentence is surely impossible in the ABNF and=20 > > > therefore the MUST is superfluous. > > > > > > 19) Section 9.3. > > > > > > As described in Section 4, an INFO request associated > > with an Info > > > Package always contains an Info-Package header field. =20 > A legacy=20 > > > INFO > > > request MUST NOT contain an Info-Package header field. > > > > > > The first sentence of the above is fine. However the=20 > second sentence=20 > > > is not conformable by implementations of this specification. So I=20 > > > believe the "MUST" is incorrect and should be replaced by=20 > something=20 > > > more descriptive. > > > > > > 20) Section 10.1: > > > > > > If an Info Package extends or modifies the behavior=20 > described in=20 > > > this > > > document, it MUST be described in the definition for that Info > > > Package. Info Package definitions should not repeat procedures > > > defined in this specification, unless needed for=20 > clarification or > > > emphasis purpose. > > > > > > Change "it MUST" to "that behaviour MUST" > > > > > > As for the second sentence, assuming that we do not mean=20 > an RFC 2119=20 > > > SHOULD, which I believe we do not, reword as > > > follows: "It is bad practice for Info Package defintions=20 > to repeat=20 > > > procedures defined in this specification, unless..." > > > > > > 21) Section 10.1: > > > > > > Info Packages MUST NOT weaken any behavior designated > > with "SHOULD" > > > or "MUST" in this specification. However, Info Packages MAY > > > strengthen "SHOULD", "MAY", or "RECOMMENDED" > > requirements to "MUST" > > > strength if applications associated with the Info > > Package requires > > > it. > > > > > > Do we mean "Info Packages" here or "Info Package > > Definitions"? (twice) > > > > > > 22) Section 10.2: > > > > > > Annex A provides more information, and describes alternative > > > mechanisms which one should consider for solving a specific=20 > > > use-case. > > > > > > reword to: > > > > > > Annex A provides more information, and describes alternative > > > mechanisms which are considered as part of the process for=20 > > > solving a specific use-case. > > > > > > 23) Section 10.3 > > > > > > The Info Package specification MUST define a for Info > > Package name > > > (e.g. "Info Package for X"). > > > > > > Do we mean: > > > > > > The Info Package specification MUST define an Info Package name > > > (e.g. "Info Package for X"). > > > > > > 24) Section 10.3 > > > > > > The specification MUST also define the header field value (e.g. > > > "infoX") to be used to indicate support of this package in the=20 > > > Recv- > > > Info and Info-Package header fields. > > > > > > Why do we allow the potential for a separate name for the=20 > package,=20 > > > and the value that appears in the header fields. I see=20 > this causing=20 > > > mixed usage in the IANA registrations. > > > Surely it is simpler that whatever appears in the header=20 > fields is=20 > > > by definition the package name. It works for event=20 > packages surely. > > > > > > 25) Section 10.4 > > > > > > Note that Info Package parameters are only applicable > > for the Info > > > Package(s) for which they have been explicitly defined. > > They MUST > > > NOT be used for other Info Packages. > > > > > > I don't think we need the MUST here. By virtue of the=20 > fact that the=20 > > > Info Package specification defines only one Info Package, it can=20 > > > only define parameters to be associated with one Info=20 > Package. Yes=20 > > > other packages may define a parameter with the same name,=20 > but we are=20 > > > not precluding that anyway. So turn the second sentence into=20 > > > something informative rather than RFC 2119. > > > > > > 26) Section 10.4 > > > > > > NOTE: Info Package parameters defined for specific=20 > Info Packages=20 > > > may > > > share the name with parameters defined for other Info > > Packages, but > > > the parameter semantics are specific to the Info Package > > for which > > > they are defined. > > > > > > Change "may" to "can". > > > > > > 27) Section 10.5 > > > > > > SIP option tags MUST conform to the SIP Change Process > > > [I-D.peterson-rai-rfc3427bis]. > > > > > > I don't believe we need the MUST here. We merely need a sentence=20 > > > that "the registration requirements for option tags are=20 > defined in=20 > > > ...". As you have only made this an informative reference in any=20 > > > case, that surely has to happen. > > > > > > 28) Section 10.6 > > > > > > The Info Package specification MUST define what type=20 > of message=20 > > > body > > > parts are associated with the Info Package, and MUST refer to > > > specifications where the syntax, semantics and MIME type of the > > > message body parts are described. > > > > > > The text above appears to preclude the Info Package specification=20 > > > defining them itself. > > > > > > 29) Section 10.7 > > > > > > The specification MUST define whether there are SIP level > > > restrictions in the usage of the Info Package. For=20 > example, an=20 > > > Info > > > Package may require support of other SIP extensions > > (e.g. reliable > > > provisional responses). > > > > > > Change "may" to "can". > > > > > > 30) Section 10.7 > > > > > > As the SIP stack may not be aware of Info Package specific > > > restrictions, it cannot be assumed that overlapping requests=20 > > > would be > > > rejected. As defined in Section 4.4, in most cases a 200 OK=20 > > > response > > > will be sent for the INFO request. The application logic=20 > > > associated > > > with the Info Package needs to handle situations which=20 > can occur=20 > > > due > > > to overlapping requests. > > > > > > Change "may not" to "might not". > > > > > > 31) Section 10.9 > > > > > > The Info Package specification MUST contain an IANA > > Considerations > > > section that includes definitions for the Info Package > > Name and, if > > > needed, supported MIME types. > > > > > > I believe this is unduly onerous for Info Package definitions not=20 > > > published by IETF and goes beyond what we require for=20 > media feature=20 > > > tags. They need to fit their zpecification structure. I=20 > believe that=20 > > > all we need to say is that the registration requirements for IANA=20 > > > need to be readily identifiable to IANA by including them in a=20 > > > single part of the document to which IANAs attention is=20 > drawn at the=20 > > > time of the registration request. > > > > > > 32) Section 10.11 > > > > > > The Info Package specification SHOULD contain a > > description of the > > > application procedures associated with the Info Package, or > > > alternatively refer to application procedures defined=20 > elsewhere. > > > > > > This SHOULD is inconsistent with section 4.3 which contains: > > > > > > Info Package specifications MUST describe the application level > > > information associated with the Info Package. > > > > > > I believe the MUST is correct. > > > > > > > > > regards > > > > > > Keith > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From john.elwell@siemens-enterprise.com Wed Oct 28 00:16:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9783A698B for ; Wed, 28 Oct 2009 00:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkbQOjOqDxdo for ; Wed, 28 Oct 2009 00:16:38 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id 00CE83A68AF for ; Wed, 28 Oct 2009 00:16:37 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9S7GPvm001774; Wed, 28 Oct 2009 08:16:26 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9S7GPU8031803; Wed, 28 Oct 2009 08:16:25 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 28 Oct 2009 08:16:24 +0100 From: "Elwell, John" To: Dean Willis , "DRAGE, Keith (Keith)" Date: Wed, 28 Oct 2009 08:16:22 +0100 Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording Thread-Index: AcpXaEGz+mIINO0aQISssLLpwIbSkAANVsPg Message-ID: <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> In-Reply-To: <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Adam Roach , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 07:16:39 -0000 Yes, I think Dean, Paul and myself are all arguing to keep it simple. One I= nfo-Package per INFO message (that was agreed a long time ago), one body pa= rt per Info-Package with C-D Info-Package. What type of body part is left t= o the Info Package definition and could be multipart, in which case the chi= ld body parts would also be defined as part of the Info Package, not in thi= s spec. The less we say about what happens within the Info Package body par= t, the better. Finally, the single Info-Package body part can be carried wi= th other body parts within a multi-part body part. John > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 28 October 2009 00:47 > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; Elwell, John; SIPCORE; Adam Roach;=20 > Gonzalo Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > receive Info-Package wording >=20 >=20 > On Oct 27, 2009, at 7:37 PM, DRAGE, Keith (Keith) wrote: >=20 > > Is it just me, or are we making this all way more complicated that =20 > > it should be. > > > > Let us start from two principles. > > > > 1) If we find ourselves trying to describe body handling=20 > issues in =20 > > the info-event draft, then either the body handling RFC is broken, =20 > > or we are going beyond the scope of something that should=20 > be generic. > > > > 2) If an info-package has need of multiple data streams that are =20 > > somehow sent in the same INFO message, then that should be done at =20 > > the application level and not multiplexed at the SIP level. In my =20 > > view the multiple MIME bodies are more at the SIP level=20 > than at the =20 > > application level. There will always be some relationship =20 > > description between the two data streams that multipart=20 > MIME cannot =20 > > describe because it is application specific. > > > > So I would suggest we stick to the rules of: > > > > One body per INFO message. >=20 > We have described use cases where a multipart body per INFO is =20 > required, because the INFO payload itself has multiple parts defined =20 > by the package. For example, a location body(or link) and an image =20 > body(or link) for geotagged imagery. >=20 > > > > One Info-package per INFO message. > > >=20 > We agree there. >=20 > > The one body in potential multipart must be clearly labelled as =20 > > belonging to the Info-package. Other bodies in multipart bodies =20 > > belong to other dialog usages. I can envisage an entity that works =20 > > under the rule - everytime you send a message include a=20 > Geolocation =20 > > and associated body. >=20 > I mostly agree, but instead believe that there must be a singular =20 > object that is marked as info-package, and that it may have sub-=20 > components with other markings that are marked for other=20 > dispositions =20 > but are still part of the package specification's payload. This =20 > container might be related, alternative, or any other multiplicative =20 > MIME structure. >=20 > In other words, it's a tree, and everything below the C-D "info-=20 > package" node on the tree is party of the info-package payload. >=20 > -- > Dean >=20 >=20 > = From adam@estacado.net Wed Oct 28 06:07:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F66A3A69DF for ; Wed, 28 Oct 2009 06:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DhqL2Erz9jX for ; Wed, 28 Oct 2009 06:07:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F38B53A698B for ; Wed, 28 Oct 2009 06:07:17 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-113-207.dsl.rcsntx.swbell.net [70.242.113.207]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9SD7UTg007583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 08:07:30 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4AE84212.3040802@estacado.net> Date: Wed, 28 Oct 2009 08:07:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.113.207 is authenticated by a trusted mechanism) Cc: "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:07:19 -0000 [as an individual] On 10/28/09 02:16, Oct 28, Elwell, John wrote: > Yes, I think Dean, Paul and myself are all arguing to keep it simple. One Info-Package per INFO message (that was agreed a long time ago), one body part per Info-Package with C-D Info-Package. What type of body part is left to the Info Package definition and could be multipart, in which case the child body parts would also be defined as part of the Info Package, not in this spec. The less we say about what happens within the Info Package body part, the better. Finally, the single Info-Package body part can be carried with other body parts within a multi-part body part. > Excellent summary, and I agree with all aspects of it. /a From christer.holmberg@ericsson.com Wed Oct 28 06:31:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A673A687C for ; Wed, 28 Oct 2009 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWTukOlAwD4B for ; Wed, 28 Oct 2009 06:31:46 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D1D903A6782 for ; Wed, 28 Oct 2009 06:31:45 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-9d-4ae847cf11e1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E3.1B.31706.FC748EA4; Wed, 28 Oct 2009 14:31:59 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:31:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 14:31:28 +0100 Message-ID: In-Reply-To: <4AE84212.3040802@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording thread-index: AcpXz5/DAE6ixjHDQzeeB49V0n9Y0gAAyLRQ References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> <4AE84212.3040802@estacado.net> From: "Christer Holmberg" To: "Adam Roach" , "Elwell, John" X-OriginalArrivalTime: 28 Oct 2009 13:31:59.0281 (UTC) FILETIME=[06889210:01CA57D3] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:31:47 -0000 I'll try to put together some text. Regards, Christer > -----Original Message----- > From: Adam Roach [mailto:adam@estacado.net]=20 > Sent: 28. lokakuuta 2009 15:08 > To: Elwell, John > Cc: Dean Willis; DRAGE, Keith (Keith); Christer Holmberg;=20 > SIPCORE; Gonzalo Camarillo;=20 > draft-ietf-sipcore-info-events@tools.ietf.org > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > receive Info-Package wording >=20 > [as an individual] >=20 > On 10/28/09 02:16, Oct 28, Elwell, John wrote: > > Yes, I think Dean, Paul and myself are all arguing to keep=20 > it simple. One Info-Package per INFO message (that was agreed=20 > a long time ago), one body part per Info-Package with C-D=20 > Info-Package. What type of body part is left to the Info=20 > Package definition and could be multipart, in which case the=20 > child body parts would also be defined as part of the Info=20 > Package, not in this spec. The less we say about what happens=20 > within the Info Package body part, the better. Finally, the=20 > single Info-Package body part can be carried with other body=20 > parts within a multi-part body part. > > =20 >=20 > Excellent summary, and I agree with all aspects of it. >=20 > /a >=20 From pkyzivat@cisco.com Wed Oct 28 06:35:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CA03A6934 for ; Wed, 28 Oct 2009 06:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kMvgRz464TT for ; Wed, 28 Oct 2009 06:35:32 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 66EDD3A6893 for ; Wed, 28 Oct 2009 06:35:32 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANvl50qrR7Hu/2dsb2JhbADCJpgxhD8E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208";a="199333542" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Oct 2009 13:35:47 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9SDZk6r017455; Wed, 28 Oct 2009 13:35:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:35:46 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 09:35:46 -0400 Message-ID: <4AE848B1.30208@cisco.com> Date: Wed, 28 Oct 2009 09:35:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 13:35:46.0357 (UTC) FILETIME=[8DE19E50:01CA57D3] Cc: Adam Roach , "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:35:33 -0000 YES! Elwell, John wrote: > Yes, I think Dean, Paul and myself are all arguing to keep it simple. One Info-Package per INFO message (that was agreed a long time ago), one body part per Info-Package with C-D Info-Package. What type of body part is left to the Info Package definition and could be multipart, in which case the child body parts would also be defined as part of the Info Package, not in this spec. The less we say about what happens within the Info Package body part, the better. Finally, the single Info-Package body part can be carried with other body parts within a multi-part body part. > > John > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: 28 October 2009 00:47 >> To: DRAGE, Keith (Keith) >> Cc: Christer Holmberg; Elwell, John; SIPCORE; Adam Roach; >> Gonzalo Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org >> Subject: Re: [sipcore] WGLC comments >> (draft-ietf-sipcore-info-events-01) - John E's comments - >> receive Info-Package wording >> >> >> On Oct 27, 2009, at 7:37 PM, DRAGE, Keith (Keith) wrote: >> >>> Is it just me, or are we making this all way more complicated that >>> it should be. >>> >>> Let us start from two principles. >>> >>> 1) If we find ourselves trying to describe body handling >> issues in >>> the info-event draft, then either the body handling RFC is broken, >>> or we are going beyond the scope of something that should >> be generic. >>> 2) If an info-package has need of multiple data streams that are >>> somehow sent in the same INFO message, then that should be done at >>> the application level and not multiplexed at the SIP level. In my >>> view the multiple MIME bodies are more at the SIP level >> than at the >>> application level. There will always be some relationship >>> description between the two data streams that multipart >> MIME cannot >>> describe because it is application specific. >>> >>> So I would suggest we stick to the rules of: >>> >>> One body per INFO message. >> We have described use cases where a multipart body per INFO is >> required, because the INFO payload itself has multiple parts defined >> by the package. For example, a location body(or link) and an image >> body(or link) for geotagged imagery. >> >>> One Info-package per INFO message. >>> >> We agree there. >> >>> The one body in potential multipart must be clearly labelled as >>> belonging to the Info-package. Other bodies in multipart bodies >>> belong to other dialog usages. I can envisage an entity that works >>> under the rule - everytime you send a message include a >> Geolocation >>> and associated body. >> I mostly agree, but instead believe that there must be a singular >> object that is marked as info-package, and that it may have sub- >> components with other markings that are marked for other >> dispositions >> but are still part of the package specification's payload. This >> container might be related, alternative, or any other multiplicative >> MIME structure. >> >> In other words, it's a tree, and everything below the C-D "info- >> package" node on the tree is party of the info-package payload. >> >> -- >> Dean >> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Oct 28 06:39:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6BB3A6802 for ; Wed, 28 Oct 2009 06:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4q7EqB-QJr9 for ; Wed, 28 Oct 2009 06:39:01 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3B2D63A6893 for ; Wed, 28 Oct 2009 06:39:01 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-df-4ae84983c2d9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id AE.9B.31706.38948EA4; Wed, 28 Oct 2009 14:39:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:38:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 14:37:46 +0100 Message-ID: In-Reply-To: <4AE848B1.30208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording thread-index: AcpX05M8F9d3ka2sTIyXUCenqGdM6wAACzIw References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com><7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> <4AE848B1.30208@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Elwell, John" X-OriginalArrivalTime: 28 Oct 2009 13:38:08.0303 (UTC) FILETIME=[E27CDBF0:01CA57D3] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , SIPCORE , Gonzalo Camarillo , draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:39:02 -0000 The opera ain't over until we've got an RFC number :)=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 28. lokakuuta 2009 15:36 > To: Elwell, John > Cc: Adam Roach;=20 > draft-ietf-sipcore-info-events@tools.ietf.org; SIPCORE;=20 > Gonzalo Camarillo > Subject: Re: [sipcore] WGLC comments=20 > (draft-ietf-sipcore-info-events-01) - John E's comments -=20 > receive Info-Package wording >=20 > YES! >=20 > Elwell, John wrote: > > Yes, I think Dean, Paul and myself are all arguing to keep=20 > it simple. One Info-Package per INFO message (that was agreed=20 > a long time ago), one body part per Info-Package with C-D=20 > Info-Package. What type of body part is left to the Info=20 > Package definition and could be multipart, in which case the=20 > child body parts would also be defined as part of the Info=20 > Package, not in this spec. The less we say about what happens=20 > within the Info Package body part, the better. Finally, the=20 > single Info-Package body part can be carried with other body=20 > parts within a multi-part body part. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> Sent: 28 October 2009 00:47 > >> To: DRAGE, Keith (Keith) > >> Cc: Christer Holmberg; Elwell, John; SIPCORE; Adam Roach; Gonzalo=20 > >> Camarillo; draft-ietf-sipcore-info-events@tools.ietf.org > >> Subject: Re: [sipcore] WGLC comments > >> (draft-ietf-sipcore-info-events-01) - John E's comments - receive=20 > >> Info-Package wording > >> > >> > >> On Oct 27, 2009, at 7:37 PM, DRAGE, Keith (Keith) wrote: > >> > >>> Is it just me, or are we making this all way more=20 > complicated that=20 > >>> it should be. > >>> > >>> Let us start from two principles. > >>> > >>> 1) If we find ourselves trying to describe body handling=20 > >> issues in > >>> the info-event draft, then either the body handling RFC=20 > is broken,=20 > >>> or we are going beyond the scope of something that should > >> be generic. > >>> 2) If an info-package has need of multiple data=20 > streams that are =20 > >>> somehow sent in the same INFO message, then that should=20 > be done at=20 > >>> the application level and not multiplexed at the SIP level. In my=20 > >>> view the multiple MIME bodies are more at the SIP level > >> than at the > >>> application level. There will always be some relationship=20 > >>> description between the two data streams that multipart > >> MIME cannot > >>> describe because it is application specific. > >>> > >>> So I would suggest we stick to the rules of: > >>> > >>> One body per INFO message. > >> We have described use cases where a multipart body per INFO is=20 > >> required, because the INFO payload itself has multiple=20 > parts defined=20 > >> by the package. For example, a location body(or link) and an image=20 > >> body(or link) for geotagged imagery. > >> > >>> One Info-package per INFO message. > >>> > >> We agree there. > >> > >>> The one body in potential multipart must be clearly labelled as=20 > >>> belonging to the Info-package. Other bodies in multipart bodies=20 > >>> belong to other dialog usages. I can envisage an entity=20 > that works=20 > >>> under the rule - everytime you send a message include a > >> Geolocation > >>> and associated body. > >> I mostly agree, but instead believe that there must be a singular=20 > >> object that is marked as info-package, and that it may have sub-=20 > >> components with other markings that are marked for other=20 > dispositions=20 > >> but are still part of the package specification's payload. This=20 > >> container might be related, alternative, or any other=20 > multiplicative=20 > >> MIME structure. > >> > >> In other words, it's a tree, and everything below the C-D "info-=20 > >> package" node on the tree is party of the info-package payload. > >> > >> -- > >> Dean > >> > >> > >> > > _______________________________________________ > > 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 >=20 From christer.holmberg@ericsson.com Wed Oct 28 14:16:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550A428C158 for ; Wed, 28 Oct 2009 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYXZfLbRfl-A for ; Wed, 28 Oct 2009 14:16:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0009028C1CB for ; Wed, 28 Oct 2009 14:16:09 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-90-4ae8b4a7b12a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E9.33.04191.7A4B8EA4; Wed, 28 Oct 2009 22:16:23 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 22:16:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5812.F64940A9" Date: Wed, 28 Oct 2009 22:09:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYEvYzmFrCUV8cQDyEpYFtJpTBUQ== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 28 Oct 2009 21:16:23.0599 (UTC) FILETIME=[E6F613F0:01CA5813] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:16:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5812.F64940A9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I would like to point out the following WGLC comment provided by Keith. ------------------ "7.3. Dialog Fate Sharing As described in [RFC5057], an INFO request is always part of an INVITE dialog usage. One needs to consider the fate of the dialog usage of an INFO request is rejected. In some cases it may be acceptable that the whole dialog usage is terminated, while in other cases is is desirable to maintain the dialog usage. However as we have a specific new response code that represents a failure of the INFO method extension rather than any specific package, I believe the actions for 469 in respect of the dialog usage=20 should be defined in this document." ------------------ Personally I agree with Keith - the fate of the dialog should not depend on the package (and the SIP stack should not need to know package specific behavior). So, we should, in the main part of the spec talking about INFO responses, specify whether 469 terminates the invite dialog usage, or just the transaction. I don't see a reason to terminte the whole invite dialog usage, because the 469 could come due to a race condition, when I've sent a re-INVITE with a new set of Info Packages, but the remote UA sent an INFO based on the old set before it received the re-INVITE.=20 But, I guess Robert can give some guidance. Regards, Christer ------_=_NextPart_001_01CA5812.F64940A9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Dialog Fate Sharing

Hi,

I would like to point out the following = WGLC comment provided by Keith.

------------------

"7.3.  Dialog Fate = Sharing

   As described in [RFC5057], = an INFO request is always part of an
   INVITE dialog = usage.

   One needs to consider the = fate of the dialog usage of an INFO request
   is rejected. In some = cases it may be acceptable that the whole
   dialog usage is = terminated, while in other cases is is desirable to
   maintain the dialog = usage.

However as we have a specific new = response code that represents a failure of the INFO method extension = rather than any specific package, I believe the actions for 469 in = respect of the dialog usage

should be defined in this = document."

------------------

Personally I agree with Keith - the = fate of the dialog should not depend on the package (and the SIP stack = should not need to know package specific behavior).

So, we should, in the main part of the = spec talking about INFO responses, specify whether 469 terminates the = invite dialog usage, or just the transaction.

I don't see a reason to terminte the = whole invite dialog usage, because the 469 could come due to a race = condition, when I've sent a re-INVITE with a new set of Info Packages, = but the remote UA sent an INFO based on the old set before it received = the re-INVITE.

But, I guess Robert can give some = guidance.

Regards,

Christer

------_=_NextPart_001_01CA5812.F64940A9-- From pkyzivat@cisco.com Wed Oct 28 14:35:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2AAF3A68C3 for ; Wed, 28 Oct 2009 14:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSEX-BMNa46K for ; Wed, 28 Oct 2009 14:35:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B489C3A6AA9 for ; Wed, 28 Oct 2009 14:35:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFtW6EqtJV2c/2dsb2JhbADCYZgrhD8E X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="65376870" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 21:35:53 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id n9SLZrQt005124; Wed, 28 Oct 2009 21:35:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:35:53 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:35:52 -0400 Message-ID: <4AE8B942.1090506@cisco.com> Date: Wed, 28 Oct 2009 17:36:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 21:35:52.0592 (UTC) FILETIME=[9FBC4100:01CA5816] Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:35:39 -0000 I don't think INFO should add any new dialog or usage failure cases. Errors that generically cause global failure, such as 408, should of course do so for INFO as well. But specific failures of INFO (legacy or with I-P) should only fail the transaction. If in a particular case an application wants to consider some result of and INFO to be fatal to the call it has ample means to cause that to happen. Thanks, Paul Christer Holmberg wrote: > > Hi, > > I would like to point out the following WGLC comment provided by Keith. > > ------------------ > > "7.3. Dialog Fate Sharing > > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. > > One needs to consider the fate of the dialog usage of an INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > However as we have a specific new response code that represents a > failure of the INFO method extension rather than any specific package, I > believe the actions for 469 in respect of the dialog usage > > should be defined in this document." > > ------------------ > > Personally I agree with Keith - the fate of the dialog should not depend > on the package (and the SIP stack should not need to know package > specific behavior). > > So, we should, in the main part of the spec talking about INFO > responses, specify whether 469 terminates the invite dialog usage, or > just the transaction. > > I don't see a reason to terminte the whole invite dialog usage, because > the 469 could come due to a race condition, when I've sent a re-INVITE > with a new set of Info Packages, but the remote UA sent an INFO based on > the old set before it received the re-INVITE. > > But, I guess Robert can give some guidance. > > Regards, > > Christer > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Oct 28 14:49:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE76028C133 for ; Wed, 28 Oct 2009 14:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaSrar09ENwR for ; Wed, 28 Oct 2009 14:49:26 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 818523A69A0 for ; Wed, 28 Oct 2009 14:49:25 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-5b-4ae8bc732af1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 50.5E.31706.37CB8EA4; Wed, 28 Oct 2009 22:49:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 22:49:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5818.7178FD2D" Date: Wed, 28 Oct 2009 22:48:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Info-Event Open Issue: Header field parameter re-use thread-index: AcpYGHFg8RT3KAAMRRytbLuLYsrltg== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 28 Oct 2009 21:49:39.0589 (UTC) FILETIME=[8CA9FB50:01CA5818] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:49:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5818.7178FD2D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Another issue which came to my mind when going through Keith's comment. Currently we say that Info Package parameters can only be used with the package for which it was defined. But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer to parameter defined for other Info Packages? NOTE that I am NOT saying that Info Packages should be allowed to use other parameters just like that - the I-P specifications must still indicate (either by defining or refering to) which parameters are allowed for that I-P. Comments? Regards, Christer ------_=_NextPart_001_01CA5818.7178FD2D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Header field parameter re-use

Hi,

Another issue which came to my mind = when going through Keith's comment.

Currently we say that Info Package = parameters can only be used with the package for which it was = defined.

But, what if another Info Package needs = a parameter with exactly the same semantics? Even if that other Info = Package would use the same parameter name, it would still have to = re-define the parameter.

So, the question is: should we allow = Info Package specifications to refer to parameter defined for other Info = Packages?


NOTE that I am NOT saying that Info = Packages should be allowed to use other parameters just like that - the = I-P specifications must still indicate (either by defining or refering = to) which parameters are allowed for that I-P.

Comments?

Regards,

Christer

------_=_NextPart_001_01CA5818.7178FD2D-- From dean.willis@softarmor.com Wed Oct 28 15:53:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA4A3A6A59 for ; Wed, 28 Oct 2009 15:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2X0hywfPm9o for ; Wed, 28 Oct 2009 15:53:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6777F3A6A58 for ; Wed, 28 Oct 2009 15:53:47 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SMrvS1030632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 17:53:58 -0500 Message-ID: <4AE8CB8F.8060805@softarmor.com> Date: Wed, 28 Oct 2009 17:54:07 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:53:48 -0000 Christer Holmberg wrote: > Hi Keith, > > So, I guess we somewhere would need text saying that UAs that *only* > support legacy INFO usages are not mandated to use the Recv-Info header? Isn't that sort of like saying "Nodes not supporting this specification are not required to do anything this specification says"? seems more than pointless to me. -- Dean From dean.willis@softarmor.com Wed Oct 28 15:54:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F3B28C236 for ; Wed, 28 Oct 2009 15:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNsqPAbAxxU0 for ; Wed, 28 Oct 2009 15:54:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0E9A43A6844 for ; Wed, 28 Oct 2009 15:54:58 -0700 (PDT) Received: from [192.168.2.104] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SMsgPj030651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 17:54:43 -0500 Message-ID: <4AE8CBBC.1080905@softarmor.com> Date: Wed, 28 Oct 2009 17:54:52 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" References: <7402509E63C5A145A6095D46C179A5B71477E0CA@DEMCHP99E35MSX.ww902.siemens.net> <7402509E63C5A145A6095D46C179A5B7148B2BC0@DEMCHP99E35MSX.ww902.siemens.net> <56C2FBF5-ECD1-4B05-9107-BA67E7299041@softarmor.com> <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B363E@DEMCHP99E35MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , "draft-ietf-sipcore-info-events@tools.ietf.org" , SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] WGLC comments (draft-ietf-sipcore-info-events-01) - John E's comments - receive Info-Package wording X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:54:58 -0000 Elwell, John wrote: > Yes, I think Dean, Paul and myself are all arguing to keep it simple. > One Info-Package per INFO message (that was agreed a long time ago), > one body part per Info-Package with C-D Info-Package. What type of > body part is left to the Info Package definition and could be > multipart, in which case the child body parts would also be defined > as part of the Info Package, not in this spec. The less we say about > what happens within the Info Package body part, the better. Finally, > the single Info-Package body part can be carried with other body > parts within a multi-part body part. Yes. -- Dean From pkyzivat@cisco.com Wed Oct 28 16:14:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB54E3A67FC for ; Wed, 28 Oct 2009 16:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF4-+5sJdLEz for ; Wed, 28 Oct 2009 16:14:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D62013A677C for ; Wed, 28 Oct 2009 16:14:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMpt6EpAZnwM/2dsb2JhbADDCZgYhD8E X-IronPort-AV: E=Sophos;i="4.44,642,1249257600"; d="scan'208";a="65388668" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 23:14:24 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SNEOmJ004857; Wed, 28 Oct 2009 23:14:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 19:14:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 19:14:24 -0400 Message-ID: <4AE8D055.7010007@cisco.com> Date: Wed, 28 Oct 2009 19:14:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4AE8CB8F.8060805@softarmor.com> In-Reply-To: <4AE8CB8F.8060805@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2009 23:14:24.0387 (UTC) FILETIME=[63709530:01CA5824] Cc: draft-ietf-sipcore-info-events@tools.ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 23:14:24 -0000 Dean Willis wrote: > Christer Holmberg wrote: >> Hi Keith, >> >> So, I guess we somewhere would need text saying that UAs that *only* >> support legacy INFO usages are not mandated to use the Recv-Info header? > > Isn't that sort of like saying "Nodes not supporting this specification > are not required to do anything this specification says"? > > seems more than pointless to me. No, its not like that. This specification is *replacing* RFC 2976. So this document *is* the specification of legacy behavior as well as the new IP behavior. Thanks, Paul From dean.willis@softarmor.com Wed Oct 28 19:18:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962C33A69C8 for ; Wed, 28 Oct 2009 19:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XbVHUNDWv-v for ; Wed, 28 Oct 2009 19:18:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D0D533A6938 for ; Wed, 28 Oct 2009 19:18:54 -0700 (PDT) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9T2J5fx031768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 21:19:06 -0500 Message-Id: <63E673E5-5BF2-4A21-9EA4-EE8BBF6A215A@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4AE8D055.7010007@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 21:18:59 -0500 References: <4AE8CB8F.8060805@softarmor.com> <4AE8D055.7010007@cisco.com> X-Mailer: Apple Mail (2.936) Cc: draft-ietf-sipcore-info-events@tools.ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 02:18:55 -0000 On Oct 28, 2009, at 6:14 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> Christer Holmberg wrote: >>> Hi Keith, >>> >>> So, I guess we somewhere would need text saying that UAs that *only* >>> support legacy INFO usages are not mandated to use the Recv-Info >>> header? >> Isn't that sort of like saying "Nodes not supporting this >> specification are not required to do anything this specification >> says"? >> seems more than pointless to me. > > No, its not like that. > > This specification is *replacing* RFC 2976. > So this document *is* the specification of legacy behavior as well > as the new IP behavior. > Ah well, in that case, yes, we need it to say that. -- Dean From Martin.Thomson@andrew.com Wed Oct 28 22:23:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF463A69E5; Wed, 28 Oct 2009 22:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqkaCAbiYwrt; Wed, 28 Oct 2009 22:23:44 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 97DCE3A683B; Wed, 28 Oct 2009 22:23:35 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:14551 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S70459AbZJ2FXe (ORCPT + 1 other); Thu, 29 Oct 2009 00:23:34 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 00:23:34 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 29 Oct 2009 13:20:07 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Miguel A. Garcia" Date: Thu, 29 Oct 2009 13:20:32 +0800 Thread-Topic: draft-garcia-geopriv-indirect-publish Thread-Index: AcpXMgkw+P+UwJ2sTT6ZXQpCLuqBSABI7vEw Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 05:23:47 -0000 SGkgSmFtZXMsDQoNCj4gVGhpcyB0bywgY2FuIGJlIGFkZGVkIHRvIFNJUCBMb2NhdGlvbiBDb252 ZXlhbmNlIChpZiB0aGUgU0lQQ09SRSBXRw0KPiBhZ3JlZXMgd2l0aCB0aGlzIGFkZGl0aW9uKS4N Cg0KQXNpZGUgZnJvbSBhIHZlcnkgc3Ryb25nIGRlc2lyZSB0byBzZWUgdGhlIGVuZCBvZiBTSVAg bG9jYXRpb24gY29udmV5YW5jZSwgYWxsIHRoZSBhdXRob3JzIG9uIHRoaXMgZG9jdW1lbnQgYXJl IGluIHN0cm9uZyBhZ3JlZW1lbnQgdGhhdCBhIGxvY2F0aW9uLXNwZWNpZmljIHNvbHV0aW9uIGlz IG5vdCBkZXNpcmFibGUuDQoNCj4gQW5kIHdoZW4geW91IHJlYWNoIGNvbnNlbnN1cyBvbiB0aGUg cmVxdWlyZW1lbnQgdG8gc2VuZCBhIHdhdGNoZXIgdGhlDQo+IGxvY2F0aW9uIFVSSSBpbnN0ZWFk IG9mIGEgbG9jYXRpb24gdmFsdWUsIHRoYXQgd2lsbCBuZWVkIHRvIGJlDQo+IGluZGljYXRlZCB3 aXRoIGZ1cnRoZXIgd29yay4NCg0KVGhpcyBpcyBzZW5zaWJsZS4gIEkgdGVuZCB0byBhZ3JlZSB0 aGF0IHdlIHdhbnQgdG8gaGF2ZSB0aGUgcHJlc2VuY2UgYWdlbnQgYWJsZSB0byBkbyB0aGUgZGVy ZWZlcmVuY2UuICBJbiBtYW55IGNhc2VzLCB0aGUgd2F0Y2hlciB3b250IGJlIGludGVyZXN0ZWQg aW4gZG9pbmcgdGhpcyB0aGVtc2VsdmVzLiAgVGhpcyBpcyBqdXN0IG9uZSBhc3BlY3Qgd2UgbmVl ZCB0byBjb25zaWRlciBpbiB0aGUgc29sdXRpb24uDQoNCkZvciBpbnN0YW5jZSwgaWYgd2UgZXh0 ZW5kIFBJREYsIGEgcHJlc2VuY2UgYWdlbnQgdGhhdCBkb2Vzbid0IHN1cHBvcnQgdGhlIGV4dGVu c2lvbiB3b3VsZCBwYXNzIHRoZSByZWZlcmVuY2Ugb253YXJkIHVuYXdhcmUgb2YgaXRzIHNwZWNp YWwgc3RhdHVzLiAgVGhhdCBtaWdodCBiZSBhIGRlc2lyYWJsZSBhdHRyaWJ1dGUgb2YgYSBzb2x1 dGlvbi4gIEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIHByb3ZpZGUgYSBkaWZmZXJlbnQgYm9keS4N Cg0KTWlndWVsIGFuZCBJIGFyZSBjdXJyZW50bHkgZGViYXRpbmcgb3B0aW9ucy4gIFdlJ3JlIHN0 aWxsIHRyeWluZyB0byBjb21lIHRvIGEgY29tbW9uIHVuZGVyc3RhbmRpbmcgb24gdGhpcyBwb2lu dC4gIEFib3V0IGFsbCB3ZSBhZ3JlZSBvbiByaWdodCBub3cgaXMgdGhhdCB0aGlzIHJlZmVyZW5j ZSB3aWxsIHNpdCBpbiB0aGUgYm9keSBvZiB0aGUgU0lQIFBVQkxJU0ggYW5kIHRoYXQgaXQgd2ls bCBub3QgYmUgbG9jYXRpb24tc3BlY2lmaWMuICBUaGVzZSBhcmUgYm90aCByZWFzb25zIGFnYWlu c3QgdXNpbmcgR2VvbG9jYXRpb24sIHdoaWNoIGlzIHVuZm9ydHVuYXRlIGluIGEgd2F5IGJlY2F1 c2UgaXQgaGFzIGEgbG90IG9mIHRoZSBzZW1hbnRpY3Mgd2UncmUgbG9va2luZyBmb3IuDQoNCk9u Y2Ugd2UndmUgc29ydGVkIG91dCB0aGUgYmFzaWNzLCBtYXliZSB3ZSBjYW4gc2VlIGhvdyB0aGUg R2VvbG9jYXRpb24gaGVhZGVyIGZpdHMuDQogDQo+IEFzIHN0YXRlZCBhYm92ZSwgSSBiZWxpZXZl IHlvdSBhcmUgd2FudGluZyBhIGRlZmF1bHQgYWN0aW9uIGZvciB0aGUNCj4gUFMgdG8gZGVyZWZl cmVuY2UgDQoNCkFjdHVhbGx5LCBhcyBNaWd1ZWwgc2F5cywgdGhlIG9wdGlvbnMgYXJlIHN0aWxs IGxhcmdlbHkgb3Blbi4gIEJ1dCBJIGNlcnRhaW5seSB0aGluayB0aGF0IGhhdmluZyB0aGUgcHJl c2VuY2UgYWdlbnQgYWJsZSB0byBkZXJlZmVyZW5jZSBpcyBhIGRlc2lyYWJsZSBmZWF0dXJlLiAg VGhpcyBtaWdodCBiZTogYWx3YXlzIGRlcmVmZXJlbmNlLCBkZXJlZmVyZW5jZSBiYXNlZCBvbiBw cmVzZW5jZSBhZ2VudCBwb2xpY3ksIGRlcmVmZXJlbmNlIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBw cmVzZW50aXR5LCBvciBhIGNvbWJpbmF0aW9uIG9mIHRoZXNlLg0KDQotLU1hcnRpbg0KDQo+IA0K PiBKYW1lcw0KPiANCj4gDQo+IA0KPiANCj4gPi9NaWd1ZWwNCj4gPg0KPiA+LS0NCj4gPk1pZ3Vl bCBBLiBHYXJjaWENCj4gPiszNC05MS0zMzktMzYwOA0KPiA+RXJpY3Nzb24gU3BhaW4NCj4gDQoN Cg== From sanjsinh@cisco.com Wed Oct 28 23:56:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BCB3A685A for ; Wed, 28 Oct 2009 23:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rrYW3g6eW6O for ; Wed, 28 Oct 2009 23:56:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 61A4C3A6973 for ; Wed, 28 Oct 2009 23:56:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANfZ6EpAZnwM/2dsb2JhbADDRJgShD8E X-IronPort-AV: E=Sophos;i="4.44,644,1249257600"; d="scan'208";a="65466933" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 06:57:09 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T6v9HU028046; Thu, 29 Oct 2009 06:57:09 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 02:57:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 02:57:07 -0400 Message-ID: In-Reply-To: <4AE8B942.1090506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLeg References: <4AE8B942.1090506@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: "Paul Kyzivat (pkyzivat)" , "Christer Holmberg" X-OriginalArrivalTime: 29 Oct 2009 06:57:09.0840 (UTC) FILETIME=[08F07D00:01CA5865] Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 06:56:55 -0000 I agree.=20 If the INFO transaction fails, then let the application decide whether it wants to continue with the dialog or not? Sanjay -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, October 29, 2009 3:06 AM To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing I don't think INFO should add any new dialog or usage failure cases. Errors that generically cause global failure, such as 408, should of=20 course do so for INFO as well. But specific failures of INFO (legacy or=20 with I-P) should only fail the transaction. If in a particular case an application wants to consider some result of=20 and INFO to be fatal to the call it has ample means to cause that to happen. Thanks, Paul Christer Holmberg wrote: >=20 > Hi, >=20 > I would like to point out the following WGLC comment provided by Keith. >=20 > ------------------ >=20 > "7.3. Dialog Fate Sharing >=20 > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. >=20 > One needs to consider the fate of the dialog usage of an INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. >=20 > However as we have a specific new response code that represents a=20 > failure of the INFO method extension rather than any specific package, I=20 > believe the actions for 469 in respect of the dialog usage >=20 > should be defined in this document." >=20 > ------------------ >=20 > Personally I agree with Keith - the fate of the dialog should not depend=20 > on the package (and the SIP stack should not need to know package=20 > specific behavior). >=20 > So, we should, in the main part of the spec talking about INFO=20 > responses, specify whether 469 terminates the invite dialog usage, or=20 > just the transaction. >=20 > I don't see a reason to terminte the whole invite dialog usage, because=20 > the 469 could come due to a race condition, when I've sent a re-INVITE > with a new set of Info Packages, but the remote UA sent an INFO based on=20 > the old set before it received the re-INVITE. >=20 > But, I guess Robert can give some guidance. >=20 > Regards, >=20 > Christer >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > 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 sanjsinh@cisco.com Thu Oct 29 00:11:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED20C3A69DE for ; Thu, 29 Oct 2009 00:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8pEkyj8WwCM for ; Thu, 29 Oct 2009 00:11:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B76893A68BB for ; Thu, 29 Oct 2009 00:11:51 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAB7d6EpAZnwM/2dsb2JhbACCJyvBApgShD8E X-IronPort-AV: E=Sophos;i="4.44,644,1249257600"; d="scan'208,217";a="65430670" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Oct 2009 07:12:06 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T7C61N003516; Thu, 29 Oct 2009 07:12:06 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 03:12:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5867.1F4739A9" Date: Thu, 29 Oct 2009 03:12:05 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Header field parameter re-use Thread-Index: AcpYGHFg8RT3KAAMRRytbLuLYsrltgATLjDA References: From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "SIPCORE" X-OriginalArrivalTime: 29 Oct 2009 07:12:06.0673 (UTC) FILETIME=[1F7E5810:01CA5867] Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:11:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5867.1F4739A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think parameter name in context of the Info package should provide enough meaning to distinguish it from same parameter name use in another package. So it should be allowed. =20 Sanjay =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, October 29, 2009 3:19 AM To: SIPCORE Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use =20 =20 Hi,=20 Another issue which came to my mind when going through Keith's comment.=20 Currently we say that Info Package parameters can only be used with the package for which it was defined.=20 But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer to parameter defined for other Info Packages?=20 =20 NOTE that I am NOT saying that Info Packages should be allowed to use other parameters just like that - the I-P specifications must still indicate (either by defining or refering to) which parameters are allowed for that I-P. Comments?=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA5867.1F4739A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Header field parameter re-use

I think parameter name in context of the Info package = should provide enough meaning to distinguish it from  same parameter name use in = another package. So it should be allowed.

 

Sanjay

 

From:= sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg
Sent: Thursday, October 29, 2009 3:19 AM
To: SIPCORE
Subject: [sipcore] Info-Event Open Issue: Header field parameter = re-use

 

 

Hi, =

Another issue which came to my mind when going through Keith's comment. =

Currently we say that Info Package parameters can only be used with the package for = which it was defined.

But, what if another Info Package needs a parameter with exactly the same semantics? = Even if that other Info Package would use the same parameter name, it would = still have to re-define the parameter.

So, = the question is: should we allow Info Package specifications to refer to = parameter defined for other Info Packages?

 

NOTE that I am NOT saying that Info Packages should be allowed to use other = parameters just like that - the I-P specifications must still indicate (either by = defining or refering to) which parameters are allowed for that = I-P.

Comments?

Regards,

Christer

------_=_NextPart_001_01CA5867.1F4739A9-- From christer.holmberg@ericsson.com Thu Oct 29 00:41:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA3C3A6884 for ; Thu, 29 Oct 2009 00:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RePOpYaxI2RM for ; Thu, 29 Oct 2009 00:41:15 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C76283A67B1 for ; Thu, 29 Oct 2009 00:41:14 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-8b-4ae94728af48 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id E1.F0.31706.82749EA4; Thu, 29 Oct 2009 08:41:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 08:40:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 08:38:23 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-info-events-02 thread-index: AcpYIYuKedrI9zm8Rlq6uuGPNd20/QAST/qy References: <4AE8CB8F.8060805@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 29 Oct 2009 07:40:52.0533 (UTC) FILETIME=[242FAE50:01CA586B] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:41:16 -0000 Hi, =20 >>So, I guess we somewhere would need text saying that UAs that *only* >>support legacy INFO usages are not mandated to use the Recv-Info = header? > >Isn't that sort of like saying "Nodes not supporting this specification >are not required to do anything this specification says"? No. The draft also specifies legacy INFO usage.=20 There were WGLC comments that we should make that more clear, instead of = simply refering to the RFC for legacy procedures. Regards, Christer =20 From christer.holmberg@ericsson.com Thu Oct 29 00:45:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83863A68BB for ; Thu, 29 Oct 2009 00:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg6fJGd2xdwM for ; Thu, 29 Oct 2009 00:45:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6BF3D28B23E for ; Thu, 29 Oct 2009 00:45:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-f1-4ae948186a3c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 41.38.04191.81849EA4; Thu, 29 Oct 2009 08:45:28 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 08:43:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 08:41:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQ= References: <4AE8B942.1090506@cisco.com> From: "Christer Holmberg" To: "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 29 Oct 2009 07:43:56.0283 (UTC) FILETIME=[91B5B4B0:01CA586B] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 07:45:23 -0000 Hi, =20 So, do people think we should keep the existing text (section 7.3), = which talks about the dialog fate? =20 Regards. =20 Christer ________________________________ From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] Sent: Thu 10/29/2009 7:57 AM To: Paul Kyzivat (pkyzivat); Christer Holmberg Cc: SIPCORE Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing I agree. If the INFO transaction fails, then let the application decide whether it wants to continue with the dialog or not? Sanjay -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, October 29, 2009 3:06 AM To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing I don't think INFO should add any new dialog or usage failure cases. Errors that generically cause global failure, such as 408, should of course do so for INFO as well. But specific failures of INFO (legacy or with I-P) should only fail the transaction. If in a particular case an application wants to consider some result of and INFO to be fatal to the call it has ample means to cause that to happen. Thanks, Paul Christer Holmberg wrote: > > Hi, > > I would like to point out the following WGLC comment provided by Keith. > > ------------------ > > "7.3. Dialog Fate Sharing > > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. > > One needs to consider the fate of the dialog usage of an INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > However as we have a specific new response code that represents a > failure of the INFO method extension rather than any specific package, I > believe the actions for 469 in respect of the dialog usage > > should be defined in this document." > > ------------------ > > Personally I agree with Keith - the fate of the dialog should not depend > on the package (and the SIP stack should not need to know package > specific behavior). > > So, we should, in the main part of the spec talking about INFO > responses, specify whether 469 terminates the invite dialog usage, or > just the transaction. > > I don't see a reason to terminte the whole invite dialog usage, because > the 469 could come due to a race condition, when I've sent a re-INVITE > with a new set of Info Packages, but the remote UA sent an INFO based on > the old set before it received the re-INVITE. > > But, I guess Robert can give some guidance. > > 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 christer.holmberg@ericsson.com Thu Oct 29 01:01:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAAF3A67E9 for ; Thu, 29 Oct 2009 01:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl2qfpDLDimS for ; Thu, 29 Oct 2009 01:01:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5C3543A6403 for ; Thu, 29 Oct 2009 01:01:01 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-59-4ae94bcbff96 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0A.29.04191.BCB49EA4; Thu, 29 Oct 2009 09:01:15 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:01:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 08:57:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: AcpYbX5IWBYQjtn3QL6DGTrCTkFCng== From: "Christer Holmberg" To: X-OriginalArrivalTime: 29 Oct 2009 08:01:14.0946 (UTC) FILETIME=[FCCD1A20:01CA586D] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 08:01:02 -0000 Hi, =20 I have got WGLC comments from different people regarding the request = methods in which we allow the Recv-Info header field.=20 =20 It IS related to something we have discussed before, but I want to point = it out, to make sure we can agree on a view. =20 1) REF and SUB ------------------------ =20 There has been some comments and question about whether we should allow = the R-I header field in REF and SUB. =20 Now, both REF and SUB are target refresh requests, and CAN be sent = within an invite dialog usage. However, I assume the dialog-usage RFC = recommends against doing so. =20 =20 2) ACK and PRA ------------------------- =20 Keith suggested we shouldn't allow the header in ACK and PRA either. =20 Personally I would not like to make that restriction at this point, = unless there is a good technical reason, but I would like to hear what = other people think. =20 =20 3) "offer/answer" ----------------------- =20 The draft currently does not define o/a type-of rules when UAs are to = indicate their Info Package set (using the Recv-Info header field). =20 Personally I don't think we need to define a "o/a" rules for Recv-Info. = We only need to indicate in which message the header field is allowed. =20 We could say that, when a UA receives the I-P set from the remote user, = it is recommend that it sends back its own set as soon as possible - if = the set has changed. =20 Because, if the set hasn't changed I don't think the UA needs to send = back anything, which means that whatever set it has sent before within = that dialog is still valid. That is the biggest difference compared to = o/a, which always requires the receiver to send its SDP back - even if = nothing has changed. =20 =20 Regards, =20 Christer =20 =20 From miguel.a.garcia@ericsson.com Thu Oct 29 01:37:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD35F3A681C; Thu, 29 Oct 2009 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLipFSGuBmvI; Thu, 29 Oct 2009 01:37:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5F5853A63EB; Thu, 29 Oct 2009 01:36:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-ed-4ae9542b1851 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4D.85.24026.B2459EA4; Thu, 29 Oct 2009 09:37:01 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:36:37 +0100 Received: from [159.107.25.142] ([159.107.25.142]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:36:36 +0100 Message-ID: <4AE95413.2030309@ericsson.com> Date: Thu, 29 Oct 2009 09:36:35 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: "James M. Polk" References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 08:36:36.0611 (UTC) FILETIME=[ED697D30:01CA5872] X-Brightmail-Tracker: AAAAAA== Cc: geopriv@ietf.org, sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 08:37:00 -0000 On 27/10/2009 19:19, James M. Polk wrote: > Why not have the following rule cover what you want > > the recommended policy be to dereference any location URI > received in a Geolocation header-value (in a PUBLISH) from > a presentity, to give to authorized watchers. > I think this the text around the policy is quite reasonable and according to our expectations. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From john.elwell@siemens-enterprise.com Thu Oct 29 03:05:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2968E3A68A9 for ; Thu, 29 Oct 2009 03:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbnxz29so8P5 for ; Thu, 29 Oct 2009 03:05:15 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id C52E63A6819 for ; Thu, 29 Oct 2009 03:05:14 -0700 (PDT) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n9TA5O5J031027; Thu, 29 Oct 2009 11:05:24 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9TA5OYA012753; Thu, 29 Oct 2009 11:05:24 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 29 Oct 2009 11:05:24 +0100 From: "Elwell, John" To: Christer Holmberg , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 29 Oct 2009 11:05:20 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38A== Message-ID: <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> References: <4AE8B942.1090506@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:05:16 -0000 Christer, This is in the section on Info Package considerations. I rather doubt there= is anything you need to specify on this topic when defining an Info-Packag= e. All Info-Packages should be subject to the same rules: i.e., depending o= n the particular error response to an INFO request, the dialog usage will e= ither remain or be terminated. If we need to say anything more on this matt= er (e.g., the impact of 469), that should be covered elsewhere in the docum= ent. I don't think we need 7.3. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 29 October 2009 07:42 > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Hi, > =20 > So, do people think we should keep the existing text (section=20 > 7.3), which talks about the dialog fate? > =20 > Regards. > =20 > Christer >=20 > ________________________________ >=20 > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Thu 10/29/2009 7:57 AM > To: Paul Kyzivat (pkyzivat); Christer Holmberg > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 >=20 > I agree. >=20 > If the INFO transaction fails, then let the application decide whether > it wants to continue with the dialog or not? >=20 > Sanjay >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat (pkyzivat) > Sent: Thursday, October 29, 2009 3:06 AM > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > I don't think INFO should add any new dialog or usage failure cases. > Errors that generically cause global failure, such as 408, should of > course do so for INFO as well. But specific failures of INFO=20 > (legacy or > with I-P) should only fail the transaction. >=20 > If in a particular case an application wants to consider some=20 > result of > and INFO to be fatal to the call it has ample means to cause that to > happen. >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > > > > Hi, > > > > I would like to point out the following WGLC comment provided by > Keith. > > > > ------------------ > > > > "7.3. Dialog Fate Sharing > > > > As described in [RFC5057], an INFO request is always part of an > > INVITE dialog usage. > > > > One needs to consider the fate of the dialog usage of an INFO > request > > is rejected. In some cases it may be acceptable that the whole > > dialog usage is terminated, while in other cases is is=20 > desirable to > > maintain the dialog usage. > > > > However as we have a specific new response code that represents a > > failure of the INFO method extension rather than any=20 > specific package, > I > > believe the actions for 469 in respect of the dialog usage > > > > should be defined in this document." > > > > ------------------ > > > > Personally I agree with Keith - the fate of the dialog should not > depend > > on the package (and the SIP stack should not need to know package > > specific behavior). > > > > So, we should, in the main part of the spec talking about INFO > > responses, specify whether 469 terminates the invite dialog=20 > usage, or > > just the transaction. > > > > I don't see a reason to terminte the whole invite dialog usage, > because > > the 469 could come due to a race condition, when I've sent=20 > a re-INVITE >=20 > > with a new set of Info Packages, but the remote UA sent an=20 > INFO based > on > > the old set before it received the re-INVITE. > > > > But, I guess Robert can give some guidance. > > > > 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 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Thu Oct 29 03:23:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256773A6997 for ; Thu, 29 Oct 2009 03:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMiPWsU7IKBd for ; Thu, 29 Oct 2009 03:23:14 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by core3.amsl.com (Postfix) with ESMTP id F19E73A6855 for ; Thu, 29 Oct 2009 03:23:13 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9TANRPx014036; Thu, 29 Oct 2009 11:23:27 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) by mail3.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n9TANRAR028663; Thu, 29 Oct 2009 11:23:27 +0100 Received: from DEMCHP99E35MSX.ww902.siemens.net ([169.254.2.61]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Thu, 29 Oct 2009 11:23:27 +0100 From: "Elwell, John" To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 29 Oct 2009 11:23:23 +0100 Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info Thread-Index: AcpYbX5IWBYQjtn3QL6DGTrCTkFCngAE8dRw Message-ID: <7402509E63C5A145A6095D46C179A5B7148B383C@DEMCHP99E35MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:23:18 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 29 October 2009 07:58 > To: sipcore@ietf.org > Subject: [sipcore] Info Even Open Issue: Method types and=20 > offer/answer for Recv-Info >=20 > Hi, > =20 > I have got WGLC comments from different people regarding the=20 > request methods in which we allow the Recv-Info header field.=20 > =20 > It IS related to something we have discussed before, but I=20 > want to point it out, to make sure we can agree on a view. > =20 > 1) REF and SUB > ------------------------ > =20 > There has been some comments and question about whether we=20 > should allow the R-I header field in REF and SUB. > =20 > Now, both REF and SUB are target refresh requests, and CAN be=20 > sent within an invite dialog usage. However, I assume the=20 > dialog-usage RFC recommends against doing so. [JRE] I don't see any need for Recv-Info in REF and SUB. > =20 > =20 > 2) ACK and PRA > ------------------------- > =20 > Keith suggested we shouldn't allow the header in ACK and PRA either. > =20 > Personally I would not like to make that restriction at this=20 > point, unless there is a good technical reason, but I would=20 > like to hear what other people think. [JRE] I don't see a lot of need for Recv-Info in ACK and PRA, but I won't o= bject if we allow it. > =20 > =20 > 3) "offer/answer" > ----------------------- > =20 > The draft currently does not define o/a type-of rules when=20 > UAs are to indicate their Info Package set (using the=20 > Recv-Info header field). > =20 > Personally I don't think we need to define a "o/a" rules for=20 > Recv-Info. We only need to indicate in which message the=20 > header field is allowed. > =20 > We could say that, when a UA receives the I-P set from the=20 > remote user, it is recommend that it sends back its own set=20 > as soon as possible - if the set has changed. > =20 > Because, if the set hasn't changed I don't think the UA needs=20 > to send back anything, which means that whatever set it has=20 > sent before within that dialog is still valid. That is the=20 > biggest difference compared to o/a, which always requires the=20 > receiver to send its SDP back - even if nothing has changed. [JRE] I don't think we should tie the two directions together at all. A sid= e should only be required to send when it wants to advertise or when it wan= ts to change a former advertisement. John From drage@alcatel-lucent.com Thu Oct 29 03:23:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0267628C13C for ; Thu, 29 Oct 2009 03:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vE+2YN8oN-j for ; Thu, 29 Oct 2009 03:23:48 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 53B813A6A86 for ; Thu, 29 Oct 2009 03:23:48 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9TANw3a017861 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Oct 2009 11:23:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 29 Oct 2009 11:23:58 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Christer Holmberg , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 29 Oct 2009 11:23:56 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkw Message-ID: References: <4AE8B942.1090506@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> In-Reply-To: <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:23:50 -0000 To clarify on my original comment. Any specific text on receipt of 469 should go in the most appropriate secti= on, which is definitely not section 7 - I would suggest somewhere around se= ction 4.4, but not in 4.4 because this is all UAS functionality and we want= UAC functionality. With 469 we do not have a Info-Package, becuase the receiver was unable to = recognise one that was valid. If for example two had been previously negoti= ated with Recv-Info, it could be either of them, or indeed the unnegotiated= appearance of a third. That is why I think the issue is generic rather tha= n Info Package specific. I would confirm that I see no need to kill the dialog but merely the transa= ction. regards Keith =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, October 29, 2009 10:05 AM > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat=20 > (pkyzivat) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Christer, >=20 > This is in the section on Info Package considerations. I=20 > rather doubt there is anything you need to specify on this=20 > topic when defining an Info-Package. All Info-Packages should=20 > be subject to the same rules: i.e., depending on the=20 > particular error response to an INFO request, the dialog=20 > usage will either remain or be terminated. If we need to say=20 > anything more on this matter (e.g., the impact of 469), that=20 > should be covered elsewhere in the document. I don't think we=20 > need 7.3. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 29 October 2009 07:42 > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Hi, > > =20 > > So, do people think we should keep the existing text (section 7.3),=20 > > which talks about the dialog fate? > > =20 > > Regards. > > =20 > > Christer > >=20 > > ________________________________ > >=20 > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Sent: Thu 10/29/2009 7:57 AM > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > >=20 > > I agree. > >=20 > > If the INFO transaction fails, then let the application=20 > decide whether=20 > > it wants to continue with the dialog or not? > >=20 > > Sanjay > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Thursday, October 29, 2009 3:06 AM > > To: Christer Holmberg > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > I don't think INFO should add any new dialog or usage failure cases. > > Errors that generically cause global failure, such as 408,=20 > should of=20 > > course do so for INFO as well. But specific failures of=20 > INFO (legacy=20 > > or with I-P) should only fail the transaction. > >=20 > > If in a particular case an application wants to consider=20 > some result=20 > > of and INFO to be fatal to the call it has ample means to=20 > cause that=20 > > to happen. > >=20 > > Thanks, > > Paul > >=20 > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > I would like to point out the following WGLC comment provided by > > Keith. > > > > > > ------------------ > > > > > > "7.3. Dialog Fate Sharing > > > > > > As described in [RFC5057], an INFO request is always part of an > > > INVITE dialog usage. > > > > > > One needs to consider the fate of the dialog usage of an INFO > > request > > > is rejected. In some cases it may be acceptable that the whole > > > dialog usage is terminated, while in other cases is is > > desirable to > > > maintain the dialog usage. > > > > > > However as we have a specific new response code that represents a=20 > > > failure of the INFO method extension rather than any > > specific package, > > I > > > believe the actions for 469 in respect of the dialog usage > > > > > > should be defined in this document." > > > > > > ------------------ > > > > > > Personally I agree with Keith - the fate of the dialog should not > > depend > > > on the package (and the SIP stack should not need to know package=20 > > > specific behavior). > > > > > > So, we should, in the main part of the spec talking about INFO=20 > > > responses, specify whether 469 terminates the invite dialog > > usage, or > > > just the transaction. > > > > > > I don't see a reason to terminte the whole invite dialog usage, > > because > > > the 469 could come due to a race condition, when I've sent > > a re-INVITE > >=20 > > > with a new set of Info Packages, but the remote UA sent an > > INFO based > > on > > > the old set before it received the re-INVITE. > > > > > > But, I guess Robert can give some guidance. > > > > > > 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 > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From drage@alcatel-lucent.com Thu Oct 29 03:31:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C103A691B for ; Thu, 29 Oct 2009 03:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1ks6X1gGlZP for ; Thu, 29 Oct 2009 03:31:45 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CE4DB3A67EB for ; Thu, 29 Oct 2009 03:31:44 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9TAVBrl022915 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Oct 2009 11:31:48 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 29 Oct 2009 11:31:21 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 29 Oct 2009 11:31:19 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABeAngA== Message-ID: References: <4AE8B942.1090506@cisco.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 10:31:46 -0000 I had no problem with this text. I merely cited as some text that was relat= ed to my issue, but did not solve it. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, October 29, 2009 7:42 AM > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Hi, > =20 > So, do people think we should keep the existing text (section=20 > 7.3), which talks about the dialog fate? > =20 > Regards. > =20 > Christer >=20 > ________________________________ >=20 > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > Sent: Thu 10/29/2009 7:57 AM > To: Paul Kyzivat (pkyzivat); Christer Holmberg > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 >=20 > I agree. >=20 > If the INFO transaction fails, then let the application=20 > decide whether it wants to continue with the dialog or not? >=20 > Sanjay >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) > Sent: Thursday, October 29, 2009 3:06 AM > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > I don't think INFO should add any new dialog or usage failure cases. > Errors that generically cause global failure, such as 408,=20 > should of course do so for INFO as well. But specific=20 > failures of INFO (legacy or with I-P) should only fail the=20 > transaction. >=20 > If in a particular case an application wants to consider some=20 > result of and INFO to be fatal to the call it has ample means=20 > to cause that to happen. >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > > > > Hi, > > > > I would like to point out the following WGLC comment provided by > Keith. > > > > ------------------ > > > > "7.3. Dialog Fate Sharing > > > > As described in [RFC5057], an INFO request is always part of an > > INVITE dialog usage. > > > > One needs to consider the fate of the dialog usage of an INFO > request > > is rejected. In some cases it may be acceptable that the whole > > dialog usage is terminated, while in other cases is is=20 > desirable to > > maintain the dialog usage. > > > > However as we have a specific new response code that represents a=20 > > failure of the INFO method extension rather than any=20 > specific package, > I > > believe the actions for 469 in respect of the dialog usage > > > > should be defined in this document." > > > > ------------------ > > > > Personally I agree with Keith - the fate of the dialog should not > depend > > on the package (and the SIP stack should not need to know package=20 > > specific behavior). > > > > So, we should, in the main part of the spec talking about INFO=20 > > responses, specify whether 469 terminates the invite dialog=20 > usage, or=20 > > just the transaction. > > > > I don't see a reason to terminte the whole invite dialog usage, > because > > the 469 could come due to a race condition, when I've sent=20 > a re-INVITE >=20 > > with a new set of Info Packages, but the remote UA sent an=20 > INFO based > on > > the old set before it received the re-INVITE. > > > > But, I guess Robert can give some guidance. > > > > 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 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From brett@broadsoft.com Thu Oct 29 05:02:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C453A692A for ; Thu, 29 Oct 2009 05:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHRI+hNU5C5O for ; Thu, 29 Oct 2009 05:02:30 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 339143A6928 for ; Thu, 29 Oct 2009 05:02:30 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 29 Oct 2009 05:02:46 -0700 From: Brett Tate To: Christer Holmberg , "sipcore@ietf.org" Date: Thu, 29 Oct 2009 05:02:37 -0700 Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info Thread-Index: AcpYbX5IWBYQjtn3QL6DGTrCTkFCngAGilfA Message-ID: <747A6506A991724FB09B129B79D5FEB613ACA3E808@EXMBXCLUS01.citservers.local> References: 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 Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:02:31 -0000 Greetings, My opinion is the same as it was when discussed at various times earlier th= is year; thus I'll quote a few snippets. "There are numerous locations where I prefer new/updated Recv-Info not be u= sed because of race condition ambiguities; these include ACK, PRACK, and PR= ACK 2xx. However if the working group doesn't think such race conditions a= re a problem, leaving it is ok with me." "In case it matters, ACK can't be authenticated and introduces more race co= nditions. RFC 3261 did not define Supported and Allow to be optional within an ACK. = I mention it in case there were similar race condition and authentication c= oncerns associated with using ACK to indicate/update what is supported and = allowed." Concerning REFER, SUBSCRIBE, NOTIFY, and their responses, "I'm not opposed = to it being optional although it introduces more potential for race conditi= ons." Concerning offer/answer, I prefer not to go down that road again since I do= n't think that is needed. If preference among similar packages is the issu= e, allow their ordering to have relevance. If inability to use B after sta= rting to use A is the issue, mechanisms are in place to allow Recv-Info to = be updated and/or trigger 469. http://www.ietf.org/mail-archive/web/sip/current/msg27037.html http://www.ietf.org/mail-archive/web/sipcore/current/msg00082.html > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Thursday, October 29, 2009 3:58 AM > To: sipcore@ietf.org > Subject: [sipcore] Info Even Open Issue: Method types and offer/answer > for Recv-Info >=20 > Hi, >=20 > I have got WGLC comments from different people regarding the request > methods in which we allow the Recv-Info header field. >=20 > It IS related to something we have discussed before, but I want to > point it out, to make sure we can agree on a view. >=20 > 1) REF and SUB > ------------------------ >=20 > There has been some comments and question about whether we should allow > the R-I header field in REF and SUB. >=20 > Now, both REF and SUB are target refresh requests, and CAN be sent > within an invite dialog usage. However, I assume the dialog-usage RFC > recommends against doing so. >=20 >=20 > 2) ACK and PRA > ------------------------- >=20 > Keith suggested we shouldn't allow the header in ACK and PRA either. >=20 > Personally I would not like to make that restriction at this point, > unless there is a good technical reason, but I would like to hear what > other people think. >=20 >=20 > 3) "offer/answer" > ----------------------- >=20 > The draft currently does not define o/a type-of rules when UAs are to > indicate their Info Package set (using the Recv-Info header field). >=20 > Personally I don't think we need to define a "o/a" rules for Recv-Info. > We only need to indicate in which message the header field is allowed. >=20 > We could say that, when a UA receives the I-P set from the remote user, > it is recommend that it sends back its own set as soon as possible - if > the set has changed. >=20 > Because, if the set hasn't changed I don't think the UA needs to send > back anything, which means that whatever set it has sent before within > that dialog is still valid. That is the biggest difference compared to > o/a, which always requires the receiver to send its SDP back - even if > nothing has changed. From drage@alcatel-lucent.com Thu Oct 29 05:44:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE80F3A696B for ; Thu, 29 Oct 2009 05:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWwXVQWaqoFW for ; Thu, 29 Oct 2009 05:44:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 74B1C3A6982 for ; Thu, 29 Oct 2009 05:43:59 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9TCiASh019306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Oct 2009 13:44:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Oct 2009 13:44:12 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , SIPCORE Date: Thu, 29 Oct 2009 13:44:10 +0100 Thread-Topic: Info-Event Open Issue: Header field parameter re-use Thread-Index: AcpYGHFg8RT3KAAMRRytbLuLYsrltgAfMKbQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2092A743DFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:44:01 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2092A743DFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By reference is allowed, but it should be an explicit reference to the spec= ific parameter from the new Info Package. (And it obviously has to make sen= se in the new Info Package definition. Reference works a bit like a macro call, at the point the reference is made= , include the referenced text in the document. So essentially reference is = just like defining the parameter in full in the new document. regards Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, October 28, 2009 9:49 PM To: SIPCORE Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use Hi, Another issue which came to my mind when going through Keith's comment. Currently we say that Info Package parameters can only be used with the pac= kage for which it was defined. But, what if another Info Package needs a parameter with exactly the same s= emantics? Even if that other Info Package would use the same parameter name= , it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer t= o parameter defined for other Info Packages? NOTE that I am NOT saying that Info Packages should be allowed to use other= parameters just like that - the I-P specifications must still indicate (ei= ther by defining or refering to) which parameters are allowed for that I-P. Comments? Regards, Christer --_000_EDC0A1AE77C57744B664A310A0B23AE2092A743DFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Header field parameter re-use</TI= TLE> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3603" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>By reference is allowed, but it should be an expli= cit=20 reference to the specific parameter from the new Info Package. (And it obvi= ously=20 has to make sense in the new Info Package definition.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Reference works a bit like a macro call, at the po= int the=20 reference is made, include the referenced text in the document. So essentia= lly=20 reference is just like defining the parameter in full in the new=20 document.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>regards</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Keith</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] <B>On Behalf Of </B>Christer=20 Holmberg<BR><B>Sent:</B> Wednesday, October 28, 2009 9:49 PM<BR><B>To:</B= >=20 SIPCORE<BR><B>Subject:</B> [sipcore] Info-Event Open Issue: Header field= =20 parameter re-use<BR></FONT><BR></DIV> <DIV></DIV><!-- Converted from text/rtf format --><BR> <P><FONT face=3DArial size=3D2>Hi,</FONT> </P> <P><FONT face=3DArial size=3D2>Another issue which came to my mind when g= oing=20 through Keith's comment.</FONT> </P> <P><FONT face=3DArial size=3D2>Currently we say that Info Package paramet= ers can=20 only be used with the package for which it was defined.</FONT> </P> <P><FONT face=3DArial size=3D2>But, what if another Info Package needs a = parameter=20 with exactly the same semantics? Even if that other Info Package would us= e the=20 same parameter name, it would still have to re-define the=20 parameter.</FONT></P> <P><FONT face=3DArial size=3D2>So, the question is: should we allow Info = Package=20 specifications to refer to parameter defined for other Info Packages?</FO= NT>=20 </P><BR> <P><FONT face=3DArial size=3D2>NOTE that I am NOT saying that Info Packag= es should=20 be allowed to use other parameters just like that - the I-P specification= s=20 must still indicate (either by defining or refering to) which parameters = are=20 allowed for that I-P.</FONT></P> <P><FONT face=3DArial size=3D2>Comments?</FONT> </P> <P><FONT face=3DArial size=3D2>Regards,</FONT> </P> <P><FONT face=3DArial size=3D2>Christer</FONT> </P></BLOCKQUOTE></BODY></= HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE2092A743DFRMRSSXCHMBSC3d_-- From christer.holmberg@ericsson.com Thu Oct 29 05:55:03 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5E73A6906 for <sipcore@core3.amsl.com>; Thu, 29 Oct 2009 05:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6lY-NfHx5IM for <sipcore@core3.amsl.com>; Thu, 29 Oct 2009 05:55:02 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 263B93A68D3 for <sipcore@ietf.org>; Thu, 29 Oct 2009 05:54:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-1f-4ae990b239aa Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A1.CD.24026.2B099EA4; Thu, 29 Oct 2009 13:55:14 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 13:55:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5897.0C6E02EB" Date: Thu, 29 Oct 2009 13:55:10 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B1685C9@esealmw113.eemea.ericsson.se> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092A743D@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Info-Event Open Issue: Header field parameter re-use thread-index: AcpYGHFg8RT3KAAMRRytbLuLYsrltgAfMKbQAABS9cA= References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C3@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A743D@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "SIPCORE" <sipcore@ietf.org> X-OriginalArrivalTime: 29 Oct 2009 12:55:14.0674 (UTC) FILETIME=[0EE5FD20:01CA5897] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 29 Oct 2009 12:55:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5897.0C6E02EB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 >By reference is allowed, but it should be an explicit reference to the specific =20 >parameter from the new Info Package. =20 =20 Yes. =20 >(And it obviously has to make sense in the new Info Package definition.=20 =20 It always does :) =20 >Reference works a bit like a macro call, at the point the reference is made, include the =20 >referenced text in the document. So essentially reference is just like defining the =20 >parameter in full in the new document.=20 =20 Yes. =20 Regards, =20 Christer =20 =20 =20 =20 regards =20 Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, October 28, 2009 9:49 PM To: SIPCORE Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use =09 =09 Hi,=20 Another issue which came to my mind when going through Keith's comment.=20 Currently we say that Info Package parameters can only be used with the package for which it was defined.=20 But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer to parameter defined for other Info Packages?=20 NOTE that I am NOT saying that Info Packages should be allowed to use other parameters just like that - the I-P specifications must still indicate (either by defining or refering to) which parameters are allowed for that I-P. Comments?=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA5897.0C6E02EB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Info-Event Open Issue: Header field parameter = re-use
Hi,
 
>By reference=20 is allowed, but it should be an explicit reference to the = specific  
>parameter from the new Info Package.  
 
Yes.=
 
 >(And it obviously has to = make sense in=20 the new Info Package definition. 
 
It always does=20 :)
 
>Reference=20 works a bit like a macro call, at the point the reference is made, = include=20 the  
>referenced text in the document. = So=20 essentially reference is just like defining the  
>parameter in full in the new=20 document. 
 
Yes.=
 
Regards,
 
Christer
 
 
 
 
regards
 
Keith

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: Wednesday, October 28, 2009 9:49 = PM
To:=20 SIPCORE
Subject: [sipcore] Info-Event Open Issue: Header = field=20 parameter re-use


Hi,

Another issue which came to my mind = when going=20 through Keith's comment.

Currently we say that Info Package = parameters can=20 only be used with the package for which it was defined.

But, what if another Info Package needs = a parameter=20 with exactly the same semantics? Even if that other Info Package would = use the=20 same parameter name, it would still have to re-define the=20 parameter.

So, the question is: should we allow = Info Package=20 specifications to refer to parameter defined for other Info = Packages?=20


NOTE that I am NOT saying that Info = Packages should=20 be allowed to use other parameters just like that - the I-P = specifications=20 must still indicate (either by defining or refering to) which = parameters are=20 allowed for that I-P.

Comments?

Regards,

Christer =

------_=_NextPart_001_01CA5897.0C6E02EB-- From pkyzivat@cisco.com Thu Oct 29 06:32:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBDE3A6963; Thu, 29 Oct 2009 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy452jZJ0QWh; Thu, 29 Oct 2009 06:32:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1639D3A6AAB; Thu, 29 Oct 2009 06:32:40 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALE26UqrR7Hu/2dsb2JhbADFDpgShD0E X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="420460823" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 13:32:56 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TDWoAx024206; Thu, 29 Oct 2009 13:32:56 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:32:55 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:32:54 -0400 Message-ID: <4AE99986.9070305@cisco.com> Date: Thu, 29 Oct 2009 09:32:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomson, Martin" References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 13:32:54.0414 (UTC) FILETIME=[51CEF2E0:01CA589C] Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:32:41 -0000 I agree that this is something where a general solution would be preferable. There are a number of parties involved in this: - the publisher - the presence server - the watcher - the true source of the information (Some of the above may be collocated.) If there is a deref to be done, it can potentially be done in any of those places, except the source. The *policy* about where it should be done might also be set in any of those places. And there are competing interests about that. For instance: - the source wants to minimize derefs. Depending on the particular data and the typical access patterns for that data, choosing a particular one of the other parties to do the deref may minimize the number of derefs. (But probably the source has too little info about the usage to make the choice even if it could.) - the publisher, if it isn't collocated with the source, may want to delegate the deref to save itself work. - the presence server may also want to delegate the deref to either the publisher or the watcher to save itself work. But in other cases its role in life is to offload the publisher and the watcher, so it might be willing to take on the work. - the watcher also may want to delegate this work to one of the other parties to offload itself. But in other cases it may *want* the opportunity to do the deref itself so that it can get more timely values than it would otherwise. So, I think general solution is going to require some sort of negotiation between all the parties about who assumes this responsibility. Seems like an interesting and non-trivial problem. Thanks, Paul Thomson, Martin wrote: > Hi James, > >> This to, can be added to SIP Location Conveyance (if the SIPCORE WG >> agrees with this addition). > > Aside from a very strong desire to see the end of SIP location conveyance, all the authors on this document are in strong agreement that a location-specific solution is not desirable. > >> And when you reach consensus on the requirement to send a watcher the >> location URI instead of a location value, that will need to be >> indicated with further work. > > This is sensible. I tend to agree that we want to have the presence agent able to do the dereference. In many cases, the watcher wont be interested in doing this themselves. This is just one aspect we need to consider in the solution. > > For instance, if we extend PIDF, a presence agent that doesn't support the extension would pass the reference onward unaware of its special status. That might be a desirable attribute of a solution. Alternatively, we could provide a different body. > > Miguel and I are currently debating options. We're still trying to come to a common understanding on this point. About all we agree on right now is that this reference will sit in the body of the SIP PUBLISH and that it will not be location-specific. These are both reasons against using Geolocation, which is unfortunate in a way because it has a lot of the semantics we're looking for. > > Once we've sorted out the basics, maybe we can see how the Geolocation header fits. > >> As stated above, I believe you are wanting a default action for the >> PS to dereference > > Actually, as Miguel says, the options are still largely open. But I certainly think that having the presence agent able to dereference is a desirable feature. This might be: always dereference, dereference based on presence agent policy, dereference at the request of the presentity, or a combination of these. > > --Martin > >> James >> >> >> >> >>> /Miguel >>> >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Thu Oct 29 06:35:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F373A6963 for ; Thu, 29 Oct 2009 06:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aceMnjvTrjkf for ; Thu, 29 Oct 2009 06:35:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 3CC823A68FE for ; Thu, 29 Oct 2009 06:35:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ae-4ae99a15abe6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 44.F8.04191.51A99EA4; Thu, 29 Oct 2009 14:35:17 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 14:35:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 14:35:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7A= References: <4AE8B942.1090506@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Elwell, John" , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 29 Oct 2009 13:35:17.0643 (UTC) FILETIME=[A72DF5B0:01CA589C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:35:05 -0000 Hi, I am not sure I understood what you said, but I'll give it a try.=20 >Any specific text on receipt of 469 should go in the most appropriate section, which is definitely not section 7 - I would suggest somewhere around=20 >section 4.4, but not in 4.4 because this is all UAS functionality and we want UAC functionality. Ok, so whatever text we write should not be in section 7, but somewhere else. Then, the section 7 text is removed, and the individual Info Package specifications do not need to say anything about the dialog fate? Or? >With 469 we do not have a Info-Package, becuase the receiver was unable to recognise one that was valid. If for example two had been previously=20 >negotiated with Recv-Info, it could be either of them, or indeed the unnegotiated appearance of a third. That is why I think the issue is generic rather=20 >than Info Package specific. I think you will only send 469 if the INFO request contained Info-Package, and the idea is that the 469 contains the latest set of packages. One must not use the 469 to CHANGE the set, and maybe we need to make that clear. >I would confirm that I see no need to kill the dialog but merely the transaction. I agree with you. The question is whether we need to say something about it. Based on what others say, it seems like we wouldn't need any text at all about dialog fate. But, my head is so full of INFO that it soon explodes, so I may have missunderstood :) Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, October 29, 2009 10:05 AM > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > (pkyzivat) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Christer, >=20 > This is in the section on Info Package considerations. I rather doubt=20 > there is anything you need to specify on this topic when defining an=20 > Info-Package. All Info-Packages should be subject to the same rules:=20 > i.e., depending on the particular error response to an INFO request,=20 > the dialog usage will either remain or be terminated. If we need to=20 > say anything more on this matter (e.g., the impact of 469), that=20 > should be covered elsewhere in the document. I don't think we need=20 > 7.3. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 29 October 2009 07:42 > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Hi, > > =20 > > So, do people think we should keep the existing text (section 7.3),=20 > > which talks about the dialog fate? > > =20 > > Regards. > > =20 > > Christer > >=20 > > ________________________________ > >=20 > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > Sent: Thu 10/29/2009 7:57 AM > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > >=20 > > I agree. > >=20 > > If the INFO transaction fails, then let the application > decide whether > > it wants to continue with the dialog or not? > >=20 > > Sanjay > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Paul Kyzivat (pkyzivat) > > Sent: Thursday, October 29, 2009 3:06 AM > > To: Christer Holmberg > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > I don't think INFO should add any new dialog or usage failure cases. > > Errors that generically cause global failure, such as 408, > should of > > course do so for INFO as well. But specific failures of > INFO (legacy > > or with I-P) should only fail the transaction. > >=20 > > If in a particular case an application wants to consider > some result > > of and INFO to be fatal to the call it has ample means to > cause that > > to happen. > >=20 > > Thanks, > > Paul > >=20 > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > I would like to point out the following WGLC comment provided by > > Keith. > > > > > > ------------------ > > > > > > "7.3. Dialog Fate Sharing > > > > > > As described in [RFC5057], an INFO request is always part of an > > > INVITE dialog usage. > > > > > > One needs to consider the fate of the dialog usage of an INFO > > request > > > is rejected. In some cases it may be acceptable that the whole > > > dialog usage is terminated, while in other cases is is > > desirable to > > > maintain the dialog usage. > > > > > > However as we have a specific new response code that represents a=20 > > > failure of the INFO method extension rather than any > > specific package, > > I > > > believe the actions for 469 in respect of the dialog usage > > > > > > should be defined in this document." > > > > > > ------------------ > > > > > > Personally I agree with Keith - the fate of the dialog should not > > depend > > > on the package (and the SIP stack should not need to know package=20 > > > specific behavior). > > > > > > So, we should, in the main part of the spec talking about INFO=20 > > > responses, specify whether 469 terminates the invite dialog > > usage, or > > > just the transaction. > > > > > > I don't see a reason to terminte the whole invite dialog usage, > > because > > > the 469 could come due to a race condition, when I've sent > > a re-INVITE > >=20 > > > with a new set of Info Packages, but the remote UA sent an > > INFO based > > on > > > the old set before it received the re-INVITE. > > > > > > But, I guess Robert can give some guidance. > > > > > > 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 > >=20 > >=20 > > _______________________________________________ > > 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 >=20 From pkyzivat@cisco.com Thu Oct 29 07:30:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0B23A6768 for ; Thu, 29 Oct 2009 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AB0SAg2fpx8 for ; Thu, 29 Oct 2009 07:30:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 607BF28C0FA for ; Thu, 29 Oct 2009 07:29:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE9D6UpAZnwN/2dsb2JhbADFaZgRhD0E X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="65537617" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2009 14:29:34 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TETYZf004102; Thu, 29 Oct 2009 14:29:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:29:33 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:29:33 -0400 Message-ID: <4AE9A6CD.80907@cisco.com> Date: Thu, 29 Oct 2009 10:29:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2009 14:29:33.0579 (UTC) FILETIME=[3BDE5DB0:01CA58A4] Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 14:30:19 -0000 Christer Holmberg wrote: > Hi, > > I have got WGLC comments from different people regarding the request methods in which we allow the Recv-Info header field. > > It IS related to something we have discussed before, but I want to point it out, to make sure we can agree on a view. > > 1) REF and SUB > ------------------------ > > There has been some comments and question about whether we should allow the R-I header field in REF and SUB. > > Now, both REF and SUB are target refresh requests, and CAN be sent within an invite dialog usage. However, I assume the dialog-usage RFC recommends against doing so. Even when REF/SUB and INVITE are sharing a dialog, I don't see any need to have R-I in the REF/SUB. It would only matter if the ref/sub was *changing* the target to something with different properties than before. In that case a reINVITE can be sent to handle the R-I. > 2) ACK and PRA > ------------------------- > > Keith suggested we shouldn't allow the header in ACK and PRA either. > > Personally I would not like to make that restriction at this point, unless there is a good technical reason, but I would like to hear what other people think. I see issues with ACK (not being authenticated) that others have mentioned, so it seems a bad choice. I have less trouble with PRACK, but can go either way. > 3) "offer/answer" > ----------------------- > > The draft currently does not define o/a type-of rules when UAs are to indicate their Info Package set (using the Recv-Info header field). > > Personally I don't think we need to define a "o/a" rules for Recv-Info. We only need to indicate in which message the header field is allowed. > > We could say that, when a UA receives the I-P set from the remote user, it is recommend that it sends back its own set as soon as possible - if the set has changed. > > Because, if the set hasn't changed I don't think the UA needs to send back anything, which means that whatever set it has sent before within that dialog is still valid. That is the biggest difference compared to o/a, which always requires the receiver to send its SDP back - even if nothing has changed. The situation here is less complex than o/a because this is really a declaration rather than a negotiation. However, as always, issues can arise from 3pcc. A UA may receive a reinvite, and think nothing has changed, but in reality what is changing is that it has a peer UA that is not aware of its R-I settings. So I think it should be recommended that R-I always be sent in response to a reinvite. Also, to cover the case where the two ends get out of sync for some reason, I think it should be allowed, and suggested or required, to include R-I in a 469 response. Thanks, Paul From rjsparks@nostrum.com Thu Oct 29 08:05:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB093A6807 for ; Thu, 29 Oct 2009 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HplRtdvXki1B for ; Thu, 29 Oct 2009 08:05:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6340C3A6782 for ; Thu, 29 Oct 2009 08:05:37 -0700 (PDT) Received: from [192.168.2.2] (pool-173-57-98-31.dllstx.fios.verizon.net [173.57.98.31]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n9TF5kPj031626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2009 10:05:46 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: Christer Holmberg In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-75--651328204; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 10:05:45 -0500 References: X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 173.57.98.31 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:05:39 -0000 --Apple-Mail-75--651328204 Content-Type: multipart/alternative; boundary=Apple-Mail-74--651328273 --Apple-Mail-74--651328273 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I agree this document should talk about the 5057 impact for the 469 response code and it would not make sense for that behavior to change per-package. And I agree that the 469 only affects the transaction. I'm not sure if you're asking about this, but this document can probably explore the effect of other error codes, and it would be wrong to preclude event-package-specific effects for those. RjS On Oct 28, 2009, at 4:09 PM, Christer Holmberg wrote: > > Hi, > > I would like to point out the following WGLC comment provided by > Keith. > > ------------------ > > "7.3. Dialog Fate Sharing > > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. > > One needs to consider the fate of the dialog usage of an INFO > request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > > However as we have a specific new response code that represents a > failure of the INFO method extension rather than any specific > package, I believe the actions for 469 in respect of the dialog usage > > should be defined in this document." > > ------------------ > > Personally I agree with Keith - the fate of the dialog should not > depend on the package (and the SIP stack should not need to know > package specific behavior). > > So, we should, in the main part of the spec talking about INFO > responses, specify whether 469 terminates the invite dialog usage, > or just the transaction. > > I don't see a reason to terminte the whole invite dialog usage, > because the 469 could come due to a race condition, when I've sent a > re-INVITE with a new set of Info Packages, but the remote UA sent an > INFO based on the old set before it received the re-INVITE. > > But, I guess Robert can give some guidance. > > Regards, > > Christer > --Apple-Mail-74--651328273 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree this document should = talk about the 5057 impact for the 469 response code and it would not = make sense for that
behavior to change per-package. And I agree that = the 469 only affects the transaction.

I'm = not sure if you're asking about this, but this document can probably = explore the effect of other error codes, and it would be wrong to = preclude event-package-specific effects for = those.

RjS

On Oct 28, = 2009, at 4:09 PM, Christer Holmberg wrote:

=

Hi,

I would = like to point out the following WGLC comment provided by Keith. =

------------------ =

"7.3.  Dialog Fate = Sharing

   As = described in [RFC5057], an INFO request is always part of an =
   INVITE dialog = usage.

   One = needs to consider the fate of the dialog usage of an INFO request =
   is rejected. In some = cases it may be acceptable that the whole
   dialog usage is terminated, while in other = cases is is desirable to
   maintain the dialog usage. =

However as we have a specific new = response code that represents a failure of the INFO method extension = rather than any specific package, I believe the actions for 469 in = respect of the dialog usage

should be defined in this document."

------------------

Personally I agree with Keith - the fate of = the dialog should not depend on the package (and the SIP stack should = not need to know package specific behavior).

So, we should, in the main part of the spec talking = about INFO responses, specify whether 469 terminates the invite dialog = usage, or just the transaction.

I don't see a reason to terminte the whole invite dialog = usage, because the 469 could come due to a race condition, when I've = sent a re-INVITE with a new set of Info Packages, but the remote UA sent = an INFO based on the old set before it received the re-INVITE. =

But, I guess Robert can = give some guidance.

Regards,

Christer

=

= --Apple-Mail-74--651328273-- --Apple-Mail-75--651328204 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCCBTcw ggMfoAMCAQICAwdWFjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wOTA4MjQxNDQxMTJaFw0x MDAyMjAxNDQxMTJaMD8xGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEjMCEGCSqGSIb3DQEJARYU cmpzcGFya3NAbm9zdHJ1bS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDe7mNC maYvTINcr4RYsTXTQOLTWX+R9VZntVO0k5gcvAZlhd4U5fI9YMW5kUD2V8VpRK2pTAWTEHbt3hju WvORqUPK/i35HYrxGPGL+QXTZzsfbZsx6UGc7NLpXYXRoTt5Ai17OR9l/ec+NbBzY5iX32QHf7Ib eLJb4hvWdrfjZNwS7IVeo9nxvfgmM94fgfHDThWqPCrodOnxsq1OAYLB08FIkRVTiz/uKHcRHIan nSOOLhE5AFQUbvdQmNPIjCX/BdhoJIVbRi+nAkJPCgwBfVxGs0jrMYI05fqO3sFIuf3dk0yaFTsc Mg5+1MLYSKeFcjipPo+qjj38cfLFdpTZAgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZI AYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIg dG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYK KwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEF BQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRyanNwYXJrc0Bub3N0cnVt LmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAyEQkzIimhBuqrOPoBJa4aVhq5tSMZbHnI6BEGQRhdMt9 nVFs72VOyQ80ayywzK1nej4QNH/WAHOqmX9dk6wFxc4F7aO60b57WXR2GliEgaUwLGb+XzX8Iyq0 DRB1kea1wMuPHnBoGQf6eORhQkVHDNH0RKu9wtACtgpslooDMCS+BAP1O83VJos0+S8Baf056NGD E5/wtSVDrU8cIcRhKwdt8XbnKNdmYaSMh4gwEQDYG5CLdZkRWCx3WyZhdtVdaPXHxmyeeFSVYVUY azVudjJqGXh7nScD7+aKSZT4aIwNqybwIXBm6Eu4wMfEThVrRvHpTWegEr+44UNy9j9AbLvQJ0m6 1y7JfSH0RRMbo03nZZJv/s7/13UojE0dNsbrjSY+nPPlEm/gzbqbEHhyV/gtV8HbdCG+vEOvjnCL DTBgcxQ/xGIsWqaXqGMaYyP1xYVuw/WFgsZSNkWjSZc4QhFtDp9iL/pUOpgOJzvG3SvYt/3Tg+d+ MfyN0RfaabBH4OXiq565SPDMax70pSBT/CRIAEl4+NiRo7N7Jc+E6s0ed72VezUI88dZCfIJ1zGK aCiCu66YRp1UzkbfW7taKroMCEzEznYeg4jaAVpuXBIMlzqR83c9aNLJ3MtnbCugpO2mQR4W8SzN rZaPvNZ2SvzAKHPohaNCt5tRfXmDEz8xggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDB1YWMAkGBSsO AwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTAy OTE1MDU0NlowIwYJKoZIhvcNAQkEMRYEFHwzS1VxMnFLK4qZLW++XeNvFxUfMIGRBgkrBgEEAYI3 EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQu b3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJz dXBwb3J0QGNhY2VydC5vcmcCAwdWFjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMH Um9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0 IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwdW FjANBgkqhkiG9w0BAQEFAASCAQCuAUETjoqXjhG2i4WUeoKGBs7HsI1KUJhPZ0E1HVNhSw5p0AJB VGjm4qHLuU6nYPp8thZfWBZXcMhisYE9yIU0xgUeCPy1SjK30MLM/EyT4Wz69mk26xZ9i1g8xNUe MwTb3+i/aVAeRNaFjXGocZQ6CTCZS0tVbDmnd3j5Yy7db8vBj4kuojw8TS0f0BQqMlpjf1snJjY0 1rLyAD2I4CJEHL4zWRYN6ghuV8rcYK9W7UO/GEHrKLuzDWn90VQZN/yADJtR8oKFQHm/yXH2PsNS iLvQNnIq/Wt+5dlpbZL+3BxcoYf+WpXKeadLnsvIEvywA6e9jpHqbf6E3D0iwgHuAAAAAAAA --Apple-Mail-75--651328204-- From drage@alcatel-lucent.com Thu Oct 29 08:52:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560913A682A for ; Thu, 29 Oct 2009 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bELx4rDGhr2c for ; Thu, 29 Oct 2009 08:52:16 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C29AB3A6942 for ; Thu, 29 Oct 2009 08:52:15 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9TFqQVB014461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Oct 2009 16:52:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 29 Oct 2009 16:52:26 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Elwell, John" , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" Date: Thu, 29 Oct 2009 16:52:24 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYA== Message-ID: References: <4AE8B942.1090506@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:52:17 -0000 Treat the 469 dialog handling text and the existing 7.3 text separately. The 469 dialog handling belongs somewhere around the area of (but not in) s= ection 4.4. The 7.3 text should probably stay (in my view), and if it stays, it belongs= where it currently is. If the consensus is to remove it (as suggested by s= ome other people), then that is also fine, but I have no problem keeping it= . regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, October 29, 2009 1:35 PM > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I am not sure I understood what you said, but I'll give it a try.=20 >=20 > >Any specific text on receipt of 469 should go in the most appropriate > section, which is definitely not section 7 - I would suggest=20 > somewhere around=20 > >section 4.4, but not in 4.4 because this is all UAS functionality and > we want UAC functionality. >=20 > Ok, so whatever text we write should not be in section 7, but=20 > somewhere else. Then, the section 7 text is removed, and the=20 > individual Info Package specifications do not need to say=20 > anything about the dialog fate? >=20 > Or? >=20 > >With 469 we do not have a Info-Package, becuase the receiver=20 > was unable > to recognise one that was valid. If for example two had been=20 > previously=20 > >negotiated with Recv-Info, it could be either of them, or indeed the > unnegotiated appearance of a third. That is why I think the=20 > issue is generic rather=20 > >than Info Package specific. >=20 > I think you will only send 469 if the INFO request contained=20 > Info-Package, and the idea is that the 469 contains the=20 > latest set of packages. One must not use the 469 to CHANGE=20 > the set, and maybe we need to make that clear. >=20 > >I would confirm that I see no need to kill the dialog but merely the > transaction. >=20 > I agree with you. The question is whether we need to say=20 > something about it. Based on what others say, it seems like=20 > we wouldn't need any text at all about dialog fate. But, my=20 > head is so full of INFO that it soon explodes, so I may have=20 > missunderstood :) >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, October 29, 2009 10:05 AM > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > (pkyzivat) > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Christer, > >=20 > > This is in the section on Info Package considerations. I=20 > rather doubt=20 > > there is anything you need to specify on this topic when=20 > defining an=20 > > Info-Package. All Info-Packages should be subject to the same rules: > > i.e., depending on the particular error response to an INFO=20 > request,=20 > > the dialog usage will either remain or be terminated. If we need to=20 > > say anything more on this matter (e.g., the impact of 469), that=20 > > should be covered elsewhere in the document. I don't think we need=20 > > 7.3. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 29 October 2009 07:42 > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > Hi, > > > =20 > > > So, do people think we should keep the existing text=20 > (section 7.3),=20 > > > which talks about the dialog fate? > > > =20 > > > Regards. > > > =20 > > > Christer > > >=20 > > > ________________________________ > > >=20 > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > Sent: Thu 10/29/2009 7:57 AM > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > >=20 > > >=20 > > > I agree. > > >=20 > > > If the INFO transaction fails, then let the application > > decide whether > > > it wants to continue with the dialog or not? > > >=20 > > > Sanjay > > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > > > Behalf Of Paul Kyzivat (pkyzivat) > > > Sent: Thursday, October 29, 2009 3:06 AM > > > To: Christer Holmberg > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > I don't think INFO should add any new dialog or usage=20 > failure cases. > > > Errors that generically cause global failure, such as 408, > > should of > > > course do so for INFO as well. But specific failures of > > INFO (legacy > > > or with I-P) should only fail the transaction. > > >=20 > > > If in a particular case an application wants to consider > > some result > > > of and INFO to be fatal to the call it has ample means to > > cause that > > > to happen. > > >=20 > > > Thanks, > > > Paul > > >=20 > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > I would like to point out the following WGLC comment provided by > > > Keith. > > > > > > > > ------------------ > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > As described in [RFC5057], an INFO request is always=20 > part of an > > > > INVITE dialog usage. > > > > > > > > One needs to consider the fate of the dialog usage of an INFO > > > request > > > > is rejected. In some cases it may be acceptable that=20 > the whole > > > > dialog usage is terminated, while in other cases is is > > > desirable to > > > > maintain the dialog usage. > > > > > > > > However as we have a specific new response code that=20 > represents a=20 > > > > failure of the INFO method extension rather than any > > > specific package, > > > I > > > > believe the actions for 469 in respect of the dialog usage > > > > > > > > should be defined in this document." > > > > > > > > ------------------ > > > > > > > > Personally I agree with Keith - the fate of the dialog=20 > should not > > > depend > > > > on the package (and the SIP stack should not need to=20 > know package=20 > > > > specific behavior). > > > > > > > > So, we should, in the main part of the spec talking about INFO=20 > > > > responses, specify whether 469 terminates the invite dialog > > > usage, or > > > > just the transaction. > > > > > > > > I don't see a reason to terminte the whole invite dialog usage, > > > because > > > > the 469 could come due to a race condition, when I've sent > > > a re-INVITE > > >=20 > > > > with a new set of Info Packages, but the remote UA sent an > > > INFO based > > > on > > > > the old set before it received the re-INVITE. > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > 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 > > >=20 > > >=20 > > > _______________________________________________ > > > 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 > >=20 > = From jmpolk@cisco.com Thu Oct 29 11:23:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D563A694A; Thu, 29 Oct 2009 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5y+uTUG3O4t; Thu, 29 Oct 2009 11:23:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 46DE13A67A8; Thu, 29 Oct 2009 11:23:15 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAKl66UqrR7Ht/2dsb2JhbACIGr9DmBqEPQQ X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="420659402" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 18:23:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TINV6K012497; Thu, 29 Oct 2009 18:23:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:23:31 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.84]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:23:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Oct 2009 13:23:29 -0500 To: "Thomson, Martin" , "Miguel A. Garcia" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commsco pe.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2009 18:23:31.0172 (UTC) FILETIME=[EAED1240:01CA58C4] Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:23:16 -0000 Martin comments in-line At 12:20 AM 10/29/2009, Thomson, Martin wrote: >Hi James, > > > This to, can be added to SIP Location Conveyance (if the SIPCORE WG > > agrees with this addition). > >Aside from a very strong desire to see the end of SIP location >conveyance, all the authors on this document are in strong agreement >that a location-specific solution is not desirable. ok... I think I mention that this ought to be a more generic solution -- but then have to ask, if the authors believe this is to be a more generic solution, why would you create a "Location"" header in SIP (especially when Henning knows full well that we (SIP folks) can't name anything "Location:" because of the conflict with the HTTP header Location)? This seems pretty Location specific to me, unless I'm misreading the text in the ID for another purpose of Location: (I'm thinking I didn't because this is all about dereferencing a location URI when sent to a PS by a presentity). > > And when you reach consensus on the requirement to send a watcher the > > location URI instead of a location value, that will need to be > > indicated with further work. > >This is sensible. I tend to agree that we want to have the presence >agent able to do the dereference. "presence agent" here means presentity or PS? If presentity, then the dereference occurs before the SIP PUBLISH is sent to the PS (meaning there is no indirect location publish). If PS, then I don't see or know about anything preventing this from happening in the first place. Miguel stated to me that there is no requirement to date for a PS to send a location URI presentity to a watcher. This means that there need only be a policy in all presence servers to dereference all location URIs when received in a PUBLISH, to give to watchers that are authorized to receive a presentity's location. > In many cases, the watcher wont be interested in doing this > themselves. This is just one aspect we need to consider in the solution. I'm wondering why this is considered at all, since there is no requirement to be able to send a watcher a location URI. The solution is above. >For instance, if we extend PIDF, a presence agent that doesn't >support the extension would pass the reference onward unaware of its >special status. I'm not sure I understand how extending a PIDF is an answer, but I don't fully understand Miguel's desire for a new message body for this - in the first place. I see problems where this can be misunderstood and perhaps incorrectly used in other SIP methods to send a location URI, which could easily require support for multipart message bodies that not every UAS will support (because most don't today). >That might be a desirable attribute of a solution. Alternatively, >we could provide a different body. > >Miguel and I are currently debating options. We're still trying to >come to a common understanding on this point. About all we agree on >right now is that this reference will sit in the body of the SIP >PUBLISH and that it will not be location-specific. ok, so there is not going to be a new SIP Location: header. That's very good. I'm wondering why this has to be in a separate message body though. One option I haven't heard (admitting I'm not part of the author team have these discussions) is why a general policy can't exist specifically to presence servers to dereference any location URI found in the Geolocation header of a SIP PUBLISH request to give to authorized watchers. This is clearly the most straightforward solution - knowing there is no requirement for a presence server to send a location URI to the watcher. Once that new requirement is reached, I agree something new needs to be in the PUBLISH. But this is for location only, and if you want a more generic solution for situations where URIs are sent to presence servers that are location URIs, then perhaps something else needs to be done. >These are both reasons against using Geolocation, which is >unfortunate in a way because it has a lot of the semantics we're looking for. For location (specific) URIs, I'm not seeing how a policy at the presence server doesn't satisfy the current use of the Geolocation header. >Once we've sorted out the basics, maybe we can see how the >Geolocation header fits. ok > > > As stated above, I believe you are wanting a default action for the > > PS to dereference > >Actually, as Miguel says, the options are still largely open. But I >certainly think that having the presence agent able to dereference >is a desirable feature. This might be: always dereference, >dereference based on presence agent policy, dereference at the >request of the presentity, or a combination of these. sounds about right James >--Martin > > > > > James > > > > > > > > > > >/Miguel > > > > > >-- > > >Miguel A. Garcia > > >+34-91-339-3608 > > >Ericsson Spain > > From jmpolk@cisco.com Thu Oct 29 11:24:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B7D3A69FE; Thu, 29 Oct 2009 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XikxxfeEMCZj; Thu, 29 Oct 2009 11:24:20 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 742C73A694A; Thu, 29 Oct 2009 11:24:20 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcFAF176UqrR7Hu/2dsb2JhbACIGr8wmByEPQQ X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="199954943" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2009 18:24:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TIOSmV029301; Thu, 29 Oct 2009 18:24:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:24:28 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.84]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 11:24:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Oct 2009 13:24:26 -0500 To: "Miguel A. Garcia" From: "James M. Polk" In-Reply-To: <4AE95413.2030309@ericsson.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <4AE95413.2030309@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2009 18:24:27.0721 (UTC) FILETIME=[0CA1C390:01CA58C5] Cc: geopriv@ietf.org, sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:24:21 -0000 At 03:36 AM 10/29/2009, Miguel A. Garcia wrote: >On 27/10/2009 19:19, James M. Polk wrote: >>Why not have the following rule cover what you want >> >> the recommended policy be to dereference any location URI >> received in a Geolocation header-value (in a PUBLISH) from >> a presentity, to give to authorized watchers. > >I think this the text around the policy is quite reasonable and >according to our expectations. cool James >/Miguel >-- >Miguel A. Garcia >+34-91-339-3608 >Ericsson Spain From brian@estacado.net Thu Oct 29 11:31:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCD73A6990 for ; Thu, 29 Oct 2009 11:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwHEdqlIrgnt for ; Thu, 29 Oct 2009 11:31:17 -0700 (PDT) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 683CA3A6842 for ; Thu, 29 Oct 2009 11:31:17 -0700 (PDT) Received: from dn3-229.estacado.net (dn3-229.estacado.net [172.16.3.229]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n9TITLV7015945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Oct 2009 13:29:21 -0500 (CDT) (envelope-from brian@estacado.net) Message-Id: From: Brian Hibbard To: Ben Campbell In-Reply-To: <14E7FB7F-CD33-4C80-B62E-073348DF43F8@estacado.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1--639117795 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 13:29:16 -0500 References: <14E7FB7F-CD33-4C80-B62E-073348DF43F8@estacado.net> X-Mailer: Apple Mail (2.936) Cc: SIPCORE , Kumiko Ono , Sparks Robert Subject: Re: [sipcore] Review of draft-ietf-sipcore-sec-flows-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:31:20 -0000 --Apple-Mail-1--639117795 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks for the review, Ben. I have some responses inline. The minor text edits that you mention, =20= unless I specifically address them, I will go ahead and accept unless =20= someone has some objections. On Sep 17, 2009, at 4:11 PM, Ben Campbell wrote: > Hi, > > Someone pretending to be me agreed to review draft-ietf-sipcore-sec-=20= > flows-00 at the SIPCORE meeting in Stockholm. Since the chairs =20 > aren't buying my claims of identity theft, here's a review. I've =20 > broken it into substantive and editorial sections. > > I did _not_ attempt mechanical verification of the data and scripts =20= > in the draft--this is a human brain only review. > > > ------------------------------------------------- > > *** Substantive Comments: > > -- Status: > Is this really intended as standards track, rather than =20 > informational or possibly BCP? Is there anything normative in this =20 > doc? That's a good point. I wasn't around for the document's inception, =20 but I gather that this document was never intended to be normative. =20 I'm OK with it being informational. Does anyone else have opinions? =20= Specifically, is this document to give examples of how things could be =20= done, or how they should be done? > > -- Section 3, last paragraph: "This document does not show the =20 > messages needed to check Certificate Revocation Lists (see [3]) as =20 > that is not part of the SIP call flow" > > You explicitly list test cases for cert revocation--so I think it =20 > would be fair to show them, or at least mention them in the flows. I =20= > could argue that the TLS handshake is not part of the SIP flow =20 > either. I suspect that one reason not to show them is that their may =20= > not be a clear answer as to how to check CRLs--but if that is the =20 > case we should shine a light on it. > I need to update the references because RFC 5280 obsoletes [3]. You =20= have a point. Perhaps we should show the checking of certificate =20 revocation. It only makes sense to me to show in the call flow if we =20= are going to use OCSP. If I understand correctly, Firefox, Safari =20 and IE all use OCSP now. What is vogue in the SIP community? =20 Fetching CRLs via HTTP, out-of-band, wouldn't be very interesting to =20 show. How to check a certificate against a retrieved CRL is covered =20 adequately in 5280. We need to get some consensus on this. > -- Section 4.1: > > Is "0" a reasonable serial number? > This was not intended. The scripts that generate the certs somehow =20 got misconfigured. All the certs will need to be corrected in the =20 next revision. > The validity has a Not After date of 2013. Does that mean the RFC =20 > expires then :-) More importantly, do the certs for testing in the =20 > appendix share these dates? If so, I suggest they be set to further =20= > in the future. > Ok. I'll check to see what the latest date is that I can get the x509 =20= tool to accept. > -- Section 4.2: > > The cert examples don't include chains longer than 2. I don't know =20 > if it's really necessary to include examples for non-root issuer =20 > certs, but it might be worth throwing in a paragraph that they can =20 > exist and how they differ from root or end-entity certs. > I can add a paragraph about authorities that are not root CAs. > -- Section 5.2: General > > I'd like to see a little more about how this MESSAGE request is =20 > associated with the TLS session from the handshake example. I think =20= > it might actually be useful to show the RFC3263 stuff somewhere, =20 > either as an explicit part of the call flow or as a few sentences of =20= > explanatory text. A few sentences about how the UA decides whether =20 > to create a new TLS session or use an existing one might be helpful. OK. How about some text about RFC 3263. Is connection reuse (not to =20= be confused with "connection-reuse" draft) for TLS any different than =20= from vanilla TCP? I can go look for a suitable description of that =20 and add some text. > > -- Section 5.2, MESSAGE request: > > Contact: RFC3428 forbids Contact header fields in MESSAGE requests =20 > or 2XX responses to MESSAGE. This brings up the question as to =20 > whether MESSAGE is a good example, as you may wish to illustrate =20 > SIPS rules concerning Contact. (This reoccurs in all MESSAGE and 200 =20= > OK examples) We definitely need to figure out what we need to do here. Elsewhere =20 we talked about whether most people would really rather see INVITE. =20 The more we change the messages, the more complex the draft will =20 become and the more work it will take to produce it. That's fine, if =20= that's what needs to happen, but we do need to discuss this on the list. > > CSeq: I suggest a more "random looking" initial CSeq value. > Sure. > -- Same section, 200 OK > > Contact: There's that Contact again. Also, if you _were_ going to =20 > illustrate Contact, I think a SIPS URL rather than "transport=3DTLS" =20= > would be appropriate, since the original r-URI was SIPS. I'll look into why the stack did that and what it would take to make =20 it go away. > > -- Section 6.1, first text paragraph at top of page 16: "Also note =20 > that the sender=92s certificate is not attached as it is optional in =20= > [8]." > > It would be instructive to have an example with the certificate =20 > included. That doesn't sound like it would be too hard to get the software to do =20= that. > > > -- Section 7, title "Observed Interoperability Issues" > > Who observed them? Is this experience from SIPits, etc? I think it =20 > would strengthen the idea that these are real-world, observed-in-the-=20= > wild issues to give sources. > > -- Paragraph 2: "Some SIP clients..." > > Do mean client class devices, or user agents in general? Does this =20 > exclude proxies? (same question throughout section.) > > -- Paragraph 5: "Implementations should send.... but must be =20 > prepared to receive..." > > Is that intended as a normative statement? > > -- Last paragraph: > > I think there's some implicit stuff here that should be explicit. Do =20= > you mean to recommend never attaching certs? It's probably worth =20 > mentioning the message size limit issue. What do you mean by "it =20 > cannot be relied upon"--that you can't rely on the peer sending it, =20= > or it is unreliable when the peer does send it? Is there anyone out there who can answer these questions about section =20= 7? Cullen? Kumiko? Robert? > > -- Section 8, first bullet entry: "the peer's URI" > > What URI? An AoR for the user? =46rom or To values? Contacts? Request-=20= > URIs? > I agree, this should be specific. > For request URIs, do we need to discuss the effects of retargeting? =20= > Do we need to consider some of the current History-Info discussions? > Does anyone else in the working group have opinions on this? > -- 2nd bullet: > > What if all you've got is an IP address? Do we disallow IPAddress =20 > entries in SubjectAltName? > > -- 1st sub-bullet: "(Wildcard > matching is not allowed against these dNSName entries)" > > Is there something that can be referenced here? In particular, =20 > RFC2818 explicitly allows wildcards in dNSName entries. It is not =20 > obvious to me whether the proscription against wildcards in RFC4474 =20= > should apply to general use of TLS, or just to identity. > I don't have answers right now. We'll have to look into these. > > -- section 8, list of tests: > > What about cases where the basic constraints or allowed uses are not =20= > appropriate? Is it worth putting in cases around self-signed certs? =20= > (i.e. self-signed cert, explicitly trusted, not trusted, etc.) How =20 > about cases where one or more certs in the chain to the root were =20 > not provided and not available through other means? > Those seem like sensible cases to either include or explain why they =20 aren't included. The self-signed cert is definitely a popular case =20 among developers. > > -- 13.2 (Informative References) > > The criteria in this draft for normative vs informative references =20 > are not clear to me, particularly in the cases of 17 and 18. OTOH, =20= > are any of the references really normative for this draft? > The normative vs informative issue in general definitely needs to be =20 clarified. > Appendix A: > > Do you expect these scripts to work with all future versions of =20 > OpenSSL :-) If not, it may be worth mentioning the latest version =20 > that this has been tested with. > :) I will throw in that they worked with 0.9.8 j (or later if we move =20= on to a later version). > > -- 3rd paragraph from end: "IE, Outlook, and Netscape..." > > Please give full names and version numbers tested. Also, did you =20 > really mean Netscape instead of Firefox? > > I think that reference should be changed to Firefox. Specific =20 versions would be a good idea. > > *** Editorial Comments: > > -- Title: > > The title is really a bit misleading, as it sounds like an =20 > exhaustive set of security flows, when it's really pretty narrow. =20 > Something more along the line of "...using SIP with TLS and S/MIME". =20= > rather than "...using SIP security mechanisms." might be in order. > I agree that the title could be more descriptive of what the draft =20 actually has become. Can we get consensus on the list on exactly what =20= the title should be? > -- Section 2: > I didn't find any 2119 normative language in the draft. If there's =20 > no intent to have normative language, please remove section 2 and =20 > the 2119 reference. > That's reasonable. > > -- Section 3: > It's odd to see Security Considerations so early. I think rfc2223 =20 > requires it to be "near the end". > They're near the front end. :) Ok, moving them is no problem. > > -- Section 5.1, first paragraph: > > (Personal pet peeve) Please avoid the form "defined in [6]" for =20 > references. That may save the author some effort, but creates more =20 > effort for the reader to have to flip all over the place. > > The best approach is "defined in [6]", =20 > although I've learned to put up with "defined in [mnemonic =20 > reference]". I prefer the former, as the sentence should makes =20 > sense with the reference stripped completely. But at least the =20 > latter lets the reader know what is being referenced without having =20= > to flip to the end of the doc every time. > > -- Section 5.1, SSLDump output: > > A bit of explanation of the format whould be helpful. For example, a =20= > bit about the C>S vs S>C fields would help. Or maybe a reference to =20= > the SSLDump documentation. > > > -- Section 6.1, 1st paragraph: "Example Signed Message." > > Sentence fragment. > > -- Section 6.1, first paragraph after example MESSAGE request: > > The paragraph is ambiguous about which "header", "boundary", and =20 > "Content" type you refer to, since all of those occur multiple times =20= > in the entire message. I think you are referring to the text/plain =20= > sub-part in all cases, but it could be more clear. > > -- Section 6.1, top of page 16: > > Here you re-state the contents of the text/plain sub-part I =20 > mentioned in the previous comment. But it's not clear from the =20 > formatting or text that this is the case--it looks like random =20 > orphaned lines. This is aggravated by the poor luck of a page break =20= > right before it. I suggest adding some text to the previous example =20= > to the effect of "... in the body part shown below:" It would also =20 > help to indent or otherwise set off the body part text from the text =20= > around it. > > -- Section 6.1, first non-example paragraph at the top of page 16: =20 > "ASN.1 parse of binary Blob 1." > > Sentence Fragment. > > -- Section 6.1, top of page 18: "The above dump of Blob 1 has SHA-1 =20= > parameters set to NULL. Below are the same contents signed with the =20= > same key, but omitting the NULL according to [10]. This is the =20 > preferred encoding." > > I would consider putting the preferred encoding first. (Do you even =20= > need an example of the non-preferred encoding?--why not just show =20 > the preferred on and mention the non-preferred in text, or in the =20 > interop issues section?) > That's a good point about which should be first. The reason for =20 including the non-preferred encoding is because the legacy software =20 widely deployed does it the non-preferred way, so that's what most =20 people are going to see. That said, I agree with you that the =20 preferred encoding should come first, and unless someone really =20 objects, I intend to rearrange the text that way. > > -- 6.2, first paragraph: 'Example encrypted text/plain message that =20= > says "hello":' > > Sentence fragment. > > -- 6.2, "ASN.1 parse of binary Blob 2." > > Sentence fragment. > > -- Section 7, Paragraph 4: (starting with "When used with SIP,..." > > Is this an interop issue? You don't mention whether this is =20 > something that devices get wrong. As it stands, it is probably more =20= > suited for the SecCons section. > I see what you're getting at, but in a security-related document, =20 someone could argue that all the interop issues are security =20 considerations. My belief is that since this document does not =20 introduce new behavior, this probably really is an interop issue. The =20= fact that it is a security consideration also is hopefully covered in =20= some other document. Does anyone think I'm off in my reasoning? > 2nd to last paragraph: > > Another candidate for SecCons. > > -- Section 8, first paragraph: > > Calling the section the "beginning of a list" implies you aren't =20 > through with it. Perhaps you mean "non-exhaustive", or "an example =20 > list" or something else? > > -- 2nd paragraph: > > I take this to mean some of this is truly folklore, and some come =20 > from bona-fide normative language somewhere. Can you distinguish =20 > between the two? The true folklore parts may point to future =20 > normative work we need to do. > > For [16], can you reference the section number? > > Also, you mention [16] and [17] as normative works, but they are =20 > informative references. I don't know if that's a problem, just =20 > sayin'... > > -- section 8, 2nd bullet item: > > s/"as fed into 3263..."/"from the initial DNS query in the server =20 > location process. [RFC3263]" Good. Thanks. > > -- Section 12: > > I suspect this section should be removed from the RFC, as hopefully =20= > the issue will be resolved. And since an RFC is written in stone, =20 > I'm not sure the maintainability of the examples will matter anymore. > Yes, my bad. > -- Appendix A, general: > > It would be handy to have a table(s) showing file names and =20 > contents, rather than having to pick through paragraph streams to =20 > find them. > OK. > -- Appendix A, 3rd paragraph, last sentence: "...filed..." > > should "filed" be "file"? > > It should. > > > > --Apple-Mail-1--639117795 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Thanks for the review, = Ben.  

I have some responses inline. =  The minor text edits that you mention, unless I specifically = address them, I will go ahead and accept unless someone has some = objections. 


On Sep 17, 2009, at = 4:11 PM, Ben Campbell wrote:

Hi,

Someone pretending to be me agreed to = review draft-ietf-sipcore-sec-flows-00 at the SIPCORE meeting in = Stockholm. Since the chairs aren't buying my claims of identity theft, = here's a review. I've broken it into substantive and editorial = sections.

I did _not_ attempt mechanical verification of the data = and scripts in the draft--this is a human brain only = review.


-------------------------------------------------
*** Substantive Comments:

-- Status:
Is this really intended = as standards track, rather than informational or possibly BCP? Is there = anything normative in this = doc?

That's a good point. =  I wasn't around for the document's inception, but I gather that = this document was never intended to be normative.  I'm OK with it = being informational.  Does anyone else have opinions? =  Specifically, is this document to give examples of how things = could be done, or how they should be done?


-- Section 3, last paragraph: "This document does = not show the messages needed to check Certificate Revocation Lists (see = [3]) as that is not part of the SIP call flow"

You explicitly = list test cases for cert revocation--so I think it would be fair to show = them, or at least mention them in the flows. I could argue that the TLS = handshake is not part of the SIP flow either. I suspect that one reason = not to show them is that their may not be a clear answer as to how to = check CRLs--but if that is the case we should shine a light on = it.


I need to update the = references because RFC 5280 obsoletes [3].   You have a point. =  Perhaps we should show the checking of certificate revocation. =  It only makes sense to me to show in the call flow if we are going = to use OCSP.   If I understand correctly, Firefox, Safari and IE = all use OCSP now.  What is vogue in the SIP community? =  Fetching CRLs via HTTP, out-of-band, wouldn't be very interesting = to show.  How to check a certificate against a retrieved CRL is = covered adequately in 5280.  We need to get some consensus on = this.


-- Section = 4.1:

Is "0" a reasonable serial = number?


This was not = intended.  The scripts that generate the certs somehow got = misconfigured.  All the certs will need to be corrected in the next = revision.


The = validity has a Not After date of 2013. Does that mean the RFC expires = then :-) More importantly, do the certs for testing in the appendix = share these dates? If so, I suggest they be set to further in the = future.


Ok.  I'll = check to see what the latest date is that I can get the x509 tool to = accept.   


-- Section 4.2:

The cert examples don't = include chains longer than 2. I don't know if it's really necessary to = include examples for non-root issuer certs, but it might be worth = throwing in a paragraph that they can exist and how they differ from = root or end-entity = certs.


I can add a = paragraph about authorities that are not root = CAs. 


-- = Section 5.2: General

I'd like to see a little more about how this = MESSAGE request is associated with the TLS session from the handshake = example. I think it might actually be useful to show the RFC3263 stuff = somewhere, either as an explicit part of the call flow or as a few = sentences of explanatory text. A few sentences about how the UA decides = whether to create a new TLS session or use an existing one might be = helpful.

OK.  How about = some text about RFC 3263.  Is connection reuse (not to be confused = with "connection-reuse" draft)  for TLS any different than from = vanilla TCP?  I can go look for a suitable description of that and = add some text.


-- Section = 5.2, MESSAGE request:

Contact: RFC3428 forbids Contact header = fields in MESSAGE requests or 2XX responses to MESSAGE. This brings up = the question as to whether MESSAGE is a good example, as you may wish to = illustrate SIPS rules concerning Contact. (This reoccurs in all MESSAGE = and 200 OK examples)

We = definitely need to figure out what we need to do here.  Elsewhere = we talked about whether most people would really rather see INVITE. =  The more we change the messages, the more complex the draft will = become and the more work it will take to produce it.  That's fine, = if that's what needs to happen, but we do need to discuss this on the = list.  


CSeq: I suggest = a more "random looking" initial CSeq = value.


Sure.

<= /div>
-- Same section, 200 = OK

Contact: There's that Contact again. Also, if you _were_ going = to illustrate Contact, I think a SIPS URL rather than "transport=3DTLS" = would be appropriate, since the original r-URI was = SIPS.

I'll look into why = the stack did that and what it would take to make it go away. =  


-- Section 6.1, = first text paragraph at top of page 16: "Also note that the sender=92s = certificate is not attached as it is optional in [8]."

It would = be instructive to have an example with the certificate = included.

That doesn't sound = like it would be too hard to get the software to do that. =  



-- Section 7, = title "Observed Interoperability Issues"

Who observed them? Is = this experience from SIPits, etc? I think it would strengthen the idea = that these are real-world, observed-in-the-wild issues to give = sources.

-- Paragraph 2: "Some SIP clients..."

Do mean = client class devices, or user agents in general? Does this exclude = proxies? (same question throughout section.)

-- Paragraph 5: = "Implementations should send.... but must be prepared to = receive..."

Is that intended as a normative statement?

-- = Last paragraph:

I think there's some implicit stuff here that = should be explicit. Do you mean to recommend never attaching certs? It's = probably worth mentioning the message size limit issue. What do you mean = by "it cannot be relied upon"--that you can't rely on the peer sending = it, or it is unreliable when the peer does send = it?

Is there anyone out = there who can answer these questions about section 7?  Cullen? =  Kumiko? =  Robert? 



-- Section 8, first bullet entry: "the peer's = URI"

What URI? An AoR for the user? =46rom or To values? = Contacts? Request-URIs?


I = agree, this should be specific.


For request URIs, do we need to discuss the effects = of retargeting? Do we need to consider some of the current History-Info = discussions?


Does anyone = else in the working group have opinions on = this? 

-- 2nd = bullet:

What if all you've got is an IP address? Do we disallow = IPAddress entries in SubjectAltName?

-- 1st sub-bullet: = "(Wildcard
matching is not allowed against these dNSName = entries)"

Is there something that can be referenced here? In = particular, RFC2818 explicitly allows wildcards in dNSName entries. It = is not obvious to me whether the proscription against wildcards in = RFC4474 should apply to general use of TLS, or just to = identity.


I don't have answers right now.  We'll have to look into = these.


-- = section 8, list of tests:

What about cases where the basic = constraints or allowed uses are not appropriate? Is it worth putting in = cases around self-signed certs? (i.e. self-signed cert, explicitly = trusted, not trusted, etc.) How about cases where one or more certs in = the chain to the root were not provided and not available through other = means?


Those seem = like sensible cases to either include or explain why they aren't = included.  The self-signed cert is definitely a popular case among = developers.


-- = 13.2 (Informative References)

The criteria in this draft for = normative vs informative references are not clear to me, particularly =  in the cases of 17 and 18. OTOH, are any of the references really = normative for this = draft?


The normative vs = informative issue in general definitely needs to be = clarified.


Appendix= A:

Do you expect these scripts to work with all future versions = of OpenSSL :-)  If not, it may be worth mentioning the latest = version that this has been tested = with.



:)=  I will throw in that they worked with 0.9.8 j (or later if we = move on to a later version).


-- = 3rd paragraph from end: "IE, Outlook, and Netscape..."

Please = give full names and version numbers tested. Also, did you really mean = Netscape instead of = Firefox?



I think = that reference should be changed to Firefox.  Specific versions = would be a good = idea.




*** Editorial Comments:

-- = Title:

The title is really a bit misleading, as it sounds like an = exhaustive set of security flows, when it's really pretty narrow. = Something more along the line of "...using SIP with TLS and S/MIME". = rather than "...using SIP security mechanisms." might be in = order.



I= agree that the title could be more descriptive of what the draft = actually has become.  Can we get consensus on the list on exactly = what the title should be? =   


-- Section 2:
I didn't find any 2119 normative = language in the draft. If there's no intent to have normative language, = please remove section 2 and the 2119 = reference.



That's reasonable. 



-- Section 3:
It's odd to see Security = Considerations so early. I think rfc2223 requires it to be "near the = end".


They're near = the front end. :)   Ok, moving them is no problem. =   


-- Section 5.1, first paragraph:

(Personal pet = peeve) Please avoid the form "defined in [6]" for references. That may = save the author some effort, but creates more effort for the reader to = have to flip all over the place.

The best approach is "defined = in <doc name or description>[6]", although I've learned to put up = with "defined in [mnemonic reference]". I prefer the former,  as = the sentence should makes sense with the reference stripped completely. = But at least the latter lets the reader know what is being referenced = without having to flip to the end of the doc every time.

-- = Section 5.1, SSLDump output:

A bit of explanation of the format = whould be helpful. For example, a bit about the C>S vs S>C fields = would help. Or maybe a reference to the SSLDump = documentation.


-- Section 6.1, 1st paragraph: "Example Signed = Message."

Sentence fragment.

-- Section 6.1, first = paragraph after example MESSAGE request:

The paragraph is = ambiguous about which "header", "boundary", and "Content" type you refer = to, since all of those occur multiple times in the entire message. =  I think you are referring to the text/plain sub-part in all cases, = but it could be more clear.

-- Section 6.1, top of page = 16:

Here you re-state the contents of the text/plain sub-part I = mentioned in the previous comment. But it's not clear from the = formatting or text that this is the case--it looks like random orphaned = lines. This is aggravated by the poor luck of a page break right before = it. I suggest adding some text to the previous example to the effect of = "... in the body part shown below:" It would also help to indent or = otherwise set off the body part text from the text around it.

-- = Section 6.1, first non-example paragraph at the top of page 16: "ASN.1 = parse of binary Blob 1."

Sentence Fragment.

-- Section = 6.1, top of page 18: "The above dump of Blob 1 has SHA-1 parameters set = to NULL. Below are the same contents signed with the same key, but = omitting the NULL according to [10]. This is the preferred = encoding."

I would consider putting the preferred encoding first. = (Do you even need an example of the non-preferred encoding?--why not = just show the preferred on and mention the non-preferred in text, or in = the interop issues = section?)



That's a good point about which should be first.  The reason for = including the non-preferred encoding is because the legacy software = widely deployed does it the non-preferred way, so that's what most = people are going to see.   That said, I agree with you that the = preferred encoding should come first, and unless someone really objects, = I intend to rearrange the text that way.


-- = 6.2, first paragraph: 'Example encrypted text/plain message that says = "hello":'

Sentence fragment.

-- 6.2, "ASN.1 parse of = binary Blob 2."

Sentence fragment.

-- Section 7, Paragraph = 4: (starting with "When used with SIP,..."

Is this an interop = issue? You don't mention whether this is something that devices get = wrong. As it stands, it is probably more suited for the SecCons = section.



I = see what you're getting at, but in a security-related document, someone = could argue that all the interop issues are security considerations. =  My belief is that since this document does not introduce new = behavior, this probably really is an interop issue.  The fact that = it is a security consideration also is hopefully covered in some other = document.  Does anyone think I'm off in my = reasoning?

2nd to last = paragraph:

Another candidate for SecCons.

-- Section 8, = first paragraph:

Calling the section the "beginning of a list" = implies you aren't through with it. Perhaps you mean "non-exhaustive", = or "an example list" or something else?

-- 2nd = paragraph:

I take this to mean some of this is truly folklore, = and some come from bona-fide normative language somewhere. Can you = distinguish between the two? The true folklore parts may point to future = normative work we need to do.

For [16], can you reference the = section number?

Also, you mention [16] and [17] as normative = works, but they are informative references. I don't know if that's a = problem, just sayin'...

-- section 8, 2nd bullet = item:

s/"as fed into 3263..."/"from the initial DNS query in the = server location process. = [RFC3263]"

Good. = Thanks.


-- Section = 12:

I suspect this section should be removed from the RFC, as = hopefully the issue will be resolved. And since an RFC is written in = stone, I'm not sure the maintainability of the examples will matter = anymore.


Yes, my = bad.


-- Appendix = A, general:

It would be handy to have a table(s) showing file = names and contents, rather than having to pick through paragraph streams = to find = them.


OK.


-- Appendix A, 3rd paragraph, last = sentence: "...filed..."

should "filed" be = "file"?



It = should.






= --Apple-Mail-1--639117795-- From christer.holmberg@ericsson.com Thu Oct 29 13:18:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D313A69E3 for ; Thu, 29 Oct 2009 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMBVrSLqqOWo for ; Thu, 29 Oct 2009 13:18:38 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 11B183A694A for ; Thu, 29 Oct 2009 13:18:37 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-cc-4ae9f8accdaf Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B3.01.31706.DA8F9EA4; Thu, 29 Oct 2009 21:18:53 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 21:18:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 21:18:36 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+Qg References: <4AE8B942.1090506@cisco.com> <7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "Elwell, John" , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 29 Oct 2009 20:18:52.0940 (UTC) FILETIME=[089F0CC0:01CA58D5] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 20:18:40 -0000 Hi, My suggestion is to go with Robert's proposal, then and somewhere (in Section 4.x) generally indciate that 469 only affects the transaction, and then remote the text from section 7. We used to have a section dedicated to the 469 response, so I guess it could have fitted there also, but I was asked to remove it because the text at that time didn't really bring anything new. Regards, Christer -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: 29. lokakuuta 2009 17:52 To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) Cc: SIPCORE Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Treat the 469 dialog handling text and the existing 7.3 text separately. The 469 dialog handling belongs somewhere around the area of (but not in) section 4.4. The 7.3 text should probably stay (in my view), and if it stays, it belongs where it currently is. If the consensus is to remove it (as suggested by some other people), then that is also fine, but I have no problem keeping it. regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, October 29, 2009 1:35 PM > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha (sanjsinh); Paul=20 > Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I am not sure I understood what you said, but I'll give it a try.=20 >=20 > >Any specific text on receipt of 469 should go in the most appropriate > section, which is definitely not section 7 - I would suggest somewhere > around > >section 4.4, but not in 4.4 because this is all UAS functionality and > we want UAC functionality. >=20 > Ok, so whatever text we write should not be in section 7, but=20 > somewhere else. Then, the section 7 text is removed, and the=20 > individual Info Package specifications do not need to say anything=20 > about the dialog fate? >=20 > Or? >=20 > >With 469 we do not have a Info-Package, becuase the receiver > was unable > to recognise one that was valid. If for example two had been=20 > previously > >negotiated with Recv-Info, it could be either of them, or indeed the > unnegotiated appearance of a third. That is why I think the issue is=20 > generic rather > >than Info Package specific. >=20 > I think you will only send 469 if the INFO request contained=20 > Info-Package, and the idea is that the 469 contains the latest set of=20 > packages. One must not use the 469 to CHANGE the set, and maybe we=20 > need to make that clear. >=20 > >I would confirm that I see no need to kill the dialog but merely the > transaction. >=20 > I agree with you. The question is whether we need to say something=20 > about it. Based on what others say, it seems like we wouldn't need any > text at all about dialog fate. But, my head is so full of INFO that it > soon explodes, so I may have missunderstood :) >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, October 29, 2009 10:05 AM > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > (pkyzivat) > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Christer, > >=20 > > This is in the section on Info Package considerations. I > rather doubt > > there is anything you need to specify on this topic when > defining an > > Info-Package. All Info-Packages should be subject to the same rules: > > i.e., depending on the particular error response to an INFO > request, > > the dialog usage will either remain or be terminated. If we need to=20 > > say anything more on this matter (e.g., the impact of 469), that=20 > > should be covered elsewhere in the document. I don't think we need=20 > > 7.3. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 29 October 2009 07:42 > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > Hi, > > > =20 > > > So, do people think we should keep the existing text > (section 7.3), > > > which talks about the dialog fate? > > > =20 > > > Regards. > > > =20 > > > Christer > > >=20 > > > ________________________________ > > >=20 > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > Sent: Thu 10/29/2009 7:57 AM > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > >=20 > > >=20 > > > I agree. > > >=20 > > > If the INFO transaction fails, then let the application > > decide whether > > > it wants to continue with the dialog or not? > > >=20 > > > Sanjay > > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat (pkyzivat) > > > Sent: Thursday, October 29, 2009 3:06 AM > > > To: Christer Holmberg > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > I don't think INFO should add any new dialog or usage > failure cases. > > > Errors that generically cause global failure, such as 408, > > should of > > > course do so for INFO as well. But specific failures of > > INFO (legacy > > > or with I-P) should only fail the transaction. > > >=20 > > > If in a particular case an application wants to consider > > some result > > > of and INFO to be fatal to the call it has ample means to > > cause that > > > to happen. > > >=20 > > > Thanks, > > > Paul > > >=20 > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > I would like to point out the following WGLC comment provided by > > > Keith. > > > > > > > > ------------------ > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > As described in [RFC5057], an INFO request is always > part of an > > > > INVITE dialog usage. > > > > > > > > One needs to consider the fate of the dialog usage of an INFO > > > request > > > > is rejected. In some cases it may be acceptable that > the whole > > > > dialog usage is terminated, while in other cases is is > > > desirable to > > > > maintain the dialog usage. > > > > > > > > However as we have a specific new response code that > represents a > > > > failure of the INFO method extension rather than any > > > specific package, > > > I > > > > believe the actions for 469 in respect of the dialog usage > > > > > > > > should be defined in this document." > > > > > > > > ------------------ > > > > > > > > Personally I agree with Keith - the fate of the dialog > should not > > > depend > > > > on the package (and the SIP stack should not need to > know package > > > > specific behavior). > > > > > > > > So, we should, in the main part of the spec talking about INFO=20 > > > > responses, specify whether 469 terminates the invite dialog > > > usage, or > > > > just the transaction. > > > > > > > > I don't see a reason to terminte the whole invite dialog usage, > > > because > > > > the 469 could come due to a race condition, when I've sent > > > a re-INVITE > > >=20 > > > > with a new set of Info Packages, but the remote UA sent an > > > INFO based > > > on > > > > the old set before it received the re-INVITE. > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > 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 > > >=20 > > >=20 > > > _______________________________________________ > > > 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 > >=20 >=20 From Martin.Thomson@andrew.com Thu Oct 29 14:58:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270ED28C0E8; Thu, 29 Oct 2009 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YMQLF+HDT8w; Thu, 29 Oct 2009 14:58:25 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id 08CC728C0D8; Thu, 29 Oct 2009 14:58:25 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:47400 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4871397AbZJ2V6l (ORCPT + 1 other); Thu, 29 Oct 2009 16:58:41 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 16:58:40 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 30 Oct 2009 05:58:38 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Miguel A. Garcia" Date: Fri, 30 Oct 2009 05:59:03 +0800 Thread-Topic: draft-garcia-geopriv-indirect-publish Thread-Index: AcpYxPAKZPVfOl/YR1WgbBvrMqhV5AAHE7QA Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2519E9@SISPE7MB1.commscope.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 21:58:26 -0000 PiB3aHkgd291bGQgeW91IGNyZWF0ZSBhICJMb2NhdGlvbiIiIGhlYWRlciBpbiBTSVAgWy4uLl0g PyANCg0KU28gdGhhdCB3ZSB3b3VsZCBoYXZlIHRoaXMgZGViYXRlLiAgSXQgc2VlbXMgdG8gaGF2 ZSB3b3JrZWQgOykNCg0KVGhlcmUgd2VyZSByZWFzb25zIGZvciBjaG9vc2luZyAiTG9jYXRpb24i IHRoYXQgc2VlbWVkIHZhbGlkLiAgSSBoYWQgbm8gaWRlYSB0aGF0IGl0IHdvdWxkIGNhdXNlIHNv IG11Y2ggY29uZnVzaW9uIHRob3VnaC4gIEl0IHdhcyBuZXZlciBpbnRlbmRlZCB0byBiZSBsb2Nh dGlvbiBzcGVjaWZpYyAoaW4gYSBnZW9wcml2IHNlbnNlKTsgdGhlIGRyYWZ0IGdvZXMgdG8gZ3Jl YXQgbGVuZ3RocyB0byBtYWtlIHRoaXMgZGlzdGluY3Rpb24uICBCdXQgdGhlbiwgZXZlcnlvbmUg anVzdCBza2ltcyBkcmFmdHMsIHNvIEkgY2FuIHNlZSBob3cgZWFzaWx5IHdlIGdldCBjb25mdXNp b24gbGlrZSB0aGlzLg0KDQpTaW5jZSBJIHVwZGF0ZWQgdGhlIGRvYywgSSd2ZSBiZWVuIGNvbnZp bmNlZCB0aGF0IGEgbWVzc2FnZSBib2R5IGlzIG1vcmUgYXBwcm9wcmlhdGUgdGhhbiBhIGhlYWRl ci4NCg0KPiA+ID4gQW5kIHdoZW4geW91IHJlYWNoIGNvbnNlbnN1cyBvbiB0aGUgcmVxdWlyZW1l bnQgdG8gc2VuZCBhIHdhdGNoZXINCj4gdGhlDQo+ID4gPiBsb2NhdGlvbiBVUkkgaW5zdGVhZCBv ZiBhIGxvY2F0aW9uIHZhbHVlLCB0aGF0IHdpbGwgbmVlZCB0byBiZQ0KPiA+ID4gaW5kaWNhdGVk IHdpdGggZnVydGhlciB3b3JrLg0KPiA+DQo+ID5UaGlzIGlzIHNlbnNpYmxlLiAgSSB0ZW5kIHRv IGFncmVlIHRoYXQgd2Ugd2FudCB0byBoYXZlIHRoZSBwcmVzZW5jZQ0KPiA+YWdlbnQgYWJsZSB0 byBkbyB0aGUgZGVyZWZlcmVuY2UuDQo+IA0KPiAicHJlc2VuY2UgYWdlbnQiIGhlcmUgbWVhbnMg cHJlc2VudGl0eSBvciBQUz8NCg0KUHJlc2VuY2UgYWdlbnQgaXMgdGhlIHRlcm0gdXNlZCBieSBS RkMgMzkwMyBhbmQgb3RoZXIgcHJlc2VuY2UgZG9jdW1lbnRzLiAgSXQncyB0aGUgcHJlc2VuY2Ug c2VydmVyIChQUykgaW4geW91ciB0ZXJtcy4NCg0KPiBJZiBwcmVzZW50aXR5LCB0aGVuIHRoZSBk ZXJlZmVyZW5jZSBvY2N1cnMgYmVmb3JlIHRoZSBTSVAgUFVCTElTSCBpcw0KPiBzZW50IHRvIHRo ZSBQUyAobWVhbmluZyB0aGVyZSBpcyBubyBpbmRpcmVjdCBsb2NhdGlvbiBwdWJsaXNoKS4NCg0K TWVhbmluZyB3ZSBkb24ndCBuZWVkIGEgbWVjaGFuaXNtLiAgSSdtIG5vdCByZWFsbHkgaW50ZXJl c3RlZCBzbyBtdWNoIGluIHRoYXQgdXNlIGNhc2UuDQoNCj4gSWYgUFMsIHRoZW4gSSBkb24ndCBz ZWUgb3Iga25vdyBhYm91dCBhbnl0aGluZyBwcmV2ZW50aW5nIHRoaXMgZnJvbQ0KPiBoYXBwZW5p bmcgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpOb3RoaW5nIHByZXZlbnRpbmcgaXQsIGJ1dCBhcyBQ YXVsIG5vdGVzLCB3ZSBuZWVkIHRvIGJlIGNsZWFyIG9uIHdoYXQgbW9kZWwgd2Ugd2FudC4NCg0K PiBNaWd1ZWwgc3RhdGVkIHRvIG1lIHRoYXQgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgdG8gZGF0 ZSBmb3IgYSBQUyB0bw0KPiBzZW5kIGEgbG9jYXRpb24gVVJJIHByZXNlbnRpdHkgdG8gYSB3YXRj aGVyLiBUaGlzIG1lYW5zIHRoYXQgdGhlcmUNCj4gbmVlZCBvbmx5IGJlIGEgcG9saWN5IGluIGFs bCBwcmVzZW5jZSBzZXJ2ZXJzIHRvIGRlcmVmZXJlbmNlIGFsbA0KPiBsb2NhdGlvbiBVUklzIHdo ZW4gcmVjZWl2ZWQgaW4gYSBQVUJMSVNILCB0byBnaXZlIHRvIHdhdGNoZXJzIHRoYXQNCj4gYXJl IGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBhIHByZXNlbnRpdHkncyBsb2NhdGlvbi4NCg0KV2UncmUg bm90IHRhbGtpbmcgYWJvdXQgbG9jYXRpb24gVVJJcywgcmVtZW1iZXIuDQoNCmMuZi4gbXkgdXBj b21pbmcgcmVzcG9uc2UgdG8gUGF1bC4NCg0KPiA+ICBJbiBtYW55IGNhc2VzLCB0aGUgd2F0Y2hl ciB3b250IGJlIGludGVyZXN0ZWQgaW4gZG9pbmcgdGhpcw0KPiA+IHRoZW1zZWx2ZXMuICBUaGlz IGlzIGp1c3Qgb25lIGFzcGVjdCB3ZSBuZWVkIHRvIGNvbnNpZGVyIGluIHRoZQ0KPiBzb2x1dGlv bi4NCj4gDQo+IEknbSB3b25kZXJpbmcgd2h5IHRoaXMgaXMgY29uc2lkZXJlZCBhdCBhbGwsIHNp bmNlIHRoZXJlIGlzIG5vDQo+IHJlcXVpcmVtZW50IHRvIGJlIGFibGUgdG8gc2VuZCBhIHdhdGNo ZXIgYSBsb2NhdGlvbiBVUkkuICBUaGUNCj4gc29sdXRpb24gaXMgYWJvdmUuDQoNCldlIGhhdmVu J3QgZGV0ZXJtaW5lZCBpZiB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IG9yIG5vdC4gIEkgdGVuZCB0 byB0aGluayB0aGF0IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBwcmV2ZW50IHRoaXMsIGFuZCB0aGVy ZSBhcmUgY2FzZXMgd2hlcmUgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBhbGxvdyBmb3IgaXQuDQog DQo+ID5Gb3IgaW5zdGFuY2UsIGlmIHdlIGV4dGVuZCBQSURGLCBhIHByZXNlbmNlIGFnZW50IHRo YXQgZG9lc24ndA0KPiA+c3VwcG9ydCB0aGUgZXh0ZW5zaW9uIHdvdWxkIHBhc3MgdGhlIHJlZmVy ZW5jZSBvbndhcmQgdW5hd2FyZSBvZiBpdHMNCj4gPnNwZWNpYWwgc3RhdHVzLg0KPiANCj4gSSdt IG5vdCBzdXJlIEkgdW5kZXJzdGFuZCBob3cgZXh0ZW5kaW5nIGEgUElERiBpcyBhbiBhbnN3ZXIs IGJ1dCBJDQo+IGRvbid0IGZ1bGx5IHVuZGVyc3RhbmQgTWlndWVsJ3MgZGVzaXJlIGZvciBhIG5l dyBtZXNzYWdlIGJvZHkgZm9yDQo+IHRoaXMgLSBpbiB0aGUgZmlyc3QgcGxhY2UuIEkgc2VlIHBy b2JsZW1zIHdoZXJlIHRoaXMgY2FuIGJlDQo+IG1pc3VuZGVyc3Rvb2QgYW5kIHBlcmhhcHMgaW5j b3JyZWN0bHkgdXNlZCBpbiBvdGhlciBTSVAgbWV0aG9kcyB0bw0KPiBzZW5kIGEgbG9jYXRpb24g VVJJLCB3aGljaCBjb3VsZCBlYXNpbHkgcmVxdWlyZSBzdXBwb3J0IGZvciBtdWx0aXBhcnQNCj4g bWVzc2FnZSBib2RpZXMgdGhhdCBub3QgZXZlcnkgVUFTIHdpbGwgc3VwcG9ydCAoYmVjYXVzZSBt b3N0IGRvbid0DQo+IHRvZGF5KS4NCj4gDQo+ID5UaGF0IG1pZ2h0IGJlIGEgZGVzaXJhYmxlIGF0 dHJpYnV0ZSBvZiBhIHNvbHV0aW9uLiAgQWx0ZXJuYXRpdmVseSwNCj4gPndlIGNvdWxkIHByb3Zp ZGUgYSBkaWZmZXJlbnQgYm9keS4NCj4gPg0KPiA+TWlndWVsIGFuZCBJIGFyZSBjdXJyZW50bHkg ZGViYXRpbmcgb3B0aW9ucy4gIFdlJ3JlIHN0aWxsIHRyeWluZyB0bw0KPiA+Y29tZSB0byBhIGNv bW1vbiB1bmRlcnN0YW5kaW5nIG9uIHRoaXMgcG9pbnQuICBBYm91dCBhbGwgd2UgYWdyZWUgb24N Cj4gPnJpZ2h0IG5vdyBpcyB0aGF0IHRoaXMgcmVmZXJlbmNlIHdpbGwgc2l0IGluIHRoZSBib2R5 IG9mIHRoZSBTSVANCj4gPlBVQkxJU0ggYW5kIHRoYXQgaXQgd2lsbCBub3QgYmUgbG9jYXRpb24t c3BlY2lmaWMuDQo+IA0KPiBvaywgc28gdGhlcmUgaXMgbm90IGdvaW5nIHRvIGJlIGEgbmV3IFNJ UCBMb2NhdGlvbjogaGVhZGVyLiBUaGF0J3MgdmVyeQ0KPiBnb29kLg0KPiANCj4gSSdtIHdvbmRl cmluZyB3aHkgdGhpcyBoYXMgdG8gYmUgaW4gYSBzZXBhcmF0ZSBtZXNzYWdlIGJvZHkgdGhvdWdo Lg0KDQpJdCdzIGN1cnJlbnRseSBhIGNob2ljZS4gIE9uZSB0aGF0IEknbSB0ZW5kaW5nIGF3YXkg ZnJvbSByaWdodCBub3csIGJ1dCBpdCdzIHN0aWxsIGEgdmFsaWQgY2hvaWNlLg0KDQo+IE9uZSBv cHRpb24gSSBoYXZlbid0IGhlYXJkIChhZG1pdHRpbmcgSSdtIG5vdCBwYXJ0IG9mIHRoZSBhdXRo b3IgdGVhbQ0KPiBoYXZlIHRoZXNlIGRpc2N1c3Npb25zKSBpcyB3aHkgYSBnZW5lcmFsIHBvbGlj eSBjYW4ndCBleGlzdA0KPiBzcGVjaWZpY2FsbHkgdG8gcHJlc2VuY2Ugc2VydmVycyB0byBkZXJl ZmVyZW5jZSBhbnkgbG9jYXRpb24gVVJJDQo+IGZvdW5kIGluIHRoZSBHZW9sb2NhdGlvbiBoZWFk ZXIgb2YgYSBTSVAgUFVCTElTSCByZXF1ZXN0IHRvIGdpdmUgdG8NCj4gYXV0aG9yaXplZCB3YXRj aGVycy4gIFRoaXMgaXMgY2xlYXJseSB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQNCj4gc29sdXRp b24gLSBrbm93aW5nIHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciBhIHByZXNlbmNlIHNlcnZl ciB0bw0KPiBzZW5kIGEgbG9jYXRpb24gVVJJIHRvIHRoZSB3YXRjaGVyLiBPbmNlIHRoYXQgbmV3 IHJlcXVpcmVtZW50IGlzDQo+IHJlYWNoZWQsIEkgYWdyZWUgc29tZXRoaW5nIG5ldyBuZWVkcyB0 byBiZSBpbiB0aGUgUFVCTElTSC4NCg0KQWN0dWFsbHksIGlmIHlvdSByZWFkIHRoZSBkcmFmdCwg SSBkaXNjdXNzIHRoaXMgYnJpZWZseS4gIFdlIGNhbiByZXF1ZXN0IHRoYXQgYSBzZXJ2ZXIgZGVy ZWZlcmVuY2VzLCBidXQgd2UgY2FuJ3QgZm9yY2UgdGhlbS4gIEFmdGVyIGFsbCwgc2VydmVycyB0 aGF0IGRvbid0IHN1cHBvcnQgdGhpcyBmZWF0dXJlIHdpbGwgZXhpc3QuDQoNCj4gQnV0IHRoaXMg aXMgZm9yIGxvY2F0aW9uIG9ubHksIGFuZCBpZiB5b3Ugd2FudCBhIG1vcmUgZ2VuZXJpYw0KPiBz b2x1dGlvbiBmb3Igc2l0dWF0aW9ucyB3aGVyZSBVUklzIGFyZSBzZW50IHRvIHByZXNlbmNlIHNl cnZlcnMgdGhhdA0KPiBhcmUgbG9jYXRpb24gVVJJcywgdGhlbiBwZXJoYXBzIHNvbWV0aGluZyBl bHNlIG5lZWRzIHRvIGJlIGRvbmUuDQoNClByZWNpc2VseS4NCiANCj4gPk9uY2Ugd2UndmUgc29y dGVkIG91dCB0aGUgYmFzaWNzLCBtYXliZSB3ZSBjYW4gc2VlIGhvdyB0aGUNCj4gPkdlb2xvY2F0 aW9uIGhlYWRlciBmaXRzLg0KPiANCj4gb2sNCj4gDQo+ID4NCj4gPiA+IEFzIHN0YXRlZCBhYm92 ZSwgSSBiZWxpZXZlIHlvdSBhcmUgd2FudGluZyBhIGRlZmF1bHQgYWN0aW9uIGZvciB0aGUNCj4g PiA+IFBTIHRvIGRlcmVmZXJlbmNlDQo+ID4NCj4gPkFjdHVhbGx5LCBhcyBNaWd1ZWwgc2F5cywg dGhlIG9wdGlvbnMgYXJlIHN0aWxsIGxhcmdlbHkgb3Blbi4gIEJ1dCBJDQo+ID5jZXJ0YWlubHkg dGhpbmsgdGhhdCBoYXZpbmcgdGhlIHByZXNlbmNlIGFnZW50IGFibGUgdG8gZGVyZWZlcmVuY2UN Cj4gPmlzIGEgZGVzaXJhYmxlIGZlYXR1cmUuICBUaGlzIG1pZ2h0IGJlOiBhbHdheXMgZGVyZWZl cmVuY2UsDQo+ID5kZXJlZmVyZW5jZSBiYXNlZCBvbiBwcmVzZW5jZSBhZ2VudCBwb2xpY3ksIGRl cmVmZXJlbmNlIGF0IHRoZQ0KPiA+cmVxdWVzdCBvZiB0aGUgcHJlc2VudGl0eSwgb3IgYSBjb21i aW5hdGlvbiBvZiB0aGVzZS4NCj4gDQo+IHNvdW5kcyBhYm91dCByaWdodA0KPiANCj4gSmFtZXMN Cg0KLS1NYXJ0aW4NCg0KPiANCj4gDQo+ID4tLU1hcnRpbg0KPiA+DQo+ID4gPg0KPiA+ID4gSmFt ZXMNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+L01pZ3VlbA0KPiA+ID4gPg0K PiA+ID4gPi0tDQo+ID4gPiA+TWlndWVsIEEuIEdhcmNpYQ0KPiA+ID4gPiszNC05MS0zMzktMzYw OA0KPiA+ID4gPkVyaWNzc29uIFNwYWluDQo+ID4gPg0KPiANCg0K From Martin.Thomson@andrew.com Thu Oct 29 15:31:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4EC28C108; Thu, 29 Oct 2009 15:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8ICSlXavUSm; Thu, 29 Oct 2009 15:31:25 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.243]) by core3.amsl.com (Postfix) with ESMTP id ED2623A6A3E; Thu, 29 Oct 2009 15:31:24 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:15319 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S4877141AbZJ2Wbj (ORCPT + 1 other); Thu, 29 Oct 2009 17:31:39 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 17:31:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 30 Oct 2009 06:31:34 +0800 From: "Thomson, Martin" To: Paul Kyzivat Date: Fri, 30 Oct 2009 06:31:59 +0800 Thread-Topic: [sipcore] draft-garcia-geopriv-indirect-publish Thread-Index: AcpYnFhy/jjghRL7Rm+CiapP9RzFdAARrFDQ Message-ID: <8B0A9FCBB9832F43971E38010638454F0F2519F6@SISPE7MB1.commscope.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> <4AE99986.9070305@cisco.com> In-Reply-To: <4AE99986.9070305@cisco.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 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 22:31:26 -0000 SGkgUGF1bCwNCg0KVGhhdCdzIGFuIGV4Y2VsbGVudCBzdW1tYXJ5IG9mIHRoZSBzdGFrZWhvbGRl cnMuDQoNCiAgICAgICAgICAgICAgICAgU291cmNlDQogICAgICAgICAgICAgICAgICAgIHwgIFwN CiAgICAgICAgICAgICAgICAgICA/fCAgICBcID8NCiAgICAgICAgICAgICAgICAgICAgfCAgICAg IFwNCiAgUHVibGlzaGVyLyAtLS0gU2VydmVyIC0tLSBXYXRjaGVyDQogIFByZXNlbnRpdHkgICAg ICAoUEEpDQoNCkFzc3VtaW5nIHRoYXQgdGhlIHB1Ymxpc2hlciB3YW50cyB0byBkbyB0aGUgZGVy ZWZlcmVuY2UgKGFuZCB0aGV5IGFyZSBhYmxlIHRvIFsxXSksIHdlIGhhdmUgbm90aGluZyBmdXJ0 aGVyIHRvIGRvLiAgV2UgZG9uJ3QgbmVlZCB0byBidWlsZCBhIG1lY2hhbmlzbS4gIFRoZSBwdWJs aXNoZXIgY2FuIGltcGxlbWVudCB0aGlzIHBvbGljeSBhcyB0aGV5IHNlZSBmaXQuDQoNClNvLCB0 aGUgcHJlc2VudGl0eSBwdWJsaXNoZXMgYSByZWZlcmVuY2UgdG8gdGhlIHByZXNlbmNlIHNlcnZl ci4NCg0KVGhlIHBlcnRpbmVudCBxdWVzdGlvbnMgYXJlOg0KDQogKEEpIGRvZXMgdGhlIHByZXNl bnRpdHkgaGF2ZSBhbnkgc2F5IGluIHdoZXJlIHRoZSByZWZlcmVuY2UgaXMgcmVzb2x2ZWQ/DQoN CiAoQikgZG9lcyB0aGUgd2F0Y2hlciBoYXZlIGFueSBzYXkgaW4gd2hlcmUgdGhlIHJlZmVyZW5j ZSBpcyByZXNvbHZlZD8NCg0KQW55IHByZWZlcmVuY2UgZm9yIChBKSBpcyBleHByZXNzZWQgaW4g YSBQVUJMSVNIIGFuZCB0aGF0IGFueSBwcmVmZXJlbmNlIGZvciAoQikgaXMgZXhwcmVzc2VkIGlu IGEgU1VCU0NSSUJFIChtb3N0IHByb2JhYmx5KS4gIE9idmlvdXNseSwgdGhlIHNlcnZlciBoYXMg dGhlIGZpbmFsIHNheTogaXQgY2FuIGNob29zZSB0byBwYXNzIHRoZSByZWZlcmVuY2Ugb24gLSBm b3JjaW5nIHRoZSB3YXRjaGVyIHRvIGRlcmVmZXJlbmNlIC0gb3IgaXQgY2FuIGRvIHRoZSBkZXJl ZmVyZW5jZSBpdHNlbGYuDQoNClNvLCB3aHkgd291bGQgdGhlIHB1Ymxpc2hlciBhc2sgdGhlIHNl cnZlciB0byBkZXJlZmVyZW5jZT8gIE1heWJlIGl0IGtub3dzIHNvbWV0aGluZyBvZiB0aGUgd2F0 Y2hlcnMsIG9yIG1heWJlIGl0IHdhbnRzIHRvIHByb3RlY3QgdGhlIHJlZmVyZW5jZSAoYy5mLiBs b2NhdGlvbiBVUklzIGFuZCB0aGUgcG9zc2Vzc2lvbiBtb2RlbCkuICBUaGF0IHNlY29uZCByZWFz b24gaXMgYSBnb29kIHJlYXNvbiB0byBoYXZlIGEgbWVhbnMgdG8gZmFpbCB0aGUgcHVibGlzaCBp ZiB0aGUgc2VydmVyIGlzIHVud2lsbGluZyBvciB1bmFibGUuICBUaGUgUmVxdWlyZSBoZWFkZXIg SSBwcm9wb3NlZCBkb2VzIHRoaXMsIGJ1dCB0aGVyZSBtaWdodCBiZSBvdGhlciB3YXlzIHRvIGFj aGlldmUgdGhlIHNhbWUgZWZmZWN0Lg0KDQpTbyB3aHkgd291bGQgdGhlIHdhdGNoZXIgYXNrIHRo ZSBzZXJ2ZXIgdG8gZGVyZWZlcmVuY2U/ICBUaGUgc2ltcGxlc3QgcmVhc29uIGlzOiBpdCBkb2Vz bid0IHdhbnQgdG8gZG8gdGhlIHdvcmsgaXRzZWxmLg0KDQpXaHkgd291bGQgdGhlIHNlcnZlciBu b3Qgd2FudCB0byBkZXJlZmVyZW5jZT8gIFRoZSBpZGVhIHRoYXQgaXQgZG9lc24ndCB3YW50IHRo ZSBleHRyYSB3b3JrIGRvZXNuJ3QgcmVhbGx5IGZpdCB3aXRoIGl0IGJlaW5nIGEgcHJlc2VuY2Ug c2VydmVyLiAgQWZ0ZXIgYWxsLCBhIGxhcmdlIHBhcnQgb2YgaXRzIHJlYXNvbiBmb3IgYmVpbmcg aXMgdG8gb2ZmbG9hZCB3b3JrIGZyb20gd2F0Y2hlciBhbmQgcHVibGlzaGVyLg0KDQpTbywgYWxs IHRoaXMgbW9yZSBvciBsZXNzIGxlYWRzIG1lIHRvIHRoaW5rIHRoYXQgaGF2aW5nIHRoZSBzZXJ2 ZXIgZGVyZWZlcmVuY2UgaXMgdGhlIG1vc3Qgc2Vuc2libGUgb3B0aW9uLiAgT2J2aW91c2x5LCBz ZXJ2ZXIgcG9saWN5IGNhbiBvdmVycmlkZSB0aGlzIG9yIHRoZSBzZXJ2ZXIgbWlnaHQgYmUgdW5h YmxlIHRvIGRlcmVmZXJlbmNlLg0KDQpJIGRvIHRoaW5rIHRoYXQgaXQgbWlnaHQgbWFrZSBzZW5z ZSB0byBoYXZlIGFuIG9wdGlvbiB3aGVyZSB0aGUgc2VydmVyIGZhaWxpbmcgdG8gZGVyZWZlcmVu Y2UgZG9lc24ndCBwcmV2ZW50IHRoZSB3YXRjaGVyIGZyb20gYXR0ZW1wdGluZyB0byBkbyBzby4g IElmIHRoZSBzZXJ2ZXIgZG9lc24ndCBzdXBwb3J0IHRoZSBmZWF0dXJlLCB0aGUgc2VydmVyIGRl Y2lkZXMgbm90IGRlcmVmZXJlbmNlLCBvciB0aGUgc2VydmVyIGVuY291bnRlcnMgYW4gZXJyb3Ig d2hpbGUgdHJ5aW5nLCAuLi4gdGhlbiB0aGUgcmVmZXJlbmNlIGlzIHBhc3NlZCBvbiB0aGUgd2F0 Y2hlci4gIA0KDQpUaGF0IGxlYWRzIG1lIHRvIGNvbmNsdWRlIHRoYXQgdGhlcmUgaXMgbm8gYmVu ZWZpdCBpbiBoYXZpbmcgdGhlIHdhdGNoZXIgcmVxdWVzdCB0aGF0IGEgcmVmZXJlbmNlIGlzIHJl c29sdmVkLiAgSWYgdGhlIHdhdGNoZXIgcmVjZWl2ZXMgYSByZWZlcmVuY2UsIGl0IGtub3dzIHRo YXQgdGhlcmUncyBub3RoaW5nIGl0IGNvdWxkIGhhdmUgZG9uZSB0byBoYXZlIHRoaXMgZGVyZWZl cmVuY2VkIGZvciBpdC4NCg0KQ2hlZXJzLA0KLS1NYXJ0aW4NCg0KWzFdIFRoaXMgaXNuJ3QgYWx3 YXlzIHRoZSBjYXNlOiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lY3Jp dC1yb3VnaC1sb2M+LCB0aG91Z2ggZm9yIG1hbnkgcHJlc2VuY2UgdXNlIGNhc2VzIEkgZG91YnQg aXQgd2lsbCBiZSBhIGZhY3Rvci4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dDQo+IFNlbnQ6IEZy aWRheSwgMzAgT2N0b2JlciAyMDA5IDEyOjMzIEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW4NCj4g Q2M6IEphbWVzIE0uIFBvbGs7IE1pZ3VlbCBBLiBHYXJjaWE7IGdlb3ByaXZAaWV0Zi5vcmc7IHNp cGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC1nYXJjaWEtZ2Vv cHJpdi1pbmRpcmVjdC1wdWJsaXNoDQo+IA0KPiBJIGFncmVlIHRoYXQgdGhpcyBpcyBzb21ldGhp bmcgd2hlcmUgYSBnZW5lcmFsIHNvbHV0aW9uIHdvdWxkIGJlDQo+IHByZWZlcmFibGUuDQo+IA0K PiBUaGVyZSBhcmUgYSBudW1iZXIgb2YgcGFydGllcyBpbnZvbHZlZCBpbiB0aGlzOg0KPiAtIHRo ZSBwdWJsaXNoZXINCj4gLSB0aGUgcHJlc2VuY2Ugc2VydmVyDQo+IC0gdGhlIHdhdGNoZXINCj4g LSB0aGUgdHJ1ZSBzb3VyY2Ugb2YgdGhlIGluZm9ybWF0aW9uDQo+IA0KPiAoU29tZSBvZiB0aGUg YWJvdmUgbWF5IGJlIGNvbGxvY2F0ZWQuKQ0KPiANCj4gSWYgdGhlcmUgaXMgYSBkZXJlZiB0byBi ZSBkb25lLCBpdCBjYW4gcG90ZW50aWFsbHkgYmUgZG9uZSBpbiBhbnkgb2YNCj4gdGhvc2UgcGxh Y2VzLCBleGNlcHQgdGhlIHNvdXJjZS4gVGhlICpwb2xpY3kqIGFib3V0IHdoZXJlIGl0IHNob3Vs ZCBiZQ0KPiBkb25lIG1pZ2h0IGFsc28gYmUgc2V0IGluIGFueSBvZiB0aG9zZSBwbGFjZXMuIEFu ZCB0aGVyZSBhcmUgY29tcGV0aW5nDQo+IGludGVyZXN0cyBhYm91dCB0aGF0LiBGb3IgaW5zdGFu Y2U6DQo+IA0KPiAtIHRoZSBzb3VyY2Ugd2FudHMgdG8gbWluaW1pemUgZGVyZWZzLiBEZXBlbmRp bmcgb24gdGhlIHBhcnRpY3VsYXINCj4gICAgZGF0YSBhbmQgdGhlIHR5cGljYWwgYWNjZXNzIHBh dHRlcm5zIGZvciB0aGF0IGRhdGEsIGNob29zaW5nIGENCj4gICAgcGFydGljdWxhciBvbmUgb2Yg dGhlIG90aGVyIHBhcnRpZXMgdG8gZG8gdGhlIGRlcmVmIG1heSBtaW5pbWl6ZQ0KPiAgICB0aGUg bnVtYmVyIG9mIGRlcmVmcy4gKEJ1dCBwcm9iYWJseSB0aGUgc291cmNlIGhhcyB0b28gbGl0dGxl IGluZm8NCj4gICAgYWJvdXQgdGhlIHVzYWdlIHRvIG1ha2UgdGhlIGNob2ljZSBldmVuIGlmIGl0 IGNvdWxkLikNCj4gDQo+IC0gdGhlIHB1Ymxpc2hlciwgaWYgaXQgaXNuJ3QgY29sbG9jYXRlZCB3 aXRoIHRoZSBzb3VyY2UsIG1heSB3YW50DQo+ICAgIHRvIGRlbGVnYXRlIHRoZSBkZXJlZiB0byBz YXZlIGl0c2VsZiB3b3JrLg0KPiANCj4gLSB0aGUgcHJlc2VuY2Ugc2VydmVyIG1heSBhbHNvIHdh bnQgdG8gZGVsZWdhdGUgdGhlIGRlcmVmIHRvIGVpdGhlcg0KPiAgICB0aGUgcHVibGlzaGVyIG9y IHRoZSB3YXRjaGVyIHRvIHNhdmUgaXRzZWxmIHdvcmsuIEJ1dCBpbiBvdGhlcg0KPiAgICBjYXNl cyBpdHMgcm9sZSBpbiBsaWZlIGlzIHRvIG9mZmxvYWQgdGhlIHB1Ymxpc2hlciBhbmQgdGhlIHdh dGNoZXIsDQo+ICAgIHNvIGl0IG1pZ2h0IGJlIHdpbGxpbmcgdG8gdGFrZSBvbiB0aGUgd29yay4N Cj4gDQo+IC0gdGhlIHdhdGNoZXIgYWxzbyBtYXkgd2FudCB0byBkZWxlZ2F0ZSB0aGlzIHdvcmsg dG8gb25lIG9mIHRoZQ0KPiAgICBvdGhlciBwYXJ0aWVzIHRvIG9mZmxvYWQgaXRzZWxmLiBCdXQg aW4gb3RoZXIgY2FzZXMgaXQgbWF5ICp3YW50Kg0KPiAgICB0aGUgb3Bwb3J0dW5pdHkgdG8gZG8g dGhlIGRlcmVmIGl0c2VsZiBzbyB0aGF0IGl0IGNhbiBnZXQgbW9yZQ0KPiAgICB0aW1lbHkgdmFs dWVzIHRoYW4gaXQgd291bGQgb3RoZXJ3aXNlLg0KPiANCj4gU28sIEkgdGhpbmsgIGdlbmVyYWwg c29sdXRpb24gaXMgZ29pbmcgdG8gcmVxdWlyZSBzb21lIHNvcnQgb2YNCj4gbmVnb3RpYXRpb24g YmV0d2VlbiBhbGwgdGhlIHBhcnRpZXMgYWJvdXQgd2hvIGFzc3VtZXMgdGhpcw0KPiByZXNwb25z aWJpbGl0eS4gU2VlbXMgbGlrZSBhbiBpbnRlcmVzdGluZyBhbmQgbm9uLXRyaXZpYWwgcHJvYmxl bS4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6 DQo+ID4gSGkgSmFtZXMsDQo+ID4NCj4gPj4gVGhpcyB0bywgY2FuIGJlIGFkZGVkIHRvIFNJUCBM b2NhdGlvbiBDb252ZXlhbmNlIChpZiB0aGUgU0lQQ09SRSBXRw0KPiA+PiBhZ3JlZXMgd2l0aCB0 aGlzIGFkZGl0aW9uKS4NCj4gPg0KPiA+IEFzaWRlIGZyb20gYSB2ZXJ5IHN0cm9uZyBkZXNpcmUg dG8gc2VlIHRoZSBlbmQgb2YgU0lQIGxvY2F0aW9uDQo+IGNvbnZleWFuY2UsIGFsbCB0aGUgYXV0 aG9ycyBvbiB0aGlzIGRvY3VtZW50IGFyZSBpbiBzdHJvbmcgYWdyZWVtZW50DQo+IHRoYXQgYSBs b2NhdGlvbi1zcGVjaWZpYyBzb2x1dGlvbiBpcyBub3QgZGVzaXJhYmxlLg0KPiA+DQo+ID4+IEFu ZCB3aGVuIHlvdSByZWFjaCBjb25zZW5zdXMgb24gdGhlIHJlcXVpcmVtZW50IHRvIHNlbmQgYSB3 YXRjaGVyDQo+IHRoZQ0KPiA+PiBsb2NhdGlvbiBVUkkgaW5zdGVhZCBvZiBhIGxvY2F0aW9uIHZh bHVlLCB0aGF0IHdpbGwgbmVlZCB0byBiZQ0KPiA+PiBpbmRpY2F0ZWQgd2l0aCBmdXJ0aGVyIHdv cmsuDQo+ID4NCj4gPiBUaGlzIGlzIHNlbnNpYmxlLiAgSSB0ZW5kIHRvIGFncmVlIHRoYXQgd2Ug d2FudCB0byBoYXZlIHRoZSBwcmVzZW5jZQ0KPiBhZ2VudCBhYmxlIHRvIGRvIHRoZSBkZXJlZmVy ZW5jZS4gIEluIG1hbnkgY2FzZXMsIHRoZSB3YXRjaGVyIHdvbnQgYmUNCj4gaW50ZXJlc3RlZCBp biBkb2luZyB0aGlzIHRoZW1zZWx2ZXMuICBUaGlzIGlzIGp1c3Qgb25lIGFzcGVjdCB3ZSBuZWVk DQo+IHRvIGNvbnNpZGVyIGluIHRoZSBzb2x1dGlvbi4NCj4gPg0KPiA+IEZvciBpbnN0YW5jZSwg aWYgd2UgZXh0ZW5kIFBJREYsIGEgcHJlc2VuY2UgYWdlbnQgdGhhdCBkb2Vzbid0DQo+IHN1cHBv cnQgdGhlIGV4dGVuc2lvbiB3b3VsZCBwYXNzIHRoZSByZWZlcmVuY2Ugb253YXJkIHVuYXdhcmUg b2YgaXRzDQo+IHNwZWNpYWwgc3RhdHVzLiAgVGhhdCBtaWdodCBiZSBhIGRlc2lyYWJsZSBhdHRy aWJ1dGUgb2YgYSBzb2x1dGlvbi4NCj4gQWx0ZXJuYXRpdmVseSwgd2UgY291bGQgcHJvdmlkZSBh IGRpZmZlcmVudCBib2R5Lg0KPiA+DQo+ID4gTWlndWVsIGFuZCBJIGFyZSBjdXJyZW50bHkgZGVi YXRpbmcgb3B0aW9ucy4gIFdlJ3JlIHN0aWxsIHRyeWluZyB0bw0KPiBjb21lIHRvIGEgY29tbW9u IHVuZGVyc3RhbmRpbmcgb24gdGhpcyBwb2ludC4gIEFib3V0IGFsbCB3ZSBhZ3JlZSBvbg0KPiBy aWdodCBub3cgaXMgdGhhdCB0aGlzIHJlZmVyZW5jZSB3aWxsIHNpdCBpbiB0aGUgYm9keSBvZiB0 aGUgU0lQDQo+IFBVQkxJU0ggYW5kIHRoYXQgaXQgd2lsbCBub3QgYmUgbG9jYXRpb24tc3BlY2lm aWMuICBUaGVzZSBhcmUgYm90aA0KPiByZWFzb25zIGFnYWluc3QgdXNpbmcgR2VvbG9jYXRpb24s IHdoaWNoIGlzIHVuZm9ydHVuYXRlIGluIGEgd2F5DQo+IGJlY2F1c2UgaXQgaGFzIGEgbG90IG9m IHRoZSBzZW1hbnRpY3Mgd2UncmUgbG9va2luZyBmb3IuDQo+ID4NCj4gPiBPbmNlIHdlJ3ZlIHNv cnRlZCBvdXQgdGhlIGJhc2ljcywgbWF5YmUgd2UgY2FuIHNlZSBob3cgdGhlDQo+IEdlb2xvY2F0 aW9uIGhlYWRlciBmaXRzLg0KPiA+DQo+ID4+IEFzIHN0YXRlZCBhYm92ZSwgSSBiZWxpZXZlIHlv dSBhcmUgd2FudGluZyBhIGRlZmF1bHQgYWN0aW9uIGZvciB0aGUNCj4gPj4gUFMgdG8gZGVyZWZl cmVuY2UNCj4gPg0KPiA+IEFjdHVhbGx5LCBhcyBNaWd1ZWwgc2F5cywgdGhlIG9wdGlvbnMgYXJl IHN0aWxsIGxhcmdlbHkgb3Blbi4gIEJ1dCBJDQo+IGNlcnRhaW5seSB0aGluayB0aGF0IGhhdmlu ZyB0aGUgcHJlc2VuY2UgYWdlbnQgYWJsZSB0byBkZXJlZmVyZW5jZSBpcyBhDQo+IGRlc2lyYWJs ZSBmZWF0dXJlLiAgVGhpcyBtaWdodCBiZTogYWx3YXlzIGRlcmVmZXJlbmNlLCBkZXJlZmVyZW5j ZQ0KPiBiYXNlZCBvbiBwcmVzZW5jZSBhZ2VudCBwb2xpY3ksIGRlcmVmZXJlbmNlIGF0IHRoZSBy ZXF1ZXN0IG9mIHRoZQ0KPiBwcmVzZW50aXR5LCBvciBhIGNvbWJpbmF0aW9uIG9mIHRoZXNlLg0K PiA+DQo+ID4gLS1NYXJ0aW4NCj4gPg0KPiA+PiBKYW1lcw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+Pj4gL01pZ3VlbA0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBNaWd1ZWwgQS4gR2FyY2lh DQo+ID4+PiArMzQtOTEtMzM5LTM2MDgNCj4gPj4+IEVyaWNzc29uIFNwYWluDQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNpcGNv cmUgbWFpbGluZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+DQoNCg== From christer.holmberg@ericsson.com Thu Oct 29 15:51:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A173A687F for ; Thu, 29 Oct 2009 15:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVf+h+i-prII for ; Thu, 29 Oct 2009 15:51:38 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1AF1D3A6810 for ; Thu, 29 Oct 2009 15:51:36 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-76-4aea1c87ee71 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 0A.34.31706.78C1AEA4; Thu, 29 Oct 2009 23:51:51 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 23:51:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 23:48:32 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-sipcore-info-events-02 - Keith thread-index: AcpWrgbB5GKZ0NW4RPuwwYZ6ZxdH3wAPdBQw References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 29 Oct 2009 22:51:51.0650 (UTC) FILETIME=[678F0C20:01CA58EA] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-sipcore-info-events@tools.ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-info-events-02 - Keith X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 22:51:40 -0000 Hi Keith, I've collected the comments from all your e-mails into one single reply. I appretiate the numbering you've used, because it really made it easier to refer to other comments when needed. ----------- >1) General. Please write responses in the format "200 (OK)=20 >response" rather than "200 OK response". Fixed. I did the same for other response codes in the document also, e.g. 481 and 469. ----------- >2) General. Can we fix on the term of either "Info Package=20 >definition" or "Info Package specification" and use it=20 >consistently (in full) throughout where we mean that term. Fixed. Now there should only be "Info Package specification". ----------- =20 >3) Section 3.2 >=20 >A UA which supports the Info Package mechanism MUST indicate, using >the Revc-Info header field, the set of Info Packages for=20 >which it is willing to receive an INFO request. =20 > ^^^ >=20 >Insert "an" as indicated. The text is supposed to say "receive INFO requestS". ----------- >4) Section 3.2: >=20 >If a UA is not willing to receive INFO requests for any Info Packages, during > ^^^^^^^^ >dialog establishment or later during the INVITE dialog usage, the UA > ^^^^^^^ >MUST indicate this by including a Recv-Info header field with a 'nil' value. =20 >=20 >Insert "receive" as indicated. Fixed. >Replace "invite" with upper case as I believe this is the RFC 3261 convention. "invite dialog usage" is RFC 5057 terminology. ----------- >5) Section 3.2 indicates: >=20 > A UA MUST NOT send an INFO request associated with an Info Package > until it has received an indication that the remote UA is willing to > receive INFO requests for that Info Package, and a dialog has been > established with the remote UA. >=20 >and section 4.2 indicates: >=20 > For a specific dialog, a UA MUST NOT send INFO requests associated with Info Packages that the > remote UA has not indicated that it is willing to receive. >=20 >Are these not the same requirement. We need to eliminate one. I did the following: In section 3.2, which talks about *Info Packages*, we say that Info Packages must not be sent until an indication that the other entity wants to receive them has arrived. "For a specific dialog, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info Package" In section 4.2, which talks about the *INFO method*, we say that INFO can be sent once a (early-)dialog has been established. Because, that applies also to legacy INFO usage. And, since 4.2 already contains text which says that INFOs can be sent once the dialog has been established, I will remove the text You refered to above. ----------- >6) Section 3.2 indicates: >=20 > Likewise, even if a UA uses the Recv-Info header > field to indicate that it supports the Info Package mechanism, in > addition the UA MUST still also explicitly indicate support of the > INFO method using the Allow header field. >=20 >I do not believe this should be a MUST, because it is surely=20 >already a MUST in RFC 3261 - all we need to do is write an=20 >informative sentence that in accordance with RFC 3261 the=20 >Allow header also indicates INFO requests. I modified the text as below: "Likewise, even if a UA uses the Recv-Info header field to indicate that it=20 supports the Info Package mechanism, in addition the UA also indicates support=20 of the INFO method using the Allow method." The paragraph already earlier refers to 3261 for the Allow method, so I don't think we need it twice. ----------- =20 >7) Section 3.3: >=20 >3.3. Package Versioning >=20 > The Info Package mechanism does not support package versioning. > Specific Info Package payloads MAY contain version information, which > is handled by the applications associated with the Info Package, but > that is outside the scope of the Info Package mechanism. >=20 > NOTE: Even if an Info Package name contains version numbering (e.g. > foo_v2), the Info Package mechanism does not distinguish a version > number from the rest of the Info Package name. >=20 >As this is all part of the Info Package name, and needs to=20 >form part of the Info Package specification if used, I think=20 >all the text here should be moved to section 10.3, and this=20 >section header deleted. Fixed. ----------- >8) Section 4.3 indicates: >=20 > Info Package specifications MUST describe the application level > information associated with the Info Package. Each body part MUST > have a MIME type value, and the syntax and content of the body part, > defined. >=20 > Each body part, when associated with an Info Package, MUST have a > Content-Disposition header field with an 'Info-Package' value > assigned, in order to be able distinguish body parts associated with > the Info Package from other body parts. >=20 >Surely this is something where the MUST can only be met by=20 >the designer of the package, and therefore it belongs in section 10. Pending. As the whole section will change based on the body part discussion, I suggest that we come back to section 4.3 once the new text have been submitted. ----------- >9) Section 4.3: >=20 > NOTE: Some SIP functions that are orthogonal to INFO may=20 > insert body parts unrelated to the Info Package. >=20 >Change "may" to "can". Fixed. ----------- >10) Section 4.3: >=20 > However, when a body part in the INFO message is associated with an > Info Package, it MUST always have a Content-Disposition header field > with an 'Info-Package' value assigned. =20 >=20 >Is this not just a repeat of the requirement earlier in the=20 >section (1 paragraph before the note). Pending. See reply on comment 8. ----------- >11) Section 4.3: >=20 > This document does not define Info Package specific rules=20 > on how body parts associated with Info Packages are to be inserted=20 > into multipart body parts, and what type of multiparts are used. If an=20 > Info Package requires special rules regarding the usage of multipart body parts, > the specification for that Info Package MUST specify such rules. >=20 >The MUST here has to be in section 10. This paragraph needs=20 >to remove the requirement, and refer to section 10 instead. Pending. See reply on 8). ----------- >12) Section 4.4: >=20 > If a UA receives an INFO request for legacy usage, for=20 > which no Info-Package is associated (the INFO request does not contain an Info- > Package header field), the UA MUST send a 200 OK response. >=20 > The UAS MAY send other responses, such as Request Failure (4xx), > Server Failure (5xx) and Global Failure (6xx) as appropriate for the > request. >=20 >The second paragraph above contradicts the first above. I=20 >assume that means that there is a hidden condition that is=20 >missing from the first paragraph. Something along the lines=20 >of "that is otherwise syntactically correct and well structured". Fixed. I added the following text: "if the request is otherwise syntactically correct and well structured." I added the same text also to the paragraph above, which talks about 200 (OK) responses for I-P INFO requests. ----------- =20 > 13) Section 4.4: >=20 > If a UA receives an INFO request associated with an Info=20 > Package that the UA has not indicated willingness to receive, the UA MUST send a > 469 Bad INFO Package response Section 11.6. In the terminology of > Multiple Dialog Usages [RFC5057], this represents a Transaction Only > failure. >=20 >I assume that "(see Section 11.6)" or something similar is=20 >meant in the end of the first sentence.=20 Fixed. =20 >I believe we also need to define whether the response code=20 >applies to the transaction or the dialog. It obviously has to=20 >be the transaction. > >I do note the following text in 7.3 > >7.3. Dialog Fate Sharing > > As described in [RFC5057], an INFO request is always part of an > INVITE dialog usage. > > One needs to consider the fate of the dialog usage of an INFO request > is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. > >However as we have a specific new response code that represents a failure of the INFO method extension rather than any specific package, I believe the actions for 469 in respect of the dialog usage=20 >should be defined in this document. Pending. I initiated a dedicated e-mail thread on this issue. ----------- >14) Section 4.6: >=20 > The Info Package mechanism relies on the CSeq header field to detect > if an INFO request is received out of order. >=20 >Given that nowhere else in the document do we mention CSeq in=20 >this respect, I don't see how it can. I suspect we mean=20 >something more like >=20 > Many Info Packages can rely on the CSeq header field to detect > if an INFO request is received out of order. I modified the text as below: "The Info Package mechanism does not define a delivery order mechanism. Many Info Packages can rely on the CSeq header field to detect if an=20 INFO request is received out of order." ----------- >15) Section 4.6: >=20 > If specific applications need additional mechanisms for order of > delivery, those mechanisms, and related procedures, must=20 > be specified as part of the associated Info Package, and possible=20 > sequence numbers etc must be defined as application data. >=20 >Change "must be specified" to "are specified". If we need a=20 >real MUST, then it has to be in section 10 in any case, and I=20 >would expect more on this issue there. Fixed. ----------- >16) Section 6.2: >=20 > This document does not define values for Info-Package types. > Individual Info Package specifications define these values. Such > specifications MUST register the values with IANA. These=20 > values are Specification Required [RFC5226]. >=20 >The MUST part of this paragraph belongs in section 10. It is=20 >not something the implementor of the Inof-Package header=20 >field can directly comply with. I keept the 2 first sentences in 6.2: "This document does not define values for Info-Package types. Individual Info Package specifications define these values." ----------- =20 >17) Section 7.3: >=20 > One needs to consider the fate of the dialog usage of an=20 > INFO request is rejected. In some cases it may be acceptable that the whole > dialog usage is terminated, while in other cases is is desirable to > maintain the dialog usage. >=20 >Change "may" to "can". Fixed. ----------- >18) Section 8.2: >=20 > NOTE on the Recv-Info production: if the header field=20 > value is "nil", the header field MUST NOT contain any other=20 > Info Packages, and the SIP message MUST NOT contain more than=20 > one Recv-Info header field. >=20 >Please do not start a sentence containing RFC 2119 language=20 >with the word "Note". It confuses the hell out of people who=20 >understand that everything following that word is=20 >informative. In any case, the first half of this sentence is=20 >surely impossible in the ABNF and therefore the MUST is superfluous. I modified the text as below: "If a UA inserts a "nil" value in the Recv-Info header field, it MUST NOT indicate=20 additional Info-Packages." ----------- =20 >19) Section 9.3. >=20 > As described in Section 4, an INFO request associated with an Info > Package always contains an Info-Package header field. A=20 > legacy INFO request MUST NOT contain an Info-Package header field. >=20 >The first sentence of the above is fine. However the second=20 >sentence is not conformable by implementations of this=20 >specification. So I believe the "MUST" is incorrect and=20 >should be replaced by something more descriptive. I modified the text as below: "As described in Section 4, an INFO request associated with an Info Package always contains=20 an Info-Package header field. A UA MUST NOT insert an Info-Package header filed in a legacy INFO request." ----------- =20 >20) Section 10.1: >=20 > If an Info Package extends or modifies the behavior=20 > described in this document, it MUST be described in the definition=20 > for that Info Package. Info Package definitions should not repeat=20 > procedures defined in this specification, unless needed for clarification or > emphasis purpose. >=20 >Change "it MUST" to "that behaviour MUST" Fixed. >As for the second sentence, assuming that we do not mean an=20 >RFC 2119 SHOULD, which I believe we do not, reword as=20 >follows: "It is bad practice for Info Package defintions to=20 >repeat procedures defined in this specification, unless..." Fixed.=20 See my reply to comment 21). ----------- >21) Section 10.1: > > Info Packages MUST NOT weaken any behavior designated with "SHOULD" > or "MUST" in this specification. However, Info Packages MAY > strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" > strength if applications associated with the Info Package requires > it. >=20 >Do we mean "Info Packages" here or "Info Package Definitions"? (twice) "Info Package Definitions", which based on commet 2) now has become "Info Package Specifications" I modified the two paragraphs as below: "If an Info Package specification extends or modifies the behavior described in this document, that behaviour MUST be described in the specification for that Info Package. It is bad practice for Info Package specifications to repeat procedures defined in this document,=20 unless needed for clarification or emphasis purpose." "Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Packages definitions MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if applications associated with the Info Package requires it. ----------- =20 >22) Section 10.2: >=20 > Annex A provides more information, and describes alternative > mechanisms which one should consider for solving a=20 > specific use-case. >=20 > reword to: >=20 > Annex A provides more information, and describes alternative > mechanisms which are considered as part of the process for=20 > solving a specific use-case. Fixed. ----------- >23) Section 10.3 >=20 > The Info Package specification MUST define a for Info Package name > (e.g. "Info Package for X"). >=20 >Do we mean: >=20 > The Info Package specification MUST define an Info Package name > (e.g. "Info Package for X"). Fixed. ----------- >24) Section 10.3 >=20 > The specification MUST also define the header field value (e.g. > "infoX") to be used to indicate support of this package in=20 > the Recv-Info and Info-Package header fields. >=20 >Why do we allow the potential for a separate name for the=20 >package, and the value that appears in the header fields. I=20 >see this causing mixed usage in the IANA registrations.=20 >Surely it is simpler that whatever appears in the header=20 >fields is by definition the package name. It works for event=20 >packages surely. Pending. Someone else had this same comment. My reply was giving an example, that the name could be Something like "Info Package for DTMF transport", while the header field could be something like "infoDtmf" Having said that, the draft which defines the Info Package will of course have a name by default, so I can remove the text if it confuses people. But, then I think we should maybe also change the section name to "Recv-Info/Info-Package header field value", or something like that... ----------- =20 >25) Section 10.4 > > Note that Info Package parameters are only applicable for the Info > Package(s) for which they have been explicitly defined. They MUST > NOT be used for other Info Packages. >=20 >I don't think we need the MUST here. By virtue of the fact=20 >that the Info Package specification defines only one Info=20 >Package, it can only define parameters to be associated with=20 >one Info Package. Yes other packages may define a parameter=20 >with the same name, but we are not precluding that anyway. So=20 >turn the second sentence into something informative rather=20 >than RFC 2119. Pending. The current text was provided by someone, but I can think of some re-wording. But, I was actually wondering whether we should allow Info Packages to use parameters (not only the name, but also the semantics) defined in other Info Packages. So, instead of re-defining the same parameter, the package specification could simply refer to the Info Package specification which defines the parameter. I initiated a separate e-mail thread on this issue. ----------- >26) Section 10.4 >=20 > NOTE: Info Package parameters defined for specific Info=20 > Packages may share the name with parameters defined for other Info Packages, but > the parameter semantics are specific to the Info Package for which > they are defined. >=20 >Change "may" to "can". Fixed. ----------- >27) Section 10.5 >=20 > SIP option tags MUST conform to the SIP Change Process > [I-D.peterson-rai-rfc3427bis]. >=20 >I don't believe we need the MUST here. We merely need a=20 >sentence that "the registration requirements for option tags=20 >are defined in ...". As you have only made this an=20 >informative reference in any case, that surely has to happen. Fixed. ----------- >28) Section 10.6 >=20 > The Info Package specification MUST define what type of=20 > message body parts are associated with the Info Package, and MUST refer to > specifications where the syntax, semantics and MIME type of the > message body parts are described. >=20 >The text above appears to preclude the Info Package specification defining them itself. That is not the intention. I modified the text as below: "The Info Package specification MUST define what type of=20 message body parts are associated with the Info Package, and the specification MUST either define those body parts, or refer to specifications where the syntax, semantics and MIME type=20 of the body parts are described." ----------- >29) Section 10.7 >=20 > The specification MUST define whether there are SIP level > restrictions in the usage of the Info Package. For example, an Info > Package may require support of other SIP extensions (e.g. reliable > provisional responses). >=20 >Change "may" to "can". Fixed. ----------- >30) Section 10.7 >=20 > As the SIP stack may not be aware of Info Package specific > restrictions, it cannot be assumed that overlapping=20 > requests would be rejected. As defined in Section 4.4, in most cases a 200=20 > OK response will be sent for the INFO request. The application logic=20 > associated with the Info Package needs to handle situations which can=20 > occur due to overlapping requests. >=20 >Change "may not" to "might not". Fixed. ----------- >31) Section 10.9 >=20 > The Info Package specification MUST contain an IANA Considerations > section that includes definitions for the Info Package Name and, if > needed, supported MIME types. >=20 >I believe this is unduly onerous for Info Package definitions=20 >not published by IETF and goes beyond what we require for=20 >media feature tags. They need to fit their specification=20 >structure. I believe that all we need to say is that the=20 >registration requirements for IANA need to be readily=20 >identifiable to IANA by including them in a single part of=20 >the document to which IANAs attention is drawn at the time of=20 >the registration request. Pending. Could you provide some text, please? ----------- >32) Section 10.11 >=20 > The Info Package specification SHOULD contain a description of the > application procedures associated with the Info Package, or > alternatively refer to application procedures defined elsewhere. >=20 >This SHOULD is inconsistent with section 4.3 which contains: >=20 > Info Package specifications MUST describe the application level > information associated with the Info Package. =20 >=20 >I believe the MUST is correct. I modified the text in section 4.3 to more informative, as below: "Info Package specifications describe the application level=20 information associated with the Info Package, and the syntax, content and MIME value of the body parts associated with the Info Package." I modified the text in 10.10, by replacing SHOULD with MUST, as below: "The Info Package specification MUST contain a description of the application=20 procedures associated with the Info Package, or alternatively refer to application=20 procedures defined elsewhere." ----------- =20 >33) Section 1: > > Use of the INFO method does not constitute a separate dialog usage. > INFO messages are always part of, and share the fate of, an invite > dialog usage [RFC5057]. INFO messages cannot be sent as part of > other dialog usages. > >Replace "invite" with upper case as I believe this is the RFC 3261 convention. See my reply to comment 4). ----------- >34) Section 3.2: > > The indication of Info Packages can take place during the dialog > establishment, and during a target refresh. This includes INVITE, > UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx > only). Note that the UAC is not required to indicate its set of Info > Packages in the initial INVITE request. > >This I guess supports the text in the table in section 6.1: > > >Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR >----------------------------------------------------------------------- - >Info-Package R - - - - - - - m* - - - - - >Recv-Info R o - - o o o o - - o - - - >Recv-Info 2xx o - - o o - o - - o - - - >Recv-Info 1xx o - - o o - o - - o - - - >Recv-Info r o - - - o - o - - o - - - > >but this leaves a lot of open questions in my mind as to the support of the Recv-Info header in various methods, as follows: > >- what is the purpose in the REGISTER request, and does this have any impact on a future dialog usage? Does it indicate willingness to support in all future INVITE dialogs. In the absence of any=20 >further text in the document I would rather take it out. If there really is some future usage, then we need more text in the document that just the appearance in the table. There is some text about REGISTER in Section 3.4. >- can't REFER or SUBSCRIBE be used as a target refresh request within an INVITE dialog usage. I don't particularly want to add a usage, but I think this points to a lack of precision of the section=20 >3.2 text, which in some ways I would like to contain RFC 2119 language as well. We used to have REFER and SUBSCRIBE there, but I was asked to remove it. >I think personally I would prefer to limit the Recv-Info header usage to only the INVITE transaction and the UPDATE=20 >transaction and be very precise on that. I see no real use for its appearance in PRACK, ACK. This was discussed a long time ago, and I think people said that we more or less should have the same options as we have for sending SDP. >- section 3.2 needs to deal with the OPTIONS usage, which I think is valid. Section 3.5 talks about OPTIONS. Do you want me to move 3.5 (and 3.4, I assume) as subsections to 3.2? - if we have a 4xx - 6xx response to a reINVITE, why is the support different that that for an UPDATE? It is not. I have updated the table based on different feedback that I received, and it now looks like: ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR ------------------------------------------------------------------------ Info-Package R - - - - - - - m* - - - - - Recv-Info R o - - o m o o - - o - - - Recv-Info 2xx - - - o m - o - - o - - - Recv-Info 1xx - - - o - - - - - - - - - Recv-Info 469 - - - - - - - m* - - - - - Recv-Info r - - - o o - o - - o - - - =09 The support and usage of the Info-Package and Recv-Info header fields is not applicalbe to UAs that only support legacy INFO usages. =09 * The usage of the Info-Package header field is not applicalbe to INFO requests and responses=20 associated with legacy INFO usages. Pending. Note that the table may still change, based on the outcome on the ongoing e-mail discussion related to for which methods the Recv-Info header can be used. ------------ >35) Section 5.1: > >For the supported header field tables I see no listing for the following headers: I should have supported Dean on getting rid of these tables.... ;) >- Is a 415 response to INFO allowed containing the Accept header field? Fixed. "Accept 415 o" I think it should be allowed. It's for sure useful for body parts associated with legacy INFO usages. >- Allow-Events (which I think is like Allow and appears in all requests and 2xx responses). As far as I understand it only appears in requests (and their responses) which initiates dialogs, and OPTIONS. See section 3.3.7 of RFC 3265 (I assume 3265bis doesn't change that). >- Referred-By header (again which I thought could appear in all methods). Fixed. "Referred-By R o" I guess nothing prevents one from using REFER to trigger an INFO in another dialog, so... >- Request-Disposition (again all methods). Fixed. "Request-Disposition R o" I am not really sure what it would be used for in a mid-dialog request, but since 3841 allows it in with any method.... >- Geolocation-Error (all responses). Fixed. "Geolocation-Error r o" >- Resource-Priority (allowed in all requests and responses, and needed if priority is applied on a per transaction basis rather than set for the entire dialog, which is one of the options in RFC=20 >4412). Fixed. "Resource-Priority o" >- Accept-Resource-Priority in 2xx and 417 responses. Fixed. "Accept-Resource-Priority 2xx,417 o" >I would also comment on the following for which entries appear. > >- Organization. Given the semantics of this, it would be the same as appears in the original INVITE that created the dialog. The use case mentioned in RFC 3261 does not apply to subsequent requests=20 >within a dialog. Moreover I think it is harmful if people think they can use this header to carry information that really belongs in the application. Therefore I would exclude it. Fixed. "Organization -" >- Allow. RFC3261 allows this in all responses according to my interpretation, rather than specifically 2xx and 405 (which I agree do get special mention). The entry for a 405 response should be m=20 >as it is mandatory, but o for all other responses. Fixed. "Allow R o Allow 405 m Allow r o" >- Privacy. Listed for requests only. I have an understanding that this is also allowed in responses. Fixed. "Privacy o" >- Reason. Listed for responses only. Currently it is allowed in requests (BYE and CANCEL in particular) and not responses. There are proposals to extend it to responses but they have not been=20 >adopted yet. I suspect the use cases for this header field in INFO are pretty much non-existent in any case. Fixed. "Reason R o" >- Can I check that the Accept header field is not needed for 2xx responses. RFC 3261 provides for its usage in certain methods, but I am not sure about whether there is a use case in INFO. See above. At least for legacy INFO usages it is needed, and I guess someone could also insert an unsupported body part type for an Info Package even if the package doesn't allow it. >- Proxy-Authenticate. I though was also allowed for a 401 response as well as a 407 response. Fixed. "Proxy-Authenticate 401 m" According to 3261 it is "m" for 401 and "o" for 407. >- Does the Retry-After header also apply to 413 responses and 500 responses, or are these responses not valid for INFO. Fixed. "Retry-After 404,413,480,486 o Retry-After 500,503 o Retry-After 600,603 o" In my opinion they apply also to INFO. -------------- >36) Subclause 6.1. The table specifies: > >Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR >----------------------------------------------------------------------- - >Info-Package R - - - - - - - m* - - - - - >Recv-Info R o - - o o o o - - o - - - >Recv-Info 2xx o - - o o - o - - o - - - >Recv-Info 1xx o - - o o - o - - o - - - >Recv-Info r o - - - o - o - - o - - - > >But section 3.1 lists: > > A UA which supports the Info Package mechanism MUST indicate, using > the Revc-Info header field, the set of Info Packages for which it is > willing to receive INFO request. A UA can list multiple Info > Packages in a single Recv-Info header field, and the UA can use > multiple Recv-Info header fields. > >and > > If a UA is not willing to receive INFO requests for any Info Packages, during > dialog establishment or later during the invite INVITE dialog usage, the UA > MUST indicate this by including a Recv-Info header field with a 'nil' > value. This informs other UAs that the UA still supports the Info > Package mechanism. > >Even if I only support legacy usage, I don't seem to find any text that waives the requirement for implementations that support this i-d to support the Recv-Info requirements. It is only the=20 >implementations that support and are conformant to RFC 2976 that will not include this header field. That means that if Recv-Info is allowed in a message, and I support this extension, I must include the=20 >header field, even if its value is "nil". Surely that would make all the entries in the table above "m". See the text below the new table I showed in my reply to comment 34). Regards, Christer From pkyzivat@cisco.com Thu Oct 29 17:03:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D633A68AD; Thu, 29 Oct 2009 17:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEESwEVAX3Kj; Thu, 29 Oct 2009 17:03:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D78533A67FC; Thu, 29 Oct 2009 17:03:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANbJ6UpAZnwN/2dsb2JhbACEcsIXhxKRGoEygjhTBA X-IronPort-AV: E=Sophos;i="4.44,649,1249257600"; d="scan'208";a="65583383" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Oct 2009 00:03:16 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9U03G1B027615; Fri, 30 Oct 2009 00:03:16 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 20:03:16 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 20:03:16 -0400 Message-ID: <4AEA2D45.4030104@cisco.com> Date: Thu, 29 Oct 2009 20:03:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Thomson, Martin" References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> <4AE99986.9070305@cisco.com> <8B0A9FCBB9832F43971E38010638454F0F2519F6@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0F2519F6@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2009 00:03:16.0306 (UTC) FILETIME=[6169AB20:01CA58F4] Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 00:03:02 -0000 Martin, I pretty much agree. There may be other considerations if the deref'ed answer varies with time. If the server always derefs, then for the watcher to get a new value it must query the server again. If the watcher gets a reference frmo the server, then it can query the source. Is that a useful distinction? Probably not, and least not often. The work of doing so will probably not be that different for the watcher, except it may get back more data than it wants. In the interest of simplicity, I think the distinction can be ignored. Thanks, Paul Thomson, Martin wrote: > Hi Paul, > > That's an excellent summary of the stakeholders. > > Source > | \ > ?| \ ? > | \ > Publisher/ --- Server --- Watcher > Presentity (PA) > > Assuming that the publisher wants to do the dereference (and they are able to [1]), we have nothing further to do. We don't need to build a mechanism. The publisher can implement this policy as they see fit. > > So, the presentity publishes a reference to the presence server. > > The pertinent questions are: > > (A) does the presentity have any say in where the reference is resolved? > > (B) does the watcher have any say in where the reference is resolved? > > Any preference for (A) is expressed in a PUBLISH and that any preference for (B) is expressed in a SUBSCRIBE (most probably). Obviously, the server has the final say: it can choose to pass the reference on - forcing the watcher to dereference - or it can do the dereference itself. > > So, why would the publisher ask the server to dereference? Maybe it knows something of the watchers, or maybe it wants to protect the reference (c.f. location URIs and the possession model). That second reason is a good reason to have a means to fail the publish if the server is unwilling or unable. The Require header I proposed does this, but there might be other ways to achieve the same effect. > > So why would the watcher ask the server to dereference? The simplest reason is: it doesn't want to do the work itself. > > Why would the server not want to dereference? The idea that it doesn't want the extra work doesn't really fit with it being a presence server. After all, a large part of its reason for being is to offload work from watcher and publisher. > > So, all this more or less leads me to think that having the server dereference is the most sensible option. Obviously, server policy can override this or the server might be unable to dereference. > > I do think that it might make sense to have an option where the server failing to dereference doesn't prevent the watcher from attempting to do so. If the server doesn't support the feature, the server decides not dereference, or the server encounters an error while trying, ... then the reference is passed on the watcher. > > That leads me to conclude that there is no benefit in having the watcher request that a reference is resolved. If the watcher receives a reference, it knows that there's nothing it could have done to have this dereferenced for it. > > Cheers, > --Martin > > [1] This isn't always the case: , though for many presence use cases I doubt it will be a factor. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, 30 October 2009 12:33 AM >> To: Thomson, Martin >> Cc: James M. Polk; Miguel A. Garcia; geopriv@ietf.org; sipcore@ietf.org >> Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish >> >> I agree that this is something where a general solution would be >> preferable. >> >> There are a number of parties involved in this: >> - the publisher >> - the presence server >> - the watcher >> - the true source of the information >> >> (Some of the above may be collocated.) >> >> If there is a deref to be done, it can potentially be done in any of >> those places, except the source. The *policy* about where it should be >> done might also be set in any of those places. And there are competing >> interests about that. For instance: >> >> - the source wants to minimize derefs. Depending on the particular >> data and the typical access patterns for that data, choosing a >> particular one of the other parties to do the deref may minimize >> the number of derefs. (But probably the source has too little info >> about the usage to make the choice even if it could.) >> >> - the publisher, if it isn't collocated with the source, may want >> to delegate the deref to save itself work. >> >> - the presence server may also want to delegate the deref to either >> the publisher or the watcher to save itself work. But in other >> cases its role in life is to offload the publisher and the watcher, >> so it might be willing to take on the work. >> >> - the watcher also may want to delegate this work to one of the >> other parties to offload itself. But in other cases it may *want* >> the opportunity to do the deref itself so that it can get more >> timely values than it would otherwise. >> >> So, I think general solution is going to require some sort of >> negotiation between all the parties about who assumes this >> responsibility. Seems like an interesting and non-trivial problem. >> >> Thanks, >> Paul >> >> Thomson, Martin wrote: >>> Hi James, >>> >>>> This to, can be added to SIP Location Conveyance (if the SIPCORE WG >>>> agrees with this addition). >>> Aside from a very strong desire to see the end of SIP location >> conveyance, all the authors on this document are in strong agreement >> that a location-specific solution is not desirable. >>>> And when you reach consensus on the requirement to send a watcher >> the >>>> location URI instead of a location value, that will need to be >>>> indicated with further work. >>> This is sensible. I tend to agree that we want to have the presence >> agent able to do the dereference. In many cases, the watcher wont be >> interested in doing this themselves. This is just one aspect we need >> to consider in the solution. >>> For instance, if we extend PIDF, a presence agent that doesn't >> support the extension would pass the reference onward unaware of its >> special status. That might be a desirable attribute of a solution. >> Alternatively, we could provide a different body. >>> Miguel and I are currently debating options. We're still trying to >> come to a common understanding on this point. About all we agree on >> right now is that this reference will sit in the body of the SIP >> PUBLISH and that it will not be location-specific. These are both >> reasons against using Geolocation, which is unfortunate in a way >> because it has a lot of the semantics we're looking for. >>> Once we've sorted out the basics, maybe we can see how the >> Geolocation header fits. >>>> As stated above, I believe you are wanting a default action for the >>>> PS to dereference >>> Actually, as Miguel says, the options are still largely open. But I >> certainly think that having the presence agent able to dereference is a >> desirable feature. This might be: always dereference, dereference >> based on presence agent policy, dereference at the request of the >> presentity, or a combination of these. >>> --Martin >>> >>>> James >>>> >>>> >>>> >>>> >>>>> /Miguel >>>>> >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > From Martin.Thomson@andrew.com Thu Oct 29 17:24:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB6E3A68AD; Thu, 29 Oct 2009 17:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDbxBKUlkLpJ; Thu, 29 Oct 2009 17:24:56 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BF80A3A67FC; Thu, 29 Oct 2009 17:24:55 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:7569 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S69466AbZJ3AZK (ORCPT + 1 other); Thu, 29 Oct 2009 19:25:10 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 29 Oct 2009 19:25:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 30 Oct 2009 08:25:07 +0800 From: "Thomson, Martin" To: Paul Kyzivat Date: Fri, 30 Oct 2009 08:25:32 +0800 Thread-Topic: [sipcore] draft-garcia-geopriv-indirect-publish Thread-Index: AcpY9GWdlHDcJsnUQ3OGtz5BP/YojAAARuxQ Message-ID: <8B0A9FCBB9832F43971E38010638454F0F251A17@SISPE7MB1.commscope.com> References: <4AE555C3.9000109@ericsson.com> <4AE6B7FE.4090505@ericsson.com> <8B0A9FCBB9832F43971E38010638454F0F251876@SISPE7MB1.commscope.com> <4AE99986.9070305@cisco.com> <8B0A9FCBB9832F43971E38010638454F0F2519F6@SISPE7MB1.commscope.com> <4AEA2D45.4030104@cisco.com> In-Reply-To: <4AEA2D45.4030104@cisco.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 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 00:24:57 -0000 VGhpcyBpcyBzb21ldGhpbmcgdGhhdCB3aWxsIG5lZWQgdG8gYmUgZGVhbHQgd2l0aCBzb21laG93 LiAgQWZ0ZXIgYWxsLCBpZiB3ZSdyZSB0YWxraW5nIGxvY2F0aW9uLCB0aGVuIGl0IGRvZXMgY2hh bmdlLg0KDQpUaGF0J3MgYWN0dWFsbHkgYSBtb3RpdmF0aW9uIGZvciBkb2luZyB0aGlzOiB0aGUg cHJlc2VudGl0eS9wdWJsaXNoZXIgZG9lc24ndCB3YW50IHRvIGRlYWwgd2l0aCBjaGFuZ2luZyB2 YWx1ZXMgYW5kIGhhdmluZyB0byBjb250aW51YWxseSBwdWJsaXNoLiAgRm9yIG9uZSwgaXQgbWln aHQgYmUgcG9pbnRsZXNzIGJlY2F1c2Ugbm9uZSBvZiB0aGVpciB3YXRjaGVycyBhcmUgZXZlbiBp bnRlcmVzdGVkIGluIHRoZSB1cGRhdGVzLg0KDQpUaGUgImRlcmVmZXJlbmNlIiBvcGVyYXRpb24g Y291bGQgYmUgc29tZXRoaW5nIHF1aXRlIHNvcGhpc3RpY2F0ZWQsIGxpa2UgYSBwcmVzZW5jZSBz dWJzY3JpcHRpb24uICBUaGF0J3MgYWxsIHVwIHRvIHRoZSBwcmVzZW5jZSBzZXJ2ZXIuICBJdCBo YXMgYSBudW1iZXIgb2Ygb3B0aW9uczoNCg0KIC0gRGVyZWZlcmVuY2Ugb24gcHVibGlzaCwgd2hp Y2ggZXF1aXZhbGVudCBpbiBtYW55IHJlc3BlY3RzIHRvIGhhdmluZyB0aGUgcHJlc2VudGl0eSBk byB0aGUgZGVyZWZlcmVuY2UsIHNvIHRoaXMgYWRkcyBsaXR0bGUgdmFsdWUNCg0KIC0gRGVyZWZl cmVuY2Ugb24gdXBkYXRlLCB3aGVyZSB0aGUgaW5mb3JtYXRpb24gaXMgcmV0cmlldmVkIGVhY2gg dGltZSBhIHdhdGNoZXIgc3Vic2NyaWJlcw0KDQogLSBEZXJlZmVyZW5jZSBiYXNlZCBvbiBpbmZv cm1hdGlvbiBpbiB0aGUgcmV0cmlldmVkIHByZXNlbmNlIGRhdGEsIHN1Y2ggYXMgZXhwaXJ5IHRp bWVzIG9yIHRpbWVzdGFtcHMNCg0KIC0gRGVyZWZlcmVuY2UgcGVyaW9kaWNhbGx5LCB3aGVyZSB0 aGUgdGltZSBpcyBiYXNlZCBvbiBsb2NhbCBwb2xpY3kgb3IgYmFzZWQgb24gdGhlIGludGVydmFs cyBwcm92aWRlZCBieSB3YXRjaGVycw0KDQogLSBEZXJlZmVyZW5jZSBtb3JlIGludGVsbGlnZW50 bHkgYnkgY29uc2lkZXJpbmcgZXZlbnQtcmF0ZSBjb250cm9scyBmcm9tIHdhdGNoZXJzLCB0aGUg ZmlsdGVycyB0aGF0IHRoZXkgcHJvdmlkZSBhbmQgY29uc29saWRhdGUgYWxsIHRoZXNlIGludG8g dGhlIG9uZSBzdWJzY3JpcHRpb24gKGFzc3VtaW5nIHRoYXQgdGhpcyBpcyBwb3NzaWJsZSwgc2F5 IHRoZSByZWZlcmVuY2UgaXMgYSBwcmVzOiBVUkkpIG9yIGVpdGhlciBhdHRlbXB0IHRvIHBvbGwg aW4gYW4gb3B0aW11bSB3YXkgdG8gbWVldCB0aGVzZSB0YXJnZXRzDQoNCk9idmlvdXNseSwgdGhl cmUgYXJlIHF1aXRlIGEgbnVtYmVyIG9mIHdheXMgdGhpcyBjb3VsZCBiZSBkb25lLiAgT2J2aW91 c2x5LCB0aGUgb3B0aW9ucyB0aGF0IGFyZSBtb3JlIGVmZmljaWVudCBhbmQgcHJvdmlkZSBhIGJl dHRlciB2aWV3IG9mIHRoZSBwcmVzZW5jZSBzdGF0ZSB0byB3YXRjaGVycyBhcmUgbW9yZSBkaWZm aWN1bHQgdG8gaW1wbGVtZW50Lg0KDQpJJ20gaGFwcHkgdG8gbGV0IHRoZSBwcmVzZW5jZSBzZXJ2 ZXIgZGVjaWRlIG9uIHdoYXQgdG8gZG8sIGJ1dCB3ZSBzaG91bGQgcHJvYmFibHkgaGF2ZSBzb21l IHNvcnQgb2YgZGlzY3Vzc2lvbiBpbiB0aGUgZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIGNob2lj ZXMgdGhhdCBhcmUgYXZhaWxhYmxlIGFuZCBzb21lIG9mIHRoZSBpbXBsaWNhdGlvbnMgb2YgZWFj aC4gIFRoYXQgc2hvdWxkIGJlIHN1ZmZpY2llbnQuICANCg0KR2l2aW5nIHRoZSBwcmVzZW50aXR5 L3B1Ymxpc2hlciBvciB3YXRjaGVyIGEgbWVhbnMgdG8gY29udHJvbCB0aGlzIGRvZXNuJ3Qgc2Vl bSBoZWxwZnVsIC0gZm9yIHRoZSB3YXRjaGVyLCB0aGV5IGNhbiB1c2Ugc3Vic2NyaXB0aW9uIGV2 ZW50IHJhdGUgY29udHJvbCBhbmQgZmlsdGVycyB0byBpbmZsdWVuY2UgdGhlIHNlcnZlciwgYnV0 IGl0J3MgdXAgdG8gdGhlIHByZXNlbmNlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhbmQgcG9saWN5 IGhvdyB0aG9zZSBhcmUgYWN0ZWQgdXBvbi4NCg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNp c2NvLmNvbV0NCj4gU2VudDogRnJpZGF5LCAzMCBPY3RvYmVyIDIwMDkgMTE6MDMgQU0NCj4gVG86 IFRob21zb24sIE1hcnRpbg0KPiBDYzogSmFtZXMgTS4gUG9sazsgTWlndWVsIEEuIEdhcmNpYTsg Z2VvcHJpdkBpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIGRyYWZ0LWdhcmNpYS1nZW9wcml2LWluZGlyZWN0LXB1Ymxpc2gNCj4gDQo+IE1hcnRpbiwN Cj4gDQo+IEkgcHJldHR5IG11Y2ggYWdyZWUuDQo+IFRoZXJlIG1heSBiZSBvdGhlciBjb25zaWRl cmF0aW9ucyBpZiB0aGUgZGVyZWYnZWQgYW5zd2VyIHZhcmllcyB3aXRoDQo+IHRpbWUuIElmIHRo ZSBzZXJ2ZXIgYWx3YXlzIGRlcmVmcywgdGhlbiBmb3IgdGhlIHdhdGNoZXIgdG8gZ2V0IGEgbmV3 DQo+IHZhbHVlIGl0IG11c3QgcXVlcnkgdGhlIHNlcnZlciBhZ2Fpbi4gSWYgdGhlIHdhdGNoZXIg Z2V0cyBhIHJlZmVyZW5jZQ0KPiBmcm1vIHRoZSBzZXJ2ZXIsIHRoZW4gaXQgY2FuIHF1ZXJ5IHRo ZSBzb3VyY2UuDQo+IA0KPiBJcyB0aGF0IGEgdXNlZnVsIGRpc3RpbmN0aW9uPyBQcm9iYWJseSBu b3QsIGFuZCBsZWFzdCBub3Qgb2Z0ZW4uDQo+IFRoZSB3b3JrIG9mIGRvaW5nIHNvIHdpbGwgcHJv YmFibHkgbm90IGJlIHRoYXQgZGlmZmVyZW50IGZvciB0aGUNCj4gd2F0Y2hlciwgZXhjZXB0IGl0 IG1heSBnZXQgYmFjayBtb3JlIGRhdGEgdGhhbiBpdCB3YW50cy4NCj4gDQo+IEluIHRoZSBpbnRl cmVzdCBvZiBzaW1wbGljaXR5LCBJIHRoaW5rIHRoZSBkaXN0aW5jdGlvbiBjYW4gYmUgaWdub3Jl ZC4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPiBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6 DQo+ID4gSGkgUGF1bCwNCj4gPg0KPiA+IFRoYXQncyBhbiBleGNlbGxlbnQgc3VtbWFyeSBvZiB0 aGUgc3Rha2Vob2xkZXJzLg0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICBTb3VyY2UNCj4gPiAg ICAgICAgICAgICAgICAgICAgIHwgIFwNCj4gPiAgICAgICAgICAgICAgICAgICAgP3wgICAgXCA/ DQo+ID4gICAgICAgICAgICAgICAgICAgICB8ICAgICAgXA0KPiA+ICAgUHVibGlzaGVyLyAtLS0g U2VydmVyIC0tLSBXYXRjaGVyDQo+ID4gICBQcmVzZW50aXR5ICAgICAgKFBBKQ0KPiA+DQo+ID4g QXNzdW1pbmcgdGhhdCB0aGUgcHVibGlzaGVyIHdhbnRzIHRvIGRvIHRoZSBkZXJlZmVyZW5jZSAo YW5kIHRoZXkgYXJlDQo+IGFibGUgdG8gWzFdKSwgd2UgaGF2ZSBub3RoaW5nIGZ1cnRoZXIgdG8g ZG8uICBXZSBkb24ndCBuZWVkIHRvIGJ1aWxkIGENCj4gbWVjaGFuaXNtLiAgVGhlIHB1Ymxpc2hl ciBjYW4gaW1wbGVtZW50IHRoaXMgcG9saWN5IGFzIHRoZXkgc2VlIGZpdC4NCj4gPg0KPiA+IFNv LCB0aGUgcHJlc2VudGl0eSBwdWJsaXNoZXMgYSByZWZlcmVuY2UgdG8gdGhlIHByZXNlbmNlIHNl cnZlci4NCj4gPg0KPiA+IFRoZSBwZXJ0aW5lbnQgcXVlc3Rpb25zIGFyZToNCj4gPg0KPiA+ICAo QSkgZG9lcyB0aGUgcHJlc2VudGl0eSBoYXZlIGFueSBzYXkgaW4gd2hlcmUgdGhlIHJlZmVyZW5j ZSBpcw0KPiByZXNvbHZlZD8NCj4gPg0KPiA+ICAoQikgZG9lcyB0aGUgd2F0Y2hlciBoYXZlIGFu eSBzYXkgaW4gd2hlcmUgdGhlIHJlZmVyZW5jZSBpcw0KPiByZXNvbHZlZD8NCj4gPg0KPiA+IEFu eSBwcmVmZXJlbmNlIGZvciAoQSkgaXMgZXhwcmVzc2VkIGluIGEgUFVCTElTSCBhbmQgdGhhdCBh bnkNCj4gcHJlZmVyZW5jZSBmb3IgKEIpIGlzIGV4cHJlc3NlZCBpbiBhIFNVQlNDUklCRSAobW9z dCBwcm9iYWJseSkuDQo+IE9idmlvdXNseSwgdGhlIHNlcnZlciBoYXMgdGhlIGZpbmFsIHNheTog aXQgY2FuIGNob29zZSB0byBwYXNzIHRoZQ0KPiByZWZlcmVuY2Ugb24gLSBmb3JjaW5nIHRoZSB3 YXRjaGVyIHRvIGRlcmVmZXJlbmNlIC0gb3IgaXQgY2FuIGRvIHRoZQ0KPiBkZXJlZmVyZW5jZSBp dHNlbGYuDQo+ID4NCj4gPiBTbywgd2h5IHdvdWxkIHRoZSBwdWJsaXNoZXIgYXNrIHRoZSBzZXJ2 ZXIgdG8gZGVyZWZlcmVuY2U/ICBNYXliZSBpdA0KPiBrbm93cyBzb21ldGhpbmcgb2YgdGhlIHdh dGNoZXJzLCBvciBtYXliZSBpdCB3YW50cyB0byBwcm90ZWN0IHRoZQ0KPiByZWZlcmVuY2UgKGMu Zi4gbG9jYXRpb24gVVJJcyBhbmQgdGhlIHBvc3Nlc3Npb24gbW9kZWwpLiAgVGhhdCBzZWNvbmQN Cj4gcmVhc29uIGlzIGEgZ29vZCByZWFzb24gdG8gaGF2ZSBhIG1lYW5zIHRvIGZhaWwgdGhlIHB1 Ymxpc2ggaWYgdGhlDQo+IHNlcnZlciBpcyB1bndpbGxpbmcgb3IgdW5hYmxlLiAgVGhlIFJlcXVp cmUgaGVhZGVyIEkgcHJvcG9zZWQgZG9lcw0KPiB0aGlzLCBidXQgdGhlcmUgbWlnaHQgYmUgb3Ro ZXIgd2F5cyB0byBhY2hpZXZlIHRoZSBzYW1lIGVmZmVjdC4NCj4gPg0KPiA+IFNvIHdoeSB3b3Vs ZCB0aGUgd2F0Y2hlciBhc2sgdGhlIHNlcnZlciB0byBkZXJlZmVyZW5jZT8gIFRoZSBzaW1wbGVz dA0KPiByZWFzb24gaXM6IGl0IGRvZXNuJ3Qgd2FudCB0byBkbyB0aGUgd29yayBpdHNlbGYuDQo+ ID4NCj4gPiBXaHkgd291bGQgdGhlIHNlcnZlciBub3Qgd2FudCB0byBkZXJlZmVyZW5jZT8gIFRo ZSBpZGVhIHRoYXQgaXQNCj4gZG9lc24ndCB3YW50IHRoZSBleHRyYSB3b3JrIGRvZXNuJ3QgcmVh bGx5IGZpdCB3aXRoIGl0IGJlaW5nIGEgcHJlc2VuY2UNCj4gc2VydmVyLiAgQWZ0ZXIgYWxsLCBh IGxhcmdlIHBhcnQgb2YgaXRzIHJlYXNvbiBmb3IgYmVpbmcgaXMgdG8gb2ZmbG9hZA0KPiB3b3Jr IGZyb20gd2F0Y2hlciBhbmQgcHVibGlzaGVyLg0KPiA+DQo+ID4gU28sIGFsbCB0aGlzIG1vcmUg b3IgbGVzcyBsZWFkcyBtZSB0byB0aGluayB0aGF0IGhhdmluZyB0aGUgc2VydmVyDQo+IGRlcmVm ZXJlbmNlIGlzIHRoZSBtb3N0IHNlbnNpYmxlIG9wdGlvbi4gIE9idmlvdXNseSwgc2VydmVyIHBv bGljeSBjYW4NCj4gb3ZlcnJpZGUgdGhpcyBvciB0aGUgc2VydmVyIG1pZ2h0IGJlIHVuYWJsZSB0 byBkZXJlZmVyZW5jZS4NCj4gPg0KPiA+IEkgZG8gdGhpbmsgdGhhdCBpdCBtaWdodCBtYWtlIHNl bnNlIHRvIGhhdmUgYW4gb3B0aW9uIHdoZXJlIHRoZQ0KPiBzZXJ2ZXIgZmFpbGluZyB0byBkZXJl ZmVyZW5jZSBkb2Vzbid0IHByZXZlbnQgdGhlIHdhdGNoZXIgZnJvbQ0KPiBhdHRlbXB0aW5nIHRv IGRvIHNvLiAgSWYgdGhlIHNlcnZlciBkb2Vzbid0IHN1cHBvcnQgdGhlIGZlYXR1cmUsIHRoZQ0K PiBzZXJ2ZXIgZGVjaWRlcyBub3QgZGVyZWZlcmVuY2UsIG9yIHRoZSBzZXJ2ZXIgZW5jb3VudGVy cyBhbiBlcnJvciB3aGlsZQ0KPiB0cnlpbmcsIC4uLiB0aGVuIHRoZSByZWZlcmVuY2UgaXMgcGFz c2VkIG9uIHRoZSB3YXRjaGVyLg0KPiA+DQo+ID4gVGhhdCBsZWFkcyBtZSB0byBjb25jbHVkZSB0 aGF0IHRoZXJlIGlzIG5vIGJlbmVmaXQgaW4gaGF2aW5nIHRoZQ0KPiB3YXRjaGVyIHJlcXVlc3Qg dGhhdCBhIHJlZmVyZW5jZSBpcyByZXNvbHZlZC4gIElmIHRoZSB3YXRjaGVyIHJlY2VpdmVzDQo+ IGEgcmVmZXJlbmNlLCBpdCBrbm93cyB0aGF0IHRoZXJlJ3Mgbm90aGluZyBpdCBjb3VsZCBoYXZl IGRvbmUgdG8gaGF2ZQ0KPiB0aGlzIGRlcmVmZXJlbmNlZCBmb3IgaXQuDQo+ID4NCj4gPiBDaGVl cnMsDQo+ID4gLS1NYXJ0aW4NCj4gPg0KPiA+IFsxXSBUaGlzIGlzbid0IGFsd2F5cyB0aGUgY2Fz ZTogPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiBpZXRmLWVjcml0LXJvdWdo LWxvYz4sIHRob3VnaCBmb3IgbWFueSBwcmVzZW5jZSB1c2UgY2FzZXMgSSBkb3VidCBpdA0KPiB3 aWxsIGJlIGEgZmFjdG9yLg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0NCj4gPj4g U2VudDogRnJpZGF5LCAzMCBPY3RvYmVyIDIwMDkgMTI6MzMgQU0NCj4gPj4gVG86IFRob21zb24s IE1hcnRpbg0KPiA+PiBDYzogSmFtZXMgTS4gUG9sazsgTWlndWVsIEEuIEdhcmNpYTsgZ2VvcHJp dkBpZXRmLm9yZzsNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIGRyYWZ0LWdhcmNpYS1nZW9wcml2LWluZGlyZWN0LXB1Ymxpc2gNCj4gPj4NCj4gPj4gSSBh Z3JlZSB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIHdoZXJlIGEgZ2VuZXJhbCBzb2x1dGlvbiB3b3Vs ZCBiZQ0KPiA+PiBwcmVmZXJhYmxlLg0KPiA+Pg0KPiA+PiBUaGVyZSBhcmUgYSBudW1iZXIgb2Yg cGFydGllcyBpbnZvbHZlZCBpbiB0aGlzOg0KPiA+PiAtIHRoZSBwdWJsaXNoZXINCj4gPj4gLSB0 aGUgcHJlc2VuY2Ugc2VydmVyDQo+ID4+IC0gdGhlIHdhdGNoZXINCj4gPj4gLSB0aGUgdHJ1ZSBz b3VyY2Ugb2YgdGhlIGluZm9ybWF0aW9uDQo+ID4+DQo+ID4+IChTb21lIG9mIHRoZSBhYm92ZSBt YXkgYmUgY29sbG9jYXRlZC4pDQo+ID4+DQo+ID4+IElmIHRoZXJlIGlzIGEgZGVyZWYgdG8gYmUg ZG9uZSwgaXQgY2FuIHBvdGVudGlhbGx5IGJlIGRvbmUgaW4gYW55IG9mDQo+ID4+IHRob3NlIHBs YWNlcywgZXhjZXB0IHRoZSBzb3VyY2UuIFRoZSAqcG9saWN5KiBhYm91dCB3aGVyZSBpdCBzaG91 bGQNCj4gYmUNCj4gPj4gZG9uZSBtaWdodCBhbHNvIGJlIHNldCBpbiBhbnkgb2YgdGhvc2UgcGxh Y2VzLiBBbmQgdGhlcmUgYXJlDQo+IGNvbXBldGluZw0KPiA+PiBpbnRlcmVzdHMgYWJvdXQgdGhh dC4gRm9yIGluc3RhbmNlOg0KPiA+Pg0KPiA+PiAtIHRoZSBzb3VyY2Ugd2FudHMgdG8gbWluaW1p emUgZGVyZWZzLiBEZXBlbmRpbmcgb24gdGhlIHBhcnRpY3VsYXINCj4gPj4gICAgZGF0YSBhbmQg dGhlIHR5cGljYWwgYWNjZXNzIHBhdHRlcm5zIGZvciB0aGF0IGRhdGEsIGNob29zaW5nIGENCj4g Pj4gICAgcGFydGljdWxhciBvbmUgb2YgdGhlIG90aGVyIHBhcnRpZXMgdG8gZG8gdGhlIGRlcmVm IG1heSBtaW5pbWl6ZQ0KPiA+PiAgICB0aGUgbnVtYmVyIG9mIGRlcmVmcy4gKEJ1dCBwcm9iYWJs eSB0aGUgc291cmNlIGhhcyB0b28gbGl0dGxlDQo+IGluZm8NCj4gPj4gICAgYWJvdXQgdGhlIHVz YWdlIHRvIG1ha2UgdGhlIGNob2ljZSBldmVuIGlmIGl0IGNvdWxkLikNCj4gPj4NCj4gPj4gLSB0 aGUgcHVibGlzaGVyLCBpZiBpdCBpc24ndCBjb2xsb2NhdGVkIHdpdGggdGhlIHNvdXJjZSwgbWF5 IHdhbnQNCj4gPj4gICAgdG8gZGVsZWdhdGUgdGhlIGRlcmVmIHRvIHNhdmUgaXRzZWxmIHdvcmsu DQo+ID4+DQo+ID4+IC0gdGhlIHByZXNlbmNlIHNlcnZlciBtYXkgYWxzbyB3YW50IHRvIGRlbGVn YXRlIHRoZSBkZXJlZiB0byBlaXRoZXINCj4gPj4gICAgdGhlIHB1Ymxpc2hlciBvciB0aGUgd2F0 Y2hlciB0byBzYXZlIGl0c2VsZiB3b3JrLiBCdXQgaW4gb3RoZXINCj4gPj4gICAgY2FzZXMgaXRz IHJvbGUgaW4gbGlmZSBpcyB0byBvZmZsb2FkIHRoZSBwdWJsaXNoZXIgYW5kIHRoZQ0KPiB3YXRj aGVyLA0KPiA+PiAgICBzbyBpdCBtaWdodCBiZSB3aWxsaW5nIHRvIHRha2Ugb24gdGhlIHdvcmsu DQo+ID4+DQo+ID4+IC0gdGhlIHdhdGNoZXIgYWxzbyBtYXkgd2FudCB0byBkZWxlZ2F0ZSB0aGlz IHdvcmsgdG8gb25lIG9mIHRoZQ0KPiA+PiAgICBvdGhlciBwYXJ0aWVzIHRvIG9mZmxvYWQgaXRz ZWxmLiBCdXQgaW4gb3RoZXIgY2FzZXMgaXQgbWF5ICp3YW50Kg0KPiA+PiAgICB0aGUgb3Bwb3J0 dW5pdHkgdG8gZG8gdGhlIGRlcmVmIGl0c2VsZiBzbyB0aGF0IGl0IGNhbiBnZXQgbW9yZQ0KPiA+ PiAgICB0aW1lbHkgdmFsdWVzIHRoYW4gaXQgd291bGQgb3RoZXJ3aXNlLg0KPiA+Pg0KPiA+PiBT bywgSSB0aGluayAgZ2VuZXJhbCBzb2x1dGlvbiBpcyBnb2luZyB0byByZXF1aXJlIHNvbWUgc29y dCBvZg0KPiA+PiBuZWdvdGlhdGlvbiBiZXR3ZWVuIGFsbCB0aGUgcGFydGllcyBhYm91dCB3aG8g YXNzdW1lcyB0aGlzDQo+ID4+IHJlc3BvbnNpYmlsaXR5LiBTZWVtcyBsaWtlIGFuIGludGVyZXN0 aW5nIGFuZCBub24tdHJpdmlhbCBwcm9ibGVtLg0KPiA+Pg0KPiA+PiAJVGhhbmtzLA0KPiA+PiAJ UGF1bA0KPiA+Pg0KPiA+PiBUaG9tc29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4+PiBIaSBKYW1lcywN Cj4gPj4+DQo+ID4+Pj4gVGhpcyB0bywgY2FuIGJlIGFkZGVkIHRvIFNJUCBMb2NhdGlvbiBDb252 ZXlhbmNlIChpZiB0aGUgU0lQQ09SRQ0KPiBXRw0KPiA+Pj4+IGFncmVlcyB3aXRoIHRoaXMgYWRk aXRpb24pLg0KPiA+Pj4gQXNpZGUgZnJvbSBhIHZlcnkgc3Ryb25nIGRlc2lyZSB0byBzZWUgdGhl IGVuZCBvZiBTSVAgbG9jYXRpb24NCj4gPj4gY29udmV5YW5jZSwgYWxsIHRoZSBhdXRob3JzIG9u IHRoaXMgZG9jdW1lbnQgYXJlIGluIHN0cm9uZyBhZ3JlZW1lbnQNCj4gPj4gdGhhdCBhIGxvY2F0 aW9uLXNwZWNpZmljIHNvbHV0aW9uIGlzIG5vdCBkZXNpcmFibGUuDQo+ID4+Pj4gQW5kIHdoZW4g eW91IHJlYWNoIGNvbnNlbnN1cyBvbiB0aGUgcmVxdWlyZW1lbnQgdG8gc2VuZCBhIHdhdGNoZXIN Cj4gPj4gdGhlDQo+ID4+Pj4gbG9jYXRpb24gVVJJIGluc3RlYWQgb2YgYSBsb2NhdGlvbiB2YWx1 ZSwgdGhhdCB3aWxsIG5lZWQgdG8gYmUNCj4gPj4+PiBpbmRpY2F0ZWQgd2l0aCBmdXJ0aGVyIHdv cmsuDQo+ID4+PiBUaGlzIGlzIHNlbnNpYmxlLiAgSSB0ZW5kIHRvIGFncmVlIHRoYXQgd2Ugd2Fu dCB0byBoYXZlIHRoZQ0KPiBwcmVzZW5jZQ0KPiA+PiBhZ2VudCBhYmxlIHRvIGRvIHRoZSBkZXJl ZmVyZW5jZS4gIEluIG1hbnkgY2FzZXMsIHRoZSB3YXRjaGVyIHdvbnQNCj4gYmUNCj4gPj4gaW50 ZXJlc3RlZCBpbiBkb2luZyB0aGlzIHRoZW1zZWx2ZXMuICBUaGlzIGlzIGp1c3Qgb25lIGFzcGVj dCB3ZQ0KPiBuZWVkDQo+ID4+IHRvIGNvbnNpZGVyIGluIHRoZSBzb2x1dGlvbi4NCj4gPj4+IEZv ciBpbnN0YW5jZSwgaWYgd2UgZXh0ZW5kIFBJREYsIGEgcHJlc2VuY2UgYWdlbnQgdGhhdCBkb2Vz bid0DQo+ID4+IHN1cHBvcnQgdGhlIGV4dGVuc2lvbiB3b3VsZCBwYXNzIHRoZSByZWZlcmVuY2Ug b253YXJkIHVuYXdhcmUgb2YgaXRzDQo+ID4+IHNwZWNpYWwgc3RhdHVzLiAgVGhhdCBtaWdodCBi ZSBhIGRlc2lyYWJsZSBhdHRyaWJ1dGUgb2YgYSBzb2x1dGlvbi4NCj4gPj4gQWx0ZXJuYXRpdmVs eSwgd2UgY291bGQgcHJvdmlkZSBhIGRpZmZlcmVudCBib2R5Lg0KPiA+Pj4gTWlndWVsIGFuZCBJ IGFyZSBjdXJyZW50bHkgZGViYXRpbmcgb3B0aW9ucy4gIFdlJ3JlIHN0aWxsIHRyeWluZyB0bw0K PiA+PiBjb21lIHRvIGEgY29tbW9uIHVuZGVyc3RhbmRpbmcgb24gdGhpcyBwb2ludC4gIEFib3V0 IGFsbCB3ZSBhZ3JlZSBvbg0KPiA+PiByaWdodCBub3cgaXMgdGhhdCB0aGlzIHJlZmVyZW5jZSB3 aWxsIHNpdCBpbiB0aGUgYm9keSBvZiB0aGUgU0lQDQo+ID4+IFBVQkxJU0ggYW5kIHRoYXQgaXQg d2lsbCBub3QgYmUgbG9jYXRpb24tc3BlY2lmaWMuICBUaGVzZSBhcmUgYm90aA0KPiA+PiByZWFz b25zIGFnYWluc3QgdXNpbmcgR2VvbG9jYXRpb24sIHdoaWNoIGlzIHVuZm9ydHVuYXRlIGluIGEg d2F5DQo+ID4+IGJlY2F1c2UgaXQgaGFzIGEgbG90IG9mIHRoZSBzZW1hbnRpY3Mgd2UncmUgbG9v a2luZyBmb3IuDQo+ID4+PiBPbmNlIHdlJ3ZlIHNvcnRlZCBvdXQgdGhlIGJhc2ljcywgbWF5YmUg d2UgY2FuIHNlZSBob3cgdGhlDQo+ID4+IEdlb2xvY2F0aW9uIGhlYWRlciBmaXRzLg0KPiA+Pj4+ IEFzIHN0YXRlZCBhYm92ZSwgSSBiZWxpZXZlIHlvdSBhcmUgd2FudGluZyBhIGRlZmF1bHQgYWN0 aW9uIGZvcg0KPiB0aGUNCj4gPj4+PiBQUyB0byBkZXJlZmVyZW5jZQ0KPiA+Pj4gQWN0dWFsbHks IGFzIE1pZ3VlbCBzYXlzLCB0aGUgb3B0aW9ucyBhcmUgc3RpbGwgbGFyZ2VseSBvcGVuLiAgQnV0 DQo+IEkNCj4gPj4gY2VydGFpbmx5IHRoaW5rIHRoYXQgaGF2aW5nIHRoZSBwcmVzZW5jZSBhZ2Vu dCBhYmxlIHRvIGRlcmVmZXJlbmNlDQo+IGlzIGENCj4gPj4gZGVzaXJhYmxlIGZlYXR1cmUuICBU aGlzIG1pZ2h0IGJlOiBhbHdheXMgZGVyZWZlcmVuY2UsIGRlcmVmZXJlbmNlDQo+ID4+IGJhc2Vk IG9uIHByZXNlbmNlIGFnZW50IHBvbGljeSwgZGVyZWZlcmVuY2UgYXQgdGhlIHJlcXVlc3Qgb2Yg dGhlDQo+ID4+IHByZXNlbnRpdHksIG9yIGEgY29tYmluYXRpb24gb2YgdGhlc2UuDQo+ID4+PiAt LU1hcnRpbg0KPiA+Pj4NCj4gPj4+PiBKYW1lcw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4+IC9NaWd1ZWwNCj4gPj4+Pj4NCj4gPj4+Pj4gLS0NCj4gPj4+Pj4gTWlndWVs IEEuIEdhcmNpYQ0KPiA+Pj4+PiArMzQtOTEtMzM5LTM2MDgNCj4gPj4+Pj4gRXJpY3Nzb24gU3Bh aW4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPiA+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4+Pg0K PiA+DQoNCg== From christer.holmberg@ericsson.com Fri Oct 30 06:14:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B08E3A68DA for ; Fri, 30 Oct 2009 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKy1lgzxnxQQ for ; Fri, 30 Oct 2009 06:14:11 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7AFB03A681A for ; Fri, 30 Oct 2009 06:14:10 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-d0-4aeae6b2e608 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 89.A1.24026.2B6EAEA4; Fri, 30 Oct 2009 14:14:26 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:14:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 14:14:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWA= References: <4AE8B942.1090506@cisco.com><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> From: "Christer Holmberg" To: "Christer Holmberg" , "DRAGE, Keith (Keith)" , "Elwell, John" , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 30 Oct 2009 13:14:25.0943 (UTC) FILETIME=[E7857270:01CA5962] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:14:12 -0000 Hi, I realized that section 4.4 already contains the following text about 469: "In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure." Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 29. lokakuuta 2009 22:19 > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > My suggestion is to go with Robert's proposal, then and=20 > somewhere (in Section 4.x) generally indciate that 469 only=20 > affects the transaction, and then remote the text from section 7. >=20 > We used to have a section dedicated to the 469 response, so I=20 > guess it could have fitted there also, but I was asked to=20 > remove it because the text at that time didn't really bring=20 > anything new. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: 29. lokakuuta 2009 17:52 > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh);=20 > Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Treat the 469 dialog handling text and the existing 7.3 text=20 > separately. >=20 > The 469 dialog handling belongs somewhere around the area of (but not > in) section 4.4. >=20 > The 7.3 text should probably stay (in my view), and if it=20 > stays, it belongs where it currently is. If the consensus is=20 > to remove it (as suggested by some other people), then that=20 > is also fine, but I have no problem keeping it. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, October 29, 2009 1:35 PM > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > > Hi, > >=20 > > I am not sure I understood what you said, but I'll give it a try.=20 > >=20 > > >Any specific text on receipt of 469 should go in the most=20 > appropriate > > section, which is definitely not section 7 - I would=20 > suggest somewhere >=20 > > around > > >section 4.4, but not in 4.4 because this is all UAS=20 > functionality and > > we want UAC functionality. > >=20 > > Ok, so whatever text we write should not be in section 7, but=20 > > somewhere else. Then, the section 7 text is removed, and the=20 > > individual Info Package specifications do not need to say anything=20 > > about the dialog fate? > >=20 > > Or? > >=20 > > >With 469 we do not have a Info-Package, becuase the receiver > > was unable > > to recognise one that was valid. If for example two had been=20 > > previously > > >negotiated with Recv-Info, it could be either of them, or=20 > indeed the > > unnegotiated appearance of a third. That is why I think the=20 > issue is=20 > > generic rather > > >than Info Package specific. > >=20 > > I think you will only send 469 if the INFO request contained=20 > > Info-Package, and the idea is that the 469 contains the=20 > latest set of=20 > > packages. One must not use the 469 to CHANGE the set, and maybe we=20 > > need to make that clear. > >=20 > > >I would confirm that I see no need to kill the dialog but=20 > merely the > > transaction. > >=20 > > I agree with you. The question is whether we need to say something=20 > > about it. Based on what others say, it seems like we=20 > wouldn't need any >=20 > > text at all about dialog fate. But, my head is so full of=20 > INFO that it >=20 > > soon explodes, so I may have missunderstood :) > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > > Sent: Thursday, October 29, 2009 10:05 AM > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > > (pkyzivat) > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > Christer, > > >=20 > > > This is in the section on Info Package considerations. I > > rather doubt > > > there is anything you need to specify on this topic when > > defining an > > > Info-Package. All Info-Packages should be subject to the=20 > same rules: > > > i.e., depending on the particular error response to an INFO > > request, > > > the dialog usage will either remain or be terminated. If=20 > we need to=20 > > > say anything more on this matter (e.g., the impact of 469), that=20 > > > should be covered elsewhere in the document. I don't=20 > think we need=20 > > > 7.3. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > > Sent: 29 October 2009 07:42 > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > > Hi, > > > > =20 > > > > So, do people think we should keep the existing text > > (section 7.3), > > > > which talks about the dialog fate? > > > > =20 > > > > Regards. > > > > =20 > > > > Christer > > > >=20 > > > > ________________________________ > > > >=20 > > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > > Sent: Thu 10/29/2009 7:57 AM > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > >=20 > > > >=20 > > > > I agree. > > > >=20 > > > > If the INFO transaction fails, then let the application > > > decide whether > > > > it wants to continue with the dialog or not? > > > >=20 > > > > Sanjay > > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > To: Christer Holmberg > > > > Cc: SIPCORE > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > > I don't think INFO should add any new dialog or usage > > failure cases. > > > > Errors that generically cause global failure, such as 408, > > > should of > > > > course do so for INFO as well. But specific failures of > > > INFO (legacy > > > > or with I-P) should only fail the transaction. > > > >=20 > > > > If in a particular case an application wants to consider > > > some result > > > > of and INFO to be fatal to the call it has ample means to > > > cause that > > > > to happen. > > > >=20 > > > > Thanks, > > > > Paul > > > >=20 > > > > Christer Holmberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > I would like to point out the following WGLC comment=20 > provided by > > > > Keith. > > > > > > > > > > ------------------ > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > As described in [RFC5057], an INFO request is always > > part of an > > > > > INVITE dialog usage. > > > > > > > > > > One needs to consider the fate of the dialog usage=20 > of an INFO > > > > request > > > > > is rejected. In some cases it may be acceptable that > > the whole > > > > > dialog usage is terminated, while in other cases is is > > > > desirable to > > > > > maintain the dialog usage. > > > > > > > > > > However as we have a specific new response code that > > represents a > > > > > failure of the INFO method extension rather than any > > > > specific package, > > > > I > > > > > believe the actions for 469 in respect of the dialog usage > > > > > > > > > > should be defined in this document." > > > > > > > > > > ------------------ > > > > > > > > > > Personally I agree with Keith - the fate of the dialog > > should not > > > > depend > > > > > on the package (and the SIP stack should not need to > > know package > > > > > specific behavior). > > > > > > > > > > So, we should, in the main part of the spec talking=20 > about INFO=20 > > > > > responses, specify whether 469 terminates the invite dialog > > > > usage, or > > > > > just the transaction. > > > > > > > > > > I don't see a reason to terminte the whole invite=20 > dialog usage, > > > > because > > > > > the 469 could come due to a race condition, when I've sent > > > > a re-INVITE > > > >=20 > > > > > with a new set of Info Packages, but the remote UA sent an > > > > INFO based > > > > on > > > > > the old set before it received the re-INVITE. > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > 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 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > 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 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Fri Oct 30 06:18:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94BEA3A6AA1 for ; Fri, 30 Oct 2009 06:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2trVyLicsTW for ; Fri, 30 Oct 2009 06:18:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 99D033A6AA5 for ; Fri, 30 Oct 2009 06:18:47 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-bb-4aeae7c73cdc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id DE.9F.31706.7C7EAEA4; Fri, 30 Oct 2009 14:19:03 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:18:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5963.68B478FB" Date: Fri, 30 Oct 2009 14:18:02 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Header field parameter re-use thread-index: AcpYGHFg8RT3KAAMRRytbLuLYsrltgAfMKbQAABS9cAAMyuO8A== References: From: "Christer Holmberg" To: "DRAGE, Keith (Keith)" , "SIPCORE" X-OriginalArrivalTime: 30 Oct 2009 13:18:31.0670 (UTC) FILETIME=[79FC6960:01CA5963] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:18:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5963.68B478FB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 The new version of section 7.4 looks as below: =20 "The Info Package specification MAY define Info Package parameters which can be used in the Recv-Info or Info-Package header fields, together with the header field value representing the Info Package.=20 The specification MUST describe the syntax and semantics of the defined parameters. It MUST be specified whether a specific parameter is only applicable to the Recv-Info=20 header field, the Info-Package header field, or both. The Info Package specification MAY also use Info Package parameters defined in other Info Package specifications. In such cases the Info Package specification MUST contain an=20 explicit reference to the parameters and the Info Package specification in which the parameters are defined. By default, an Info Package parameter is only applicable for the Info Package for which the parameter has=20 been explicitly defined. NOTE: Info Package parameters defined for specific Info Packages can share the name with parameters defined for=20 other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined." =20 Regards, =20 Christer =20 ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 29. lokakuuta 2009 14:55 To: DRAGE, Keith (Keith); SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use =09 =09 Hi, =20 >By reference is allowed, but it should be an explicit reference to the specific =20 >parameter from the new Info Package. =20 =20 Yes. =20 >(And it obviously has to make sense in the new Info Package definition.=20 =20 It always does :) =20 >Reference works a bit like a macro call, at the point the reference is made, include the =20 >referenced text in the document. So essentially reference is just like defining the =20 >parameter in full in the new document.=20 =20 Yes. =20 Regards, =20 Christer =20 =20 =20 =20 regards =20 Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, October 28, 2009 9:49 PM To: SIPCORE Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use =09 =09 Hi,=20 Another issue which came to my mind when going through Keith's comment.=20 Currently we say that Info Package parameters can only be used with the package for which it was defined.=20 But, what if another Info Package needs a parameter with exactly the same semantics? Even if that other Info Package would use the same parameter name, it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer to parameter defined for other Info Packages?=20 NOTE that I am NOT saying that Info Packages should be allowed to use other parameters just like that - the I-P specifications must still indicate (either by defining or refering to) which parameters are allowed for that I-P. Comments?=20 Regards,=20 Christer=20 ------_=_NextPart_001_01CA5963.68B478FB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Header field parameter = re-use
 
The new version of section 7.4 looks as=20 below:
 
    "The Info Package = specification=20 MAY define Info Package parameters which can be used in=20 the
    Recv-Info or Info-Package header fields, = together=20 with the header field value
    representing the = Info=20 Package. 
    The specification = MUST describe=20 the syntax and semantics of the defined parameters. It=20 MUST
    be specified whether a specific = parameter is=20 only applicable to the Recv-Info
    header = field, the=20 Info-Package header field, or both.
    The Info Package = specification=20 MAY also use Info Package parameters defined = in
    other=20 Info Package specifications. In such cases the Info Package = specification MUST=20 contain an
    explicit reference to the = parameters and=20 the Info Package specification in which the parameters are=20 defined.
    By default, an Info = Package=20 parameter is only applicable for the Info Package for which the = parameter has=20
    been explicitly = defined.
    NOTE: Info Package = parameters=20 defined for specific Info Packages can share the name with parameters = defined=20 for
    other Info Packages, but the parameter = semantics=20 are specific to the Info Package for which they are=20 defined."
 
Regards,
 
Christer
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: 29. lokakuuta 2009 14:55
To: DRAGE, = Keith=20 (Keith); SIPCORE
Subject: Re: [sipcore] Info-Event Open = Issue:=20 Header field parameter re-use

Hi,
 
>By reference is allowed, but it = should be=20 an explicit reference to the specific  
>parameter from the new Info Package.  
 
Yes.=
 
 >(And it obviously has to = make sense=20 in the new Info Package definition. 
 
It = always does=20 = :)
 
>Reference=20 works a bit like a macro call, at the point the reference is made, = include=20 the  
>referenced text in the document. = So=20 essentially reference is just like defining the  
>parameter in = full in the=20 new document. 
 
Yes.=
 
Regards,
 
Christer
 
 
 
 
regards
 
Keith

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 Holmberg
Sent: Wednesday, October 28, 2009 9:49 = PM
To:=20 SIPCORE
Subject: [sipcore] Info-Event Open Issue: Header = field=20 parameter re-use


Hi,

Another issue which came to my mind = when going=20 through Keith's comment.

Currently we say that Info Package = parameters can=20 only be used with the package for which it was defined.

But, what if another Info Package = needs a=20 parameter with exactly the same semantics? Even if that other Info = Package=20 would use the same parameter name, it would still have to re-define = the=20 parameter.

So, the question is: should we allow = Info Package=20 specifications to refer to parameter defined for other Info = Packages?=20


NOTE that I am NOT saying that Info = Packages=20 should be allowed to use other parameters just like that - the I-P=20 specifications must still indicate (either by defining or refering = to) which=20 parameters are allowed for that I-P.

Comments?

Regards,

Christer=20

------_=_NextPart_001_01CA5963.68B478FB-- From drage@alcatel-lucent.com Fri Oct 30 06:19:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0AF3A67D3 for ; Fri, 30 Oct 2009 06:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBkL8vb0kIuL for ; Fri, 30 Oct 2009 06:19:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 75E733A67A1 for ; Fri, 30 Oct 2009 06:19:31 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9UDJgHw010720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Oct 2009 14:19:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 30 Oct 2009 14:19:42 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "Elwell, John" , "Sanjay Sinha (sanjsinh)" , "Paul Kyzivat (pkyzivat)" Date: Fri, 30 Oct 2009 14:19:41 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwA== Message-ID: References: <4AE8B942.1090506@cisco.com><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net> 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:19:33 -0000 Which covers the sender of the 469 but not the receiver. Apply the author g= uidelines and separate sender and receiver requirements into different sect= ions. regards Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, October 30, 2009 1:14 PM > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, John;=20 > Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I realized that section 4.4 already contains the following text about > 469: >=20 > "In the terminology of Multiple Dialog Usages [RFC5057], this=20 > represents a Transaction Only failure." >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 29. lokakuuta 2009 22:19 > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > > Hi, > >=20 > > My suggestion is to go with Robert's proposal, then and=20 > somewhere (in=20 > > Section 4.x) generally indciate that 469 only affects the=20 > transaction,=20 > > and then remote the text from section 7. > >=20 > > We used to have a section dedicated to the 469 response, so=20 > I guess it=20 > > could have fitted there also, but I was asked to remove it=20 > because the=20 > > text at that time didn't really bring anything new. > >=20 > > Regards, > >=20 > > Christer > >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 29. lokakuuta 2009 17:52 > > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Treat the 469 dialog handling text and the existing 7.3 text=20 > > separately. > >=20 > > The 469 dialog handling belongs somewhere around the area=20 > of (but not > > in) section 4.4. > >=20 > > The 7.3 text should probably stay (in my view), and if it stays, it=20 > > belongs where it currently is. If the consensus is to remove it (as=20 > > suggested by some other people), then that is also fine,=20 > but I have no=20 > > problem keeping it. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, October 29, 2009 1:35 PM > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > >=20 > > > Hi, > > >=20 > > > I am not sure I understood what you said, but I'll give it a try.=20 > > >=20 > > > >Any specific text on receipt of 469 should go in the most > > appropriate > > > section, which is definitely not section 7 - I would > > suggest somewhere > >=20 > > > around > > > >section 4.4, but not in 4.4 because this is all UAS > > functionality and > > > we want UAC functionality. > > >=20 > > > Ok, so whatever text we write should not be in section 7, but=20 > > > somewhere else. Then, the section 7 text is removed, and the=20 > > > individual Info Package specifications do not need to say=20 > anything=20 > > > about the dialog fate? > > >=20 > > > Or? > > >=20 > > > >With 469 we do not have a Info-Package, becuase the receiver > > > was unable > > > to recognise one that was valid. If for example two had been=20 > > > previously > > > >negotiated with Recv-Info, it could be either of them, or > > indeed the > > > unnegotiated appearance of a third. That is why I think the > > issue is > > > generic rather > > > >than Info Package specific. > > >=20 > > > I think you will only send 469 if the INFO request contained=20 > > > Info-Package, and the idea is that the 469 contains the > > latest set of > > > packages. One must not use the 469 to CHANGE the set, and=20 > maybe we=20 > > > need to make that clear. > > >=20 > > > >I would confirm that I see no need to kill the dialog but > > merely the > > > transaction. > > >=20 > > > I agree with you. The question is whether we need to say=20 > something=20 > > > about it. Based on what others say, it seems like we > > wouldn't need any > >=20 > > > text at all about dialog fate. But, my head is so full of > > INFO that it > >=20 > > > soon explodes, so I may have missunderstood :) > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > > > (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > > Christer, > > > >=20 > > > > This is in the section on Info Package considerations. I > > > rather doubt > > > > there is anything you need to specify on this topic when > > > defining an > > > > Info-Package. All Info-Packages should be subject to the > > same rules: > > > > i.e., depending on the particular error response to an INFO > > > request, > > > > the dialog usage will either remain or be terminated. If > > we need to > > > > say anything more on this matter (e.g., the impact of=20 > 469), that=20 > > > > should be covered elsewhere in the document. I don't > > think we need > > > > 7.3. > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Christer Holmberg > > > > > Sent: 29 October 2009 07:42 > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > > Hi, > > > > > =20 > > > > > So, do people think we should keep the existing text > > > (section 7.3), > > > > > which talks about the dialog fate? > > > > > =20 > > > > > Regards. > > > > > =20 > > > > > Christer > > > > >=20 > > > > > ________________________________ > > > > >=20 > > > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > Cc: SIPCORE > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > >=20 > > > > >=20 > > > > > I agree. > > > > >=20 > > > > > If the INFO transaction fails, then let the application > > > > decide whether > > > > > it wants to continue with the dialog or not? > > > > >=20 > > > > > Sanjay > > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > To: Christer Holmberg > > > > > Cc: SIPCORE > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > > I don't think INFO should add any new dialog or usage > > > failure cases. > > > > > Errors that generically cause global failure, such as 408, > > > > should of > > > > > course do so for INFO as well. But specific failures of > > > > INFO (legacy > > > > > or with I-P) should only fail the transaction. > > > > >=20 > > > > > If in a particular case an application wants to consider > > > > some result > > > > > of and INFO to be fatal to the call it has ample means to > > > > cause that > > > > > to happen. > > > > >=20 > > > > > Thanks, > > > > > Paul > > > > >=20 > > > > > Christer Holmberg wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I would like to point out the following WGLC comment > > provided by > > > > > Keith. > > > > > > > > > > > > ------------------ > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > As described in [RFC5057], an INFO request is always > > > part of an > > > > > > INVITE dialog usage. > > > > > > > > > > > > One needs to consider the fate of the dialog usage > > of an INFO > > > > > request > > > > > > is rejected. In some cases it may be acceptable that > > > the whole > > > > > > dialog usage is terminated, while in other cases is is > > > > > desirable to > > > > > > maintain the dialog usage. > > > > > > > > > > > > However as we have a specific new response code that > > > represents a > > > > > > failure of the INFO method extension rather than any > > > > > specific package, > > > > > I > > > > > > believe the actions for 469 in respect of the dialog usage > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > ------------------ > > > > > > > > > > > > Personally I agree with Keith - the fate of the dialog > > > should not > > > > > depend > > > > > > on the package (and the SIP stack should not need to > > > know package > > > > > > specific behavior). > > > > > > > > > > > > So, we should, in the main part of the spec talking > > about INFO > > > > > > responses, specify whether 469 terminates the invite dialog > > > > > usage, or > > > > > > just the transaction. > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > dialog usage, > > > > > because > > > > > > the 469 could come due to a race condition, when I've sent > > > > > a re-INVITE > > > > >=20 > > > > > > with a new set of Info Packages, but the remote UA sent an > > > > > INFO based > > > > > on > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > 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 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > 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 > > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From drage@alcatel-lucent.com Fri Oct 30 06:21:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33313A6945 for ; Fri, 30 Oct 2009 06:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.703 X-Spam-Level: X-Spam-Status: No, score=-3.703 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPU0ko72eG6J for ; Fri, 30 Oct 2009 06:21:01 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 47CC03A67A1 for ; Fri, 30 Oct 2009 06:21:01 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9UDLFsu011675 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Oct 2009 14:21:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 30 Oct 2009 14:21:15 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , SIPCORE Date: Fri, 30 Oct 2009 14:21:14 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Header field parameter re-use Thread-Index: AcpYGHFg8RT3KAAMRRytbLuLYsrltgAfMKbQAABS9cAAMyuO8AAAKgLA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2092A75D4FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:21:02 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2092A75D4FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. Keith ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 30, 2009 1:18 PM To: DRAGE, Keith (Keith); SIPCORE Subject: RE: [sipcore] Info-Event Open Issue: Header field parameter re-use The new version of section 7.4 looks as below: "The Info Package specification MAY define Info Package parameters whic= h can be used in the Recv-Info or Info-Package header fields, together with the header field= value representing the Info Package. The specification MUST describe the syntax and semantics of the defined= parameters. It MUST be specified whether a specific parameter is only applicable to the Rec= v-Info header field, the Info-Package header field, or both. The Info Package specification MAY also use Info Package parameters def= ined in other Info Package specifications. In such cases the Info Package speci= fication MUST contain an explicit reference to the parameters and the Info Package specification= in which the parameters are defined. By default, an Info Package parameter is only applicable for the Info P= ackage for which the parameter has been explicitly defined. NOTE: Info Package parameters defined for specific Info Packages can sh= are the name with parameters defined for other Info Packages, but the parameter semantics are specific to the In= fo Package for which they are defined." Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 29. lokakuuta 2009 14:55 To: DRAGE, Keith (Keith); SIPCORE Subject: Re: [sipcore] Info-Event Open Issue: Header field parameter re-use Hi, >By reference is allowed, but it should be an explicit reference to the spe= cific >parameter from the new Info Package. Yes. >(And it obviously has to make sense in the new Info Package definition. It always does :) >Reference works a bit like a macro call, at the point the reference is mad= e, include the >referenced text in the document. So essentially reference is just like def= ining the >parameter in full in the new document. Yes. Regards, Christer regards Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Wednesday, October 28, 2009 9:49 PM To: SIPCORE Subject: [sipcore] Info-Event Open Issue: Header field parameter re-use Hi, Another issue which came to my mind when going through Keith's comment. Currently we say that Info Package parameters can only be used with the pac= kage for which it was defined. But, what if another Info Package needs a parameter with exactly the same s= emantics? Even if that other Info Package would use the same parameter name= , it would still have to re-define the parameter. So, the question is: should we allow Info Package specifications to refer t= o parameter defined for other Info Packages? NOTE that I am NOT saying that Info Packages should be allowed to use other= parameters just like that - the I-P specifications must still indicate (ei= ther by defining or refering to) which parameters are allowed for that I-P. Comments? Regards, Christer --_000_EDC0A1AE77C57744B664A310A0B23AE2092A75D4FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Info-Event Open Issue: Header field parameter re-use</TI= TLE> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3603" name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr align=3Dleft><SPAN class=3D139062113-30102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Works for me.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D139062113-30102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D139062113-30102009><FONT face=3DA= rial=20 color=3D#0000ff size=3D2>Keith</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli= d; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com] <BR><B>Sent:</B> Friday, October = 30,=20 2009 1:18 PM<BR><B>To:</B> DRAGE, Keith (Keith); SIPCORE<BR><B>Subject:</= B>=20 RE: [sipcore] Info-Event Open Issue: Header field parameter=20 re-use<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>The new version of section 7.4 looks as=20 below:</SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009></SPAN></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>    "The Info Package=20 specification MAY define Info Package parameters which can be used in=20 the<BR>    Recv-Info or Info-Package header fields,=20 together with the header field value<BR>    represent= ing=20 the Info Package. <BR></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>    The specification MUST= =20 describe the syntax and semantics of the defined parameters. It=20 MUST<BR>    be specified whether a specific parameter= is=20 only applicable to the Recv-Info <BR>    header field= , the=20 Info-Package header field, or both.<BR></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>    The Info Package=20 specification MAY also use Info Package parameters defined=20 in<BR>    other Info Package specifications. In such = cases=20 the Info Package specification MUST contain an=20 <BR>    explicit reference to the parameters and the = Info=20 Package specification in which the parameters are=20 defined.<BR></SPAN></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>    By default, an Info Pa= ckage=20 parameter is only applicable for the Info Package for which the parameter= has=20 <BR>    been explicitly defined.<BR></SPAN></FONT></D= IV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff size=3D2><= SPAN=20 class=3D239241613-30102009>    NOTE: Info Package par= ameters=20 defined for specific Info Packages can share the name with parameters def= ined=20 for <BR>    other Info Packages, but the parameter=20 semantics are specific to the Info Package for which they are=20 defined."</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D239241613-30102009></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D239241613-30102009>Regards,</SPAN></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D239241613-30102009></SPAN></FONT> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D239241613-30102009>Christer</DIV> <DIV dir=3Dltr align=3Dleft><BR></DIV></SPAN></FONT><FONT face=3DArial co= lor=3D#0000ff=20 size=3D2></FONT> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px so= lid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] <B>On Behalf Of </B>Christer=20 Holmberg<BR><B>Sent:</B> 29. lokakuuta 2009 14:55<BR><B>To:</B> DRAGE, = Keith=20 (Keith); SIPCORE<BR><B>Subject:</B> Re: [sipcore] Info-Event Open Issue= :=20 Header field parameter re-use<BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D615145112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><= FONT=20 face=3DArial color=3D#0000ff size=3D2></FONT> </DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT color=3D#0000ff><F= ONT=20 size=3D2><SPAN class=3D905574112-29102009><SPAN=20 class=3D615145112-29102009>></SPAN>By reference is allowed, but it s= hould=20 be an explicit reference to the specific <SPAN=20 class=3D615145112-29102009> </SPAN></SPAN></FONT></FONT></FONT></D= IV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D905574112-29102009><SPAN=20 class=3D615145112-29102009>></SPAN>parameter<SPAN=20 class=3D615145112-29102009> </SPAN>from </SPAN><SPAN=20 class=3D905574112-29102009>the new Info Package. <SPAN=20 class=3D615145112-29102009> </SPAN></SPAN></FONT></FONT></FONT></F= ONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D905574112-29102009><SPAN=20 class=3D615145112-29102009></SPAN></SPAN></FONT></FONT></FONT></FONT></= FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D905574112-29102009><SPAN=20 class=3D615145112-29102009>Yes.</SPAN></SPAN></FONT></FONT></FONT></FON= T></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT face= =3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D905574112-29102009><SPAN=20 class=3D615145112-29102009></SPAN></SPAN></FONT></FONT></FONT></FONT></= FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT size= =3D+0><FONT=20 size=3D+0><SPAN class=3D905574112-29102009><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009> ></SPAN>(And it obviously has to ma= ke=20 sense in the new Info Package definition.<SPAN=20 class=3D615145112-29102009> </SPAN></FONT></FONT></FONT></SPAN></F= ONT></FONT></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT size= =3D+0><FONT=20 size=3D+0><SPAN class=3D905574112-29102009><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></SPAN></FONT></= FONT></FONT></FONT> </DIV> <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT size=3D+0><FONT size= =3D+0><FONT=20 size=3D+0><SPAN class=3D905574112-29102009><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D615145112-29102009>It alwa= ys does=20 :)</SPAN></FONT></FONT></FONT></SPAN></FONT></FONT></FONT></FONT></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT=20 face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009>></SPAN>Reference works a bit like a macr= o call,=20 at the point the reference is made, include the <SPAN=20 class=3D615145112-29102009> </SPAN></FONT></FONT></FONT></SPAN></D= IV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN= =20 class=3D615145112-29102009>></SPAN>referenced text in the document. = So=20 essentially reference is just like defining the <SPAN=20 class=3D615145112-29102009> </SPAN></FONT></FONT></FONT></FONT></F= ONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009>></SPAN>parameter in full in the new= =20 document.<SPAN=20 class=3D615145112-29102009> </SPAN></FONT></FONT></FONT></FONT></F= ONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009>Yes.</SPAN></FONT></FONT></FONT></FONT></FON= T></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009>Regards,</SPAN></FONT></FONT></FONT></FONT><= /FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009>Christer</SPAN></FONT></FONT></FONT></FONT><= /FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT size= =3D+0><FONT=20 size=3D+0><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D615145112-29102009></SPAN></FONT></FONT></FONT></FONT></FONT></= FONT></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2>regards</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D905574112-29102009><FONT face= =3DArial=20 color=3D#0000ff size=3D2>Keith</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft= > <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] <B>On Behalf Of </B>Christer=20 Holmberg<BR><B>Sent:</B> Wednesday, October 28, 2009 9:49 PM<BR><B>To= :</B>=20 SIPCORE<BR><B>Subject:</B> [sipcore] Info-Event Open Issue: Header fi= eld=20 parameter re-use<BR></FONT><BR></DIV> <DIV></DIV><!-- Converted from text/rtf format --><BR> <P><FONT face=3DArial size=3D2>Hi,</FONT> </P> <P><FONT face=3DArial size=3D2>Another issue which came to my mind wh= en going=20 through Keith's comment.</FONT> </P> <P><FONT face=3DArial size=3D2>Currently we say that Info Package par= ameters=20 can only be used with the package for which it was defined.</FONT> </= P> <P><FONT face=3DArial size=3D2>But, what if another Info Package need= s a=20 parameter with exactly the same semantics? Even if that other Info Pa= ckage=20 would use the same parameter name, it would still have to re-define t= he=20 parameter.</FONT></P> <P><FONT face=3DArial size=3D2>So, the question is: should we allow I= nfo=20 Package specifications to refer to parameter defined for other Info=20 Packages?</FONT> </P><BR> <P><FONT face=3DArial size=3D2>NOTE that I am NOT saying that Info Pa= ckages=20 should be allowed to use other parameters just like that - the I-P=20 specifications must still indicate (either by defining or refering to= )=20 which parameters are allowed for that I-P.</FONT></P> <P><FONT face=3DArial size=3D2>Comments?</FONT> </P> <P><FONT face=3DArial size=3D2>Regards,</FONT> </P> <P><FONT face=3DArial size=3D2>Christer</FONT>=20 </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> --_000_EDC0A1AE77C57744B664A310A0B23AE2092A75D4FRMRSSXCHMBSC3d_-- From christer.holmberg@ericsson.com Fri Oct 30 06:33:24 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DB53A6926 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J7vKk6hWkWo for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:33:23 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id F291C3A681A for <sipcore@ietf.org>; Fri, 30 Oct 2009 06:33:20 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-ed-4aeaeb30ae4b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1C.A0.31706.03BEAEA4; Fri, 30 Oct 2009 14:33:36 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:31:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 14:30:57 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.eemea.ericsson.se> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwAAASdAg References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C2@esealmw113.eemea.ericsson.se><4AE8B942.1090506@cisco.com><C7FFFFDD779F2047A0FBAC811C5C5A0009AB079D@xmb-rtp-201.amer.cisco.com><CA9998CD4A020D418654FCDEF4E707DF083CD3E1@esealmw113.eemea.ericsson.se><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net><EDC0A1AE77C57744B664A310A0B23AE20925F42C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><CA9998CD4A020D418654FCDEF4E707DF0B1685CC@esealmw113.eemea.ericsson.se><EDC0A1AE77C57744B664A310A0B23AE2092A749E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0B1685CD@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A07@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 30 Oct 2009 13:31:50.0311 (UTC) FILETIME=[56035B70:01CA5965] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE <sipcore@ietf.org> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 13:33:24 -0000 Hi, I could simply divide the paragraphs into two parts, and add some text to the end of the new second paragraph: "If a UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 Bad INFO Package response Section 11.6. =20 In the terminology of Multiple Dialog Usages [RFC5057], the 469 Bad INFO Package=20 Response represents a Transaction Only failure, and a UA MUST NOT terminate the invite dialog usage when=20 it sends or receives a 469 response." Regards, Christer > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 30. lokakuuta 2009 15:20 > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh);=20 > Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Which covers the sender of the 469 but not the receiver.=20 > Apply the author guidelines and separate sender and receiver=20 > requirements into different sections. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, October 30, 2009 1:14 PM > > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, John; Sanjay=20 > > Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > > Hi, > >=20 > > I realized that section 4.4 already contains the following=20 > text about > > 469: > >=20 > > "In the terminology of Multiple Dialog Usages [RFC5057], this=20 > > represents a Transaction Only failure." > >=20 > > Regards, > >=20 > > Christer > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > Sent: 29. lokakuuta 2009 22:19 > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > >=20 > > > Hi, > > >=20 > > > My suggestion is to go with Robert's proposal, then and > > somewhere (in > > > Section 4.x) generally indciate that 469 only affects the > > transaction, > > > and then remote the text from section 7. > > >=20 > > > We used to have a section dedicated to the 469 response, so > > I guess it > > > could have fitted there also, but I was asked to remove it > > because the > > > text at that time didn't really bring anything new. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: 29. lokakuuta 2009 17:52 > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul=20 > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > Treat the 469 dialog handling text and the existing 7.3 text=20 > > > separately. > > >=20 > > > The 469 dialog handling belongs somewhere around the area > > of (but not > > > in) section 4.4. > > >=20 > > > The 7.3 text should probably stay (in my view), and if it=20 > stays, it=20 > > > belongs where it currently is. If the consensus is to=20 > remove it (as=20 > > > suggested by some other people), then that is also fine, > > but I have no > > > problem keeping it. > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Thursday, October 29, 2009 1:35 PM > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > (sanjsinh); Paul > > > > Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > I am not sure I understood what you said, but I'll give=20 > it a try.=20 > > > >=20 > > > > >Any specific text on receipt of 469 should go in the most > > > appropriate > > > > section, which is definitely not section 7 - I would > > > suggest somewhere > > >=20 > > > > around > > > > >section 4.4, but not in 4.4 because this is all UAS > > > functionality and > > > > we want UAC functionality. > > > >=20 > > > > Ok, so whatever text we write should not be in section 7, but=20 > > > > somewhere else. Then, the section 7 text is removed, and the=20 > > > > individual Info Package specifications do not need to say > > anything > > > > about the dialog fate? > > > >=20 > > > > Or? > > > >=20 > > > > >With 469 we do not have a Info-Package, becuase the receiver > > > > was unable > > > > to recognise one that was valid. If for example two had been=20 > > > > previously > > > > >negotiated with Recv-Info, it could be either of them, or > > > indeed the > > > > unnegotiated appearance of a third. That is why I think the > > > issue is > > > > generic rather > > > > >than Info Package specific. > > > >=20 > > > > I think you will only send 469 if the INFO request contained=20 > > > > Info-Package, and the idea is that the 469 contains the > > > latest set of > > > > packages. One must not use the 469 to CHANGE the set, and > > maybe we > > > > need to make that clear. > > > >=20 > > > > >I would confirm that I see no need to kill the dialog but > > > merely the > > > > transaction. > > > >=20 > > > > I agree with you. The question is whether we need to say > > something > > > > about it. Based on what others say, it seems like we > > > wouldn't need any > > >=20 > > > > text at all about dialog fate. But, my head is so full of > > > INFO that it > > >=20 > > > > soon explodes, so I may have missunderstood :) > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > > > > (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > > Christer, > > > > >=20 > > > > > This is in the section on Info Package considerations. I > > > > rather doubt > > > > > there is anything you need to specify on this topic when > > > > defining an > > > > > Info-Package. All Info-Packages should be subject to the > > > same rules: > > > > > i.e., depending on the particular error response to an INFO > > > > request, > > > > > the dialog usage will either remain or be terminated. If > > > we need to > > > > > say anything more on this matter (e.g., the impact of > > 469), that > > > > > should be covered elsewhere in the document. I don't > > > think we need > > > > > 7.3. > > > > >=20 > > > > > John > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Christer Holmberg > > > > > > Sent: 29 October 2009 07:42 > > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > >=20 > > > > > > Hi, > > > > > > =20 > > > > > > So, do people think we should keep the existing text > > > > (section 7.3), > > > > > > which talks about the dialog fate? > > > > > > =20 > > > > > > Regards. > > > > > > =20 > > > > > > Christer > > > > > >=20 > > > > > > ________________________________ > > > > > >=20 > > > > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > > Cc: SIPCORE > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > I agree. > > > > > >=20 > > > > > > If the INFO transaction fails, then let the application > > > > > decide whether > > > > > > it wants to continue with the dialog or not? > > > > > >=20 > > > > > > Sanjay > > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On > > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > > To: Christer Holmberg > > > > > > Cc: SIPCORE > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > >=20 > > > > > > I don't think INFO should add any new dialog or usage > > > > failure cases. > > > > > > Errors that generically cause global failure, such as 408, > > > > > should of > > > > > > course do so for INFO as well. But specific failures of > > > > > INFO (legacy > > > > > > or with I-P) should only fail the transaction. > > > > > >=20 > > > > > > If in a particular case an application wants to consider > > > > > some result > > > > > > of and INFO to be fatal to the call it has ample means to > > > > > cause that > > > > > > to happen. > > > > > >=20 > > > > > > Thanks, > > > > > > Paul > > > > > >=20 > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I would like to point out the following WGLC comment > > > provided by > > > > > > Keith. > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > > > As described in [RFC5057], an INFO request is always > > > > part of an > > > > > > > INVITE dialog usage. > > > > > > > > > > > > > > One needs to consider the fate of the dialog usage > > > of an INFO > > > > > > request > > > > > > > is rejected. In some cases it may be acceptable that > > > > the whole > > > > > > > dialog usage is terminated, while in other cases is is > > > > > > desirable to > > > > > > > maintain the dialog usage. > > > > > > > > > > > > > > However as we have a specific new response code that > > > > represents a > > > > > > > failure of the INFO method extension rather than any > > > > > > specific package, > > > > > > I > > > > > > > believe the actions for 469 in respect of the dialog usage > > > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > Personally I agree with Keith - the fate of the dialog > > > > should not > > > > > > depend > > > > > > > on the package (and the SIP stack should not need to > > > > know package > > > > > > > specific behavior). > > > > > > > > > > > > > > So, we should, in the main part of the spec talking > > > about INFO > > > > > > > responses, specify whether 469 terminates the=20 > invite dialog > > > > > > usage, or > > > > > > > just the transaction. > > > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > > dialog usage, > > > > > > because > > > > > > > the 469 could come due to a race condition, when I've sent > > > > > > a re-INVITE > > > > > >=20 > > > > > > > with a new set of Info Packages, but the remote UA sent an > > > > > > INFO based > > > > > > on > > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > -------------------------------------------------------------- > > > > > > ---------- > > > > > > > > > > > > > > _______________________________________________ > > > > > > > sipcore mailing list > > > > > > > sipcore@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > 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 > > > > >=20 > > > >=20 > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > >=20 >=20 From drage@alcatel-lucent.com Fri Oct 30 06:37:00 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873C23A6945 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJCnRzKkCo7D for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:36:59 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 96AF43A6928 for <sipcore@ietf.org>; Fri, 30 Oct 2009 06:36:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9UDaUqx021214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Oct 2009 14:36:30 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 30 Oct 2009 14:36:30 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Christer Holmberg <christer.holmberg@ericsson.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Fri, 30 Oct 2009 14:36:29 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwAAASdAgAABJ9nA= Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2092A75DE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C2@esealmw113.eemea.ericsson.se><4AE8B942.1090506@cisco.com><C7FFFFDD779F2047A0FBAC811C5C5A0009AB079D@xmb-rtp-201.amer.cisco.com><CA9998CD4A020D418654FCDEF4E707DF083CD3E1@esealmw113.eemea.ericsson.se><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net><EDC0A1AE77C57744B664A310A0B23AE20925F42C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><CA9998CD4A020D418654FCDEF4E707DF0B1685CC@esealmw113.eemea.ericsson.se><EDC0A1AE77C57744B664A310A0B23AE2092A749E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0B1685CD@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A07@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.eemea.ericsson.se> In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE <sipcore@ietf.org> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 13:37:00 -0000 Please keep INFO method sender and INFO method receiver requirements in dif= ferent sections. Keith=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, October 30, 2009 1:31 PM > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 >=20 > Hi, >=20 > I could simply divide the paragraphs into two parts, and add=20 > some text to the end of the new second paragraph: >=20 > "If a UA receives an INFO request associated with an Info=20 > Package that the UA has not indicated willingness to receive,=20 > the UA MUST send a > 469 Bad INFO Package response Section 11.6. =20 >=20 > In the terminology of Multiple Dialog Usages [RFC5057], the=20 > 469 Bad INFO Package Response represents a Transaction Only=20 > failure, and a UA MUST NOT terminate the invite dialog usage=20 > when it sends or receives a 469 response." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 30. lokakuuta 2009 15:20 > > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > > Which covers the sender of the 469 but not the receiver.=20 > > Apply the author guidelines and separate sender and receiver=20 > > requirements into different sections. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Friday, October 30, 2009 1:14 PM > > > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, John; Sanjay=20 > > > Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > >=20 > > > Hi, > > >=20 > > > I realized that section 4.4 already contains the following > > text about > > > 469: > > >=20 > > > "In the terminology of Multiple Dialog Usages [RFC5057], this=20 > > > represents a Transaction Only failure." > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > > > Sent: 29. lokakuuta 2009 22:19 > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > (sanjsinh); Paul > > > > Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > My suggestion is to go with Robert's proposal, then and > > > somewhere (in > > > > Section 4.x) generally indciate that 469 only affects the > > > transaction, > > > > and then remote the text from section 7. > > > >=20 > > > > We used to have a section dedicated to the 469 response, so > > > I guess it > > > > could have fitted there also, but I was asked to remove it > > > because the > > > > text at that time didn't really bring anything new. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: 29. lokakuuta 2009 17:52 > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > > Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > > Treat the 469 dialog handling text and the existing 7.3 text=20 > > > > separately. > > > >=20 > > > > The 469 dialog handling belongs somewhere around the area > > > of (but not > > > > in) section 4.4. > > > >=20 > > > > The 7.3 text should probably stay (in my view), and if it > > stays, it > > > > belongs where it currently is. If the consensus is to > > remove it (as > > > > suggested by some other people), then that is also fine, > > > but I have no > > > > problem keeping it. > > > >=20 > > > > regards > > > >=20 > > > > Keith > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Thursday, October 29, 2009 1:35 PM > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > (sanjsinh); Paul > > > > > Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I am not sure I understood what you said, but I'll give > > it a try.=20 > > > > >=20 > > > > > >Any specific text on receipt of 469 should go in the most > > > > appropriate > > > > > section, which is definitely not section 7 - I would > > > > suggest somewhere > > > >=20 > > > > > around > > > > > >section 4.4, but not in 4.4 because this is all UAS > > > > functionality and > > > > > we want UAC functionality. > > > > >=20 > > > > > Ok, so whatever text we write should not be in section 7, but=20 > > > > > somewhere else. Then, the section 7 text is removed, and the=20 > > > > > individual Info Package specifications do not need to say > > > anything > > > > > about the dialog fate? > > > > >=20 > > > > > Or? > > > > >=20 > > > > > >With 469 we do not have a Info-Package, becuase the receiver > > > > > was unable > > > > > to recognise one that was valid. If for example two had been=20 > > > > > previously > > > > > >negotiated with Recv-Info, it could be either of them, or > > > > indeed the > > > > > unnegotiated appearance of a third. That is why I think the > > > > issue is > > > > > generic rather > > > > > >than Info Package specific. > > > > >=20 > > > > > I think you will only send 469 if the INFO request contained=20 > > > > > Info-Package, and the idea is that the 469 contains the > > > > latest set of > > > > > packages. One must not use the 469 to CHANGE the set, and > > > maybe we > > > > > need to make that clear. > > > > >=20 > > > > > >I would confirm that I see no need to kill the dialog but > > > > merely the > > > > > transaction. > > > > >=20 > > > > > I agree with you. The question is whether we need to say > > > something > > > > > about it. Based on what others say, it seems like we > > > > wouldn't need any > > > >=20 > > > > > text at all about dialog fate. But, my head is so full of > > > > INFO that it > > > >=20 > > > > > soon explodes, so I may have missunderstood :) > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); Paul Kyzivat > > > > > > (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > >=20 > > > > > > Christer, > > > > > >=20 > > > > > > This is in the section on Info Package considerations. I > > > > > rather doubt > > > > > > there is anything you need to specify on this topic when > > > > > defining an > > > > > > Info-Package. All Info-Packages should be subject to the > > > > same rules: > > > > > > i.e., depending on the particular error response to an INFO > > > > > request, > > > > > > the dialog usage will either remain or be terminated. If > > > > we need to > > > > > > say anything more on this matter (e.g., the impact of > > > 469), that > > > > > > should be covered elsewhere in the document. I don't > > > > think we need > > > > > > 7.3. > > > > > >=20 > > > > > > John > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > Christer Holmberg > > > > > > > Sent: 29 October 2009 07:42 > > > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > > > Cc: SIPCORE > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > >=20 > > > > > > > Hi, > > > > > > > =20 > > > > > > > So, do people think we should keep the existing text > > > > > (section 7.3), > > > > > > > which talks about the dialog fate? > > > > > > > =20 > > > > > > > Regards. > > > > > > > =20 > > > > > > > Christer > > > > > > >=20 > > > > > > > ________________________________ > > > > > > >=20 > > > > > > > From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@cisco.com] > > > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > > > Cc: SIPCORE > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > I agree. > > > > > > >=20 > > > > > > > If the INFO transaction fails, then let the application > > > > > > decide whether > > > > > > > it wants to continue with the dialog or not? > > > > > > >=20 > > > > > > > Sanjay > > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On > > > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > > > To: Christer Holmberg > > > > > > > Cc: SIPCORE > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > >=20 > > > > > > > I don't think INFO should add any new dialog or usage > > > > > failure cases. > > > > > > > Errors that generically cause global failure, such as 408, > > > > > > should of > > > > > > > course do so for INFO as well. But specific failures of > > > > > > INFO (legacy > > > > > > > or with I-P) should only fail the transaction. > > > > > > >=20 > > > > > > > If in a particular case an application wants to consider > > > > > > some result > > > > > > > of and INFO to be fatal to the call it has ample means to > > > > > > cause that > > > > > > > to happen. > > > > > > >=20 > > > > > > > Thanks, > > > > > > > Paul > > > > > > >=20 > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I would like to point out the following WGLC comment > > > > provided by > > > > > > > Keith. > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > > > > > As described in [RFC5057], an INFO request is always > > > > > part of an > > > > > > > > INVITE dialog usage. > > > > > > > > > > > > > > > > One needs to consider the fate of the dialog usage > > > > of an INFO > > > > > > > request > > > > > > > > is rejected. In some cases it may be acceptable that > > > > > the whole > > > > > > > > dialog usage is terminated, while in other=20 > cases is is > > > > > > > desirable to > > > > > > > > maintain the dialog usage. > > > > > > > > > > > > > > > > However as we have a specific new response code that > > > > > represents a > > > > > > > > failure of the INFO method extension rather than any > > > > > > > specific package, > > > > > > > I > > > > > > > > believe the actions for 469 in respect of the=20 > dialog usage > > > > > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > Personally I agree with Keith - the fate of the dialog > > > > > should not > > > > > > > depend > > > > > > > > on the package (and the SIP stack should not need to > > > > > know package > > > > > > > > specific behavior). > > > > > > > > > > > > > > > > So, we should, in the main part of the spec talking > > > > about INFO > > > > > > > > responses, specify whether 469 terminates the > > invite dialog > > > > > > > usage, or > > > > > > > > just the transaction. > > > > > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > > > dialog usage, > > > > > > > because > > > > > > > > the 469 could come due to a race condition,=20 > when I've sent > > > > > > > a re-INVITE > > > > > > >=20 > > > > > > > > with a new set of Info Packages, but the remote=20 > UA sent an > > > > > > > INFO based > > > > > > > on > > > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > -------------------------------------------------------------- > > > > > > > ---------- > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > sipcore mailing list > > > > > > > > sipcore@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > _______________________________________________ > > > > > > > sipcore mailing list > > > > > > > sipcore@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > 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 > > > > > >=20 > > > > >=20 > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > >=20 > > >=20 > >=20 > = From christer.holmberg@ericsson.com Fri Oct 30 06:52:02 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08813A692D for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzzkz2ligJ8F for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 06:52:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 634E93A67B6 for <sipcore@ietf.org>; Fri, 30 Oct 2009 06:52:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf6ae000005dda-4e-4aeaef90f1e1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EF.B3.24026.09FEAEA4; Fri, 30 Oct 2009 14:52:16 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:52:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 14:51:43 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0F7E0B22@esealmw113.eemea.ericsson.se> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092A75DE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwAAASdAgAABJ9nAAACH0UA== References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C2@esealmw113.eemea.ericsson.se><4AE8B942.1090506@cisco.com><C7FFFFDD779F2047A0FBAC811C5C5A0009AB079D@xmb-rtp-201.amer.cisco.com><CA9998CD4A020D418654FCDEF4E707DF083CD3E1@esealmw113.eemea.ericsson.se><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net><EDC0A1AE77C57744B664A310A0B23AE20925F42C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><CA9998CD4A020D418654FCDEF4E707DF0B1685CC@esealmw113.eemea.ericsson.se><EDC0A1AE77C57744B664A310A0B23AE2092A749E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0B1685CD@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A07@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75DE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 30 Oct 2009 13:52:16.0008 (UTC) FILETIME=[3095E080:01CA5968] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE <sipcore@ietf.org> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 13:52:02 -0000 The problem is that we don't have "UAC Procedures" and "UAS Procedures" sections. We used to have that, but the text got very confusing. Having said that, when I look at the text in the "4.2 INFO Request" and "4.4 INFO Response" sections, I guess we COULD simply rename them to "User Agent Client procedures" and "User Agent Server procedures", without any major changes in the section itself. It would be more alligned with the structure of section 3. Regards, Christer =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 30. lokakuuta 2009 15:36 > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh);=20 > Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing >=20 > Please keep INFO method sender and INFO method receiver=20 > requirements in different sections. >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, October 30, 2009 1:31 PM > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > >=20 > >=20 > > Hi, > >=20 > > I could simply divide the paragraphs into two parts, and=20 > add some text=20 > > to the end of the new second paragraph: > >=20 > > "If a UA receives an INFO request associated with an Info=20 > Package that=20 > > the UA has not indicated willingness to receive, the UA MUST send a > > 469 Bad INFO Package response Section 11.6. =20 > >=20 > > In the terminology of Multiple Dialog Usages [RFC5057], the > > 469 Bad INFO Package Response represents a Transaction Only=20 > failure,=20 > > and a UA MUST NOT terminate the invite dialog usage when it=20 > sends or=20 > > receives a 469 response." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: 30. lokakuuta 2009 15:20 > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha=20 > (sanjsinh); Paul=20 > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > >=20 > > > Which covers the sender of the 469 but not the receiver.=20 > > > Apply the author guidelines and separate sender and receiver=20 > > > requirements into different sections. > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Friday, October 30, 2009 1:14 PM > > > > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell,=20 > John; Sanjay=20 > > > > Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog=20 > Fate Sharing > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > I realized that section 4.4 already contains the following > > > text about > > > > 469: > > > >=20 > > > > "In the terminology of Multiple Dialog Usages [RFC5057], this=20 > > > > represents a Transaction Only failure." > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Christer Holmberg > > > > > Sent: 29. lokakuuta 2009 22:19 > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > (sanjsinh); Paul > > > > > Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > My suggestion is to go with Robert's proposal, then and > > > > somewhere (in > > > > > Section 4.x) generally indciate that 469 only affects the > > > > transaction, > > > > > and then remote the text from section 7. > > > > >=20 > > > > > We used to have a section dedicated to the 469 response, so > > > > I guess it > > > > > could have fitted there also, but I was asked to remove it > > > > because the > > > > > text at that time didn't really bring anything new. > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > > -----Original Message----- > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > Sent: 29. lokakuuta 2009 17:52 > > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > > (sanjsinh); Paul > > > > > Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > >=20 > > > > > Treat the 469 dialog handling text and the existing 7.3 text=20 > > > > > separately. > > > > >=20 > > > > > The 469 dialog handling belongs somewhere around the area > > > > of (but not > > > > > in) section 4.4. > > > > >=20 > > > > > The 7.3 text should probably stay (in my view), and if it > > > stays, it > > > > > belongs where it currently is. If the consensus is to > > > remove it (as > > > > > suggested by some other people), then that is also fine, > > > > but I have no > > > > > problem keeping it. > > > > >=20 > > > > > regards > > > > >=20 > > > > > Keith > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: Thursday, October 29, 2009 1:35 PM > > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > > (sanjsinh); Paul > > > > > > Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > I am not sure I understood what you said, but I'll give > > > it a try.=20 > > > > > >=20 > > > > > > >Any specific text on receipt of 469 should go in the most > > > > > appropriate > > > > > > section, which is definitely not section 7 - I would > > > > > suggest somewhere > > > > >=20 > > > > > > around > > > > > > >section 4.4, but not in 4.4 because this is all UAS > > > > > functionality and > > > > > > we want UAC functionality. > > > > > >=20 > > > > > > Ok, so whatever text we write should not be in=20 > section 7, but=20 > > > > > > somewhere else. Then, the section 7 text is=20 > removed, and the=20 > > > > > > individual Info Package specifications do not need to say > > > > anything > > > > > > about the dialog fate? > > > > > >=20 > > > > > > Or? > > > > > >=20 > > > > > > >With 469 we do not have a Info-Package, becuase=20 > the receiver > > > > > > was unable > > > > > > to recognise one that was valid. If for example two=20 > had been=20 > > > > > > previously > > > > > > >negotiated with Recv-Info, it could be either of them, or > > > > > indeed the > > > > > > unnegotiated appearance of a third. That is why I think the > > > > > issue is > > > > > > generic rather > > > > > > >than Info Package specific. > > > > > >=20 > > > > > > I think you will only send 469 if the INFO request=20 > contained=20 > > > > > > Info-Package, and the idea is that the 469 contains the > > > > > latest set of > > > > > > packages. One must not use the 469 to CHANGE the set, and > > > > maybe we > > > > > > need to make that clear. > > > > > >=20 > > > > > > >I would confirm that I see no need to kill the dialog but > > > > > merely the > > > > > > transaction. > > > > > >=20 > > > > > > I agree with you. The question is whether we need to say > > > > something > > > > > > about it. Based on what others say, it seems like we > > > > > wouldn't need any > > > > >=20 > > > > > > text at all about dialog fate. But, my head is so full of > > > > > INFO that it > > > > >=20 > > > > > > soon explodes, so I may have missunderstood :) > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Christer > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > Elwell, John > > > > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh);=20 > Paul Kyzivat > > > > > > > (pkyzivat) > > > > > > > Cc: SIPCORE > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > >=20 > > > > > > > Christer, > > > > > > >=20 > > > > > > > This is in the section on Info Package considerations. I > > > > > > rather doubt > > > > > > > there is anything you need to specify on this topic when > > > > > > defining an > > > > > > > Info-Package. All Info-Packages should be subject to the > > > > > same rules: > > > > > > > i.e., depending on the particular error response=20 > to an INFO > > > > > > request, > > > > > > > the dialog usage will either remain or be terminated. If > > > > > we need to > > > > > > > say anything more on this matter (e.g., the impact of > > > > 469), that > > > > > > > should be covered elsewhere in the document. I don't > > > > > think we need > > > > > > > 7.3. > > > > > > >=20 > > > > > > > John > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > Christer Holmberg > > > > > > > > Sent: 29 October 2009 07:42 > > > > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > > > > Cc: SIPCORE > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > Fate Sharing > > > > > > > >=20 > > > > > > > > Hi, > > > > > > > > =20 > > > > > > > > So, do people think we should keep the existing text > > > > > > (section 7.3), > > > > > > > > which talks about the dialog fate? > > > > > > > > =20 > > > > > > > > Regards. > > > > > > > > =20 > > > > > > > > Christer > > > > > > > >=20 > > > > > > > > ________________________________ > > > > > > > >=20 > > > > > > > > From: Sanjay Sinha (sanjsinh)=20 > [mailto:sanjsinh@cisco.com] > > > > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > > > > Cc: SIPCORE > > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > > Fate Sharing > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > I agree. > > > > > > > >=20 > > > > > > > > If the INFO transaction fails, then let the application > > > > > > > decide whether > > > > > > > > it wants to continue with the dialog or not? > > > > > > > >=20 > > > > > > > > Sanjay > > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On > > > > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > > > > To: Christer Holmberg > > > > > > > > Cc: SIPCORE > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > Fate Sharing > > > > > > > >=20 > > > > > > > > I don't think INFO should add any new dialog or usage > > > > > > failure cases. > > > > > > > > Errors that generically cause global failure,=20 > such as 408, > > > > > > > should of > > > > > > > > course do so for INFO as well. But specific failures of > > > > > > > INFO (legacy > > > > > > > > or with I-P) should only fail the transaction. > > > > > > > >=20 > > > > > > > > If in a particular case an application wants to consider > > > > > > > some result > > > > > > > > of and INFO to be fatal to the call it has=20 > ample means to > > > > > > > cause that > > > > > > > > to happen. > > > > > > > >=20 > > > > > > > > Thanks, > > > > > > > > Paul > > > > > > > >=20 > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I would like to point out the following WGLC comment > > > > > provided by > > > > > > > > Keith. > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > > > > > > > As described in [RFC5057], an INFO request=20 > is always > > > > > > part of an > > > > > > > > > INVITE dialog usage. > > > > > > > > > > > > > > > > > > One needs to consider the fate of the dialog usage > > > > > of an INFO > > > > > > > > request > > > > > > > > > is rejected. In some cases it may be=20 > acceptable that > > > > > > the whole > > > > > > > > > dialog usage is terminated, while in other > > cases is is > > > > > > > > desirable to > > > > > > > > > maintain the dialog usage. > > > > > > > > > > > > > > > > > > However as we have a specific new response code that > > > > > > represents a > > > > > > > > > failure of the INFO method extension rather than any > > > > > > > > specific package, > > > > > > > > I > > > > > > > > > believe the actions for 469 in respect of the > > dialog usage > > > > > > > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > Personally I agree with Keith - the fate of the dialog > > > > > > should not > > > > > > > > depend > > > > > > > > > on the package (and the SIP stack should not need to > > > > > > know package > > > > > > > > > specific behavior). > > > > > > > > > > > > > > > > > > So, we should, in the main part of the spec talking > > > > > about INFO > > > > > > > > > responses, specify whether 469 terminates the > > > invite dialog > > > > > > > > usage, or > > > > > > > > > just the transaction. > > > > > > > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > > > > dialog usage, > > > > > > > > because > > > > > > > > > the 469 could come due to a race condition, > > when I've sent > > > > > > > > a re-INVITE > > > > > > > >=20 > > > > > > > > > with a new set of Info Packages, but the remote > > UA sent an > > > > > > > > INFO based > > > > > > > > on > > > > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > -------------------------------------------------------------- > > > > > > > > ---------- > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > sipcore mailing list > > > > > > > > > sipcore@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > _______________________________________________ > > > > > > > > sipcore mailing list > > > > > > > > sipcore@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > 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 > > > > > > >=20 > > > > > >=20 > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Fri Oct 30 07:10:25 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993463A68ED for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 07:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F63fob+UhgHg for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 07:10:24 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2AF5B3A67E9 for <sipcore@ietf.org>; Fri, 30 Oct 2009 07:10:23 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-cf-4aeaf3deca6b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 71.61.04191.FD3FAEA4; Fri, 30 Oct 2009 15:10:39 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:10:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 15:10:36 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0F7E0BB5@esealmw113.eemea.ericsson.se> In-Reply-To: <4AE9A6CD.80907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: AcpYpD5FRQzPSEe8Rleq09IvvJdPKgAxSHEQ References: <CA9998CD4A020D418654FCDEF4E707DF083CD3E3@esealmw113.eemea.ericsson.se> <4AE9A6CD.80907@cisco.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-OriginalArrivalTime: 30 Oct 2009 14:10:38.0947 (UTC) FILETIME=[C1FD0330:01CA596A] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 14:10:25 -0000 Hi,=20 >>1) REF and SUB >>------------------------ >> =20 >>There has been some comments and question about whether we=20 >>should allow the R-I header field in REF and SUB. >> =20 >>Now, both REF and SUB are target refresh requests, and CAN=20 >>be sent within an invite dialog usage. However, I assume the=20 >>dialog-usage RFC recommends against doing so. >=20 >Even when REF/SUB and INVITE are sharing a dialog, I don't=20 >see any need to have R-I in the REF/SUB. It would only matter=20 >if the ref/sub was >*changing* the target to something with different properties=20 >than before. In that case a reINVITE can be sent to handle the R-I. So, if nobody indicates a reason why we should allow it in REF/SUB I will keep it away. >>2) ACK and PRA >>------------------------- >> =20 >>Keith suggested we shouldn't allow the header in ACK and PRA either. >> =20 >>Personally I would not like to make that restriction at=20 >>this point, unless there is a good technical reason, but I=20 >>would like to hear what other people think. >=20 >I see issues with ACK (not being authenticated) that others=20 >have mentioned, so it seems a bad choice. I have less trouble=20 >with PRACK, but can go either way. If we don't allow it in ACK, how will you implement the 3pcc case below? You would have to send an extra re-INVITE/UPDATE just because you couldn't send the I-P list in the ACK. Or? And, if there are no rules one can of course send a list both in the INVITE and the ACK. I don't know if that is likely to happen, but if the ACK trigger the remote entity's list to change it would have to trigger a request in order to change the list, since there is no response to ACK. So, maybe we should say that the I-P list can only be sent in INV OR ACK, or that the I-P list must be identical if sent in both INV AND ACK. >>3) "offer/answer" >>----------------------- >> =20 >>The draft currently does not define o/a type-of rules when=20 >>UAs are to indicate their Info Package set (using the=20 >>Recv-Info header field). >> =20 >>Personally I don't think we need to define a "o/a" rules=20 >>for Recv-Info. We only need to indicate in which message the=20 >>header field is allowed. >> =20 >>We could say that, when a UA receives the I-P set from the=20 >>remote user, it is recommend that it sends back its own set=20 >>as soon as possible - if the set has changed. >> =20 >>Because, if the set hasn't changed I don't think the UA=20 >>needs to send back anything, which means that whatever set it=20 >>has sent before within that dialog is still valid. That is=20 >>the biggest difference compared to o/a, which always requires=20 >>the receiver to send its SDP back - even if nothing has changed. >=20 >The situation here is less complex than o/a because this is=20 >really a declaration rather than a negotiation. >=20 >However, as always, issues can arise from 3pcc. A UA may=20 >receive a reinvite, and think nothing has changed, but in=20 >reality what is changing is that it has a peer UA that is not=20 >aware of its R-I settings. >So I think it should be recommended that R-I always be sent=20 >in response to a reinvite. Of course, that would require that the R-I header has previously been used during the dialog. Otherwise the UAS won't even know whether the sender supports I-P. >Also, to cover the case where the two ends get out of sync for some reason, I think it should be allowed, and suggested or required, to include R-I in a 469 response. At the moment my intention is to require it. Regards, Christer From pkyzivat@cisco.com Fri Oct 30 07:38:06 2009 Return-Path: <pkyzivat@cisco.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8EF3A68F9 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmUJHatRjp9O for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 07:38:05 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7693D3A67E9 for <sipcore@ietf.org>; Fri, 30 Oct 2009 07:38:05 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACeX6kqtJV2c/2dsb2JhbADKLJgjhD0E X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208";a="65718797" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2009 14:38:21 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id n9UEcLW1027695; Fri, 30 Oct 2009 14:38:21 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:38:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:38:21 -0400 Message-ID: <4AEAFA5D.4080204@cisco.com> Date: Fri, 30 Oct 2009 10:38:21 -0400 From: Paul Kyzivat <pkyzivat@cisco.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg <christer.holmberg@ericsson.com> References: <CA9998CD4A020D418654FCDEF4E707DF083CD3E3@esealmw113.eemea.ericsson.se> <4AE9A6CD.80907@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0BB5@esealmw113.eemea.ericsson.se> In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0F7E0BB5@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2009 14:38:21.0263 (UTC) FILETIME=[A0CE4DF0:01CA596E] Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 14:38:06 -0000 Christer Holmberg wrote: >>> 2) ACK and PRA >>> ------------------------- >>> >>> Keith suggested we shouldn't allow the header in ACK and PRA either. >>> >>> Personally I would not like to make that restriction at >>> this point, unless there is a good technical reason, but I >>> would like to hear what other people think. >> I see issues with ACK (not being authenticated) that others >> have mentioned, so it seems a bad choice. I have less trouble >> with PRACK, but can go either way. > > If we don't allow it in ACK, how will you implement the 3pcc case below? Good point. I take it back. > You would have to send an extra re-INVITE/UPDATE just because you > couldn't send the I-P list in the ACK. Or? > > And, if there are no rules one can of course send a list both in the > INVITE and the ACK. I don't know if that is likely to happen, but if the > ACK trigger the remote entity's list to change it would have to trigger > a request in order to change the list, since there is no response to > ACK. But this is not a negotiation, just a declaration. So what harm is there in changing between INVITE and ACK? (As unlikely as that seems.) > So, maybe we should say that the I-P list can only be sent in INV OR > ACK, or that the I-P list must be identical if sent in both INV AND ACK. I don't feel strongly about it. But every additional requirement is something else to test. >> However, as always, issues can arise from 3pcc. A UA may >> receive a reinvite, and think nothing has changed, but in >> reality what is changing is that it has a peer UA that is not >> aware of its R-I settings. >> So I think it should be recommended that R-I always be sent >> in response to a reinvite. > > Of course, that would require that the R-I header has previously been > used during the dialog. Otherwise the UAS won't even know whether the > sender supports I-P. Which dialog? Since this is 3pcc, and the interesting case is a transfer, there are *3* dialogs. It should never hurt to send an R-I in the context of a response to a reinvite. There may indeed be a problem in one case. Here's a picture to refer to: A ----- B ----- C | --- D Initially A is connected, via B to C. Then B initiates a 3pcc transfer by sending a reinvite to A. Now suppose that both A and C support I-P, but D does not. How will A ever learn that D does not? It won't receive an R-I header from D, and so will assume its unchanged from what it had from C. And when it sends INFOs with an I-P, D will think they are legacy. It will never send a 469, so it won't quench the sending. To solve that, I think the reinvite exchange must always redeclare the R-I in both directions. >> Also, to cover the case where the two ends get out of sync for some > reason, I think it should be allowed, and suggested or required, to > include R-I in a 469 response. > > At the moment my intention is to require it. OK, that's good. I didn't even see it allowed in the 469 response in Table 2 updates. Thanks, Paul > Regards, > > Christer > From drage@alcatel-lucent.com Fri Oct 30 08:05:43 2009 Return-Path: <drage@alcatel-lucent.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB18E3A6969 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 08:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.634 X-Spam-Level: X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb83jXbMg4PU for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 08:05:42 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9F9B53A692D for <sipcore@ietf.org>; Fri, 30 Oct 2009 08:05:41 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9UF5q3u018801 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Oct 2009 16:05:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 30 Oct 2009 16:05:52 +0100 From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com> To: Christer Holmberg <christer.holmberg@ericsson.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> Date: Fri, 30 Oct 2009 16:05:50 +0100 Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing Thread-Index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwAAASdAgAABJ9nAAACH0UAAC/D/Q Message-ID: <EDC0A1AE77C57744B664A310A0B23AE2092A7627@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C2@esealmw113.eemea.ericsson.se><4AE8B942.1090506@cisco.com><C7FFFFDD779F2047A0FBAC811C5C5A0009AB079D@xmb-rtp-201.amer.cisco.com><CA9998CD4A020D418654FCDEF4E707DF083CD3E1@esealmw113.eemea.ericsson.se><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net><EDC0A1AE77C57744B664A310A0B23AE20925F42C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><CA9998CD4A020D418654FCDEF4E707DF0B1685CC@esealmw113.eemea.ericsson.se><EDC0A1AE77C57744B664A310A0B23AE2092A749E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0B1685CD@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A07@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75DE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0B22@esealmw113.eemea.ericsson.se> In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0F7E0B22@esealmw113.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-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: SIPCORE <sipcore@ietf.org> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 15:05:44 -0000 I think we had a discussion way back about the terms UAC and UAS and unders= tood them to be confusing in the context of INFO. It may be better to use t= erms "INFO request client" and "INFO request server" as section titles. regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, October 30, 2009 1:52 PM > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > (sanjsinh); Paul Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > The problem is that we don't have "UAC Procedures" and "UAS > Procedures" > sections. We used to have that, but the text got very confusing. > > Having said that, when I look at the text in the "4.2 INFO > Request" and > "4.4 INFO Response" sections, I guess we COULD simply rename > them to "User Agent Client procedures" and "User Agent Server > procedures", without any major changes in the section itself. > It would be more alligned with the structure of section 3. > > Regards, > > Christer > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 30. lokakuuta 2009 15:36 > > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > > Please keep INFO method sender and INFO method receiver > requirements > > in different sections. > > > > Keith > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Friday, October 30, 2009 1:31 PM > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > > > > > > > Hi, > > > > > > I could simply divide the paragraphs into two parts, and > > add some text > > > to the end of the new second paragraph: > > > > > > "If a UA receives an INFO request associated with an Info > > Package that > > > the UA has not indicated willingness to receive, the UA > MUST send a > > > 469 Bad INFO Package response Section 11.6. > > > > > > In the terminology of Multiple Dialog Usages [RFC5057], the > > > 469 Bad INFO Package Response represents a Transaction Only > > failure, > > > and a UA MUST NOT terminate the invite dialog usage when it > > sends or > > > receives a 469 response." > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: 30. lokakuuta 2009 15:20 > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > > Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > Fate Sharing > > > > > > > > Which covers the sender of the 469 but not the receiver. > > > > Apply the author guidelines and separate sender and receiver > > > > requirements into different sections. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Friday, October 30, 2009 1:14 PM > > > > > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, > > John; Sanjay > > > > > Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I realized that section 4.4 already contains the following > > > > text about > > > > > 469: > > > > > > > > > > "In the terminology of Multiple Dialog Usages [RFC5057], this > > > > > represents a Transaction Only failure." > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Christer Holmberg > > > > > > Sent: 29. lokakuuta 2009 22:19 > > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > > (sanjsinh); Paul > > > > > > Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > My suggestion is to go with Robert's proposal, then and > > > > > somewhere (in > > > > > > Section 4.x) generally indciate that 469 only affects the > > > > > transaction, > > > > > > and then remote the text from section 7. > > > > > > > > > > > > We used to have a section dedicated to the 469 response, so > > > > > I guess it > > > > > > could have fitted there also, but I was asked to remove it > > > > > because the > > > > > > text at that time didn't really bring anything new. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > > Sent: 29. lokakuuta 2009 17:52 > > > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > > > (sanjsinh); Paul > > > > > > Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > > > > > > > > Treat the 469 dialog handling text and the existing > 7.3 text > > > > > > separately. > > > > > > > > > > > > The 469 dialog handling belongs somewhere around the area > > > > > of (but not > > > > > > in) section 4.4. > > > > > > > > > > > > The 7.3 text should probably stay (in my view), and if it > > > > stays, it > > > > > > belongs where it currently is. If the consensus is to > > > > remove it (as > > > > > > suggested by some other people), then that is also fine, > > > > > but I have no > > > > > > problem keeping it. > > > > > > > > > > > > regards > > > > > > > > > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: Thursday, October 29, 2009 1:35 PM > > > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > > > (sanjsinh); Paul > > > > > > > Kyzivat (pkyzivat) > > > > > > > Cc: SIPCORE > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I am not sure I understood what you said, but I'll give > > > > it a try. > > > > > > > > > > > > > > >Any specific text on receipt of 469 should go in the most > > > > > > appropriate > > > > > > > section, which is definitely not section 7 - I would > > > > > > suggest somewhere > > > > > > > > > > > > > around > > > > > > > >section 4.4, but not in 4.4 because this is all UAS > > > > > > functionality and > > > > > > > we want UAC functionality. > > > > > > > > > > > > > > Ok, so whatever text we write should not be in > > section 7, but > > > > > > > somewhere else. Then, the section 7 text is > > removed, and the > > > > > > > individual Info Package specifications do not need to say > > > > > anything > > > > > > > about the dialog fate? > > > > > > > > > > > > > > Or? > > > > > > > > > > > > > > >With 469 we do not have a Info-Package, becuase > > the receiver > > > > > > > was unable > > > > > > > to recognise one that was valid. If for example two > > had been > > > > > > > previously > > > > > > > >negotiated with Recv-Info, it could be either of them, or > > > > > > indeed the > > > > > > > unnegotiated appearance of a third. That is why I > think the > > > > > > issue is > > > > > > > generic rather > > > > > > > >than Info Package specific. > > > > > > > > > > > > > > I think you will only send 469 if the INFO request > > contained > > > > > > > Info-Package, and the idea is that the 469 contains the > > > > > > latest set of > > > > > > > packages. One must not use the 469 to CHANGE the set, and > > > > > maybe we > > > > > > > need to make that clear. > > > > > > > > > > > > > > >I would confirm that I see no need to kill the dialog but > > > > > > merely the > > > > > > > transaction. > > > > > > > > > > > > > > I agree with you. The question is whether we need to say > > > > > something > > > > > > > about it. Based on what others say, it seems like we > > > > > > wouldn't need any > > > > > > > > > > > > > text at all about dialog fate. But, my head is so full of > > > > > > INFO that it > > > > > > > > > > > > > soon explodes, so I may have missunderstood :) > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: sipcore-bounces@ietf.org > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Elwell, John > > > > > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); > > Paul Kyzivat > > > > > > > > (pkyzivat) > > > > > > > > Cc: SIPCORE > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > Fate Sharing > > > > > > > > > > > > > > > > Christer, > > > > > > > > > > > > > > > > This is in the section on Info Package considerations. I > > > > > > > rather doubt > > > > > > > > there is anything you need to specify on this topic when > > > > > > > defining an > > > > > > > > Info-Package. All Info-Packages should be subject to the > > > > > > same rules: > > > > > > > > i.e., depending on the particular error response > > to an INFO > > > > > > > request, > > > > > > > > the dialog usage will either remain or be terminated. If > > > > > > we need to > > > > > > > > say anything more on this matter (e.g., the impact of > > > > > 469), that > > > > > > > > should be covered elsewhere in the document. I don't > > > > > > think we need > > > > > > > > 7.3. > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: sipcore-bounces@ietf.org > > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > Christer Holmberg > > > > > > > > > Sent: 29 October 2009 07:42 > > > > > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > So, do people think we should keep the existing text > > > > > > > (section 7.3), > > > > > > > > > which talks about the dialog fate? > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Sanjay Sinha (sanjsinh) > > [mailto:sanjsinh@cisco.com] > > > > > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree. > > > > > > > > > > > > > > > > > > If the INFO transaction fails, then let the > application > > > > > > > > decide whether > > > > > > > > > it wants to continue with the dialog or not? > > > > > > > > > > > > > > > > > > Sanjay > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: sipcore-bounces@ietf.org > > > > > > > [mailto:sipcore-bounces@ietf.org] On > > > > > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > > > > > To: Christer Holmberg > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > I don't think INFO should add any new dialog or usage > > > > > > > failure cases. > > > > > > > > > Errors that generically cause global failure, > > such as 408, > > > > > > > > should of > > > > > > > > > course do so for INFO as well. But specific > failures of > > > > > > > > INFO (legacy > > > > > > > > > or with I-P) should only fail the transaction. > > > > > > > > > > > > > > > > > > If in a particular case an application wants > to consider > > > > > > > > some result > > > > > > > > > of and INFO to be fatal to the call it has > > ample means to > > > > > > > > cause that > > > > > > > > > to happen. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I would like to point out the following WGLC comment > > > > > > provided by > > > > > > > > > Keith. > > > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > > > > > > > > > As described in [RFC5057], an INFO request > > is always > > > > > > > part of an > > > > > > > > > > INVITE dialog usage. > > > > > > > > > > > > > > > > > > > > One needs to consider the fate of the > dialog usage > > > > > > of an INFO > > > > > > > > > request > > > > > > > > > > is rejected. In some cases it may be > > acceptable that > > > > > > > the whole > > > > > > > > > > dialog usage is terminated, while in other > > > cases is is > > > > > > > > > desirable to > > > > > > > > > > maintain the dialog usage. > > > > > > > > > > > > > > > > > > > > However as we have a specific new response code that > > > > > > > represents a > > > > > > > > > > failure of the INFO method extension rather than any > > > > > > > > > specific package, > > > > > > > > > I > > > > > > > > > > believe the actions for 469 in respect of the > > > dialog usage > > > > > > > > > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > > Personally I agree with Keith - the fate of > the dialog > > > > > > > should not > > > > > > > > > depend > > > > > > > > > > on the package (and the SIP stack should not need to > > > > > > > know package > > > > > > > > > > specific behavior). > > > > > > > > > > > > > > > > > > > > So, we should, in the main part of the spec talking > > > > > > about INFO > > > > > > > > > > responses, specify whether 469 terminates the > > > > invite dialog > > > > > > > > > usage, or > > > > > > > > > > just the transaction. > > > > > > > > > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > > > > > dialog usage, > > > > > > > > > because > > > > > > > > > > the 469 could come due to a race condition, > > > when I've sent > > > > > > > > > a re-INVITE > > > > > > > > > > > > > > > > > > > with a new set of Info Packages, but the remote > > > UA sent an > > > > > > > > > INFO based > > > > > > > > > on > > > > > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > sipcore mailing list > > > > > > > > > sipcore@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > sipcore mailing list > > > > > > > > sipcore@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > From kpfleming@digium.com Fri Oct 30 09:10:29 2009 Return-Path: <kpfleming@digium.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208DF28C0E5 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.819 X-Spam-Level: X-Spam-Status: No, score=-104.819 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvrSMyF0dLFQ for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 09:10:28 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id EF8C828C0E0 for <sipcore@ietf.org>; Fri, 30 Oct 2009 09:10:27 -0700 (PDT) Received: from jupiler.digium.internal ([10.19.29.150] helo=jupiler.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1N3u3o-0008Jh-EK for sipcore@ietf.org; Fri, 30 Oct 2009 11:10:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by jupiler.digium.com (Postfix) with ESMTP id 5EB9129E0002 for <sipcore@ietf.org>; Fri, 30 Oct 2009 11:10:44 -0500 (CDT) Received: from jupiler.digium.com ([127.0.0.1]) by localhost (jupiler.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn06afnnD+ta for <sipcore@ietf.org>; Fri, 30 Oct 2009 11:10:43 -0500 (CDT) Received: from [10.24.20.235] (kildare.digium.internal [10.24.20.235]) (Authenticated sender: kpfleming) by jupiler.digium.com (Postfix) with ESMTP id 20C9329E0003 for <sipcore@ietf.org>; Fri, 30 Oct 2009 11:10:43 -0500 (CDT) Message-ID: <4AEB1002.6090407@digium.com> Date: Fri, 30 Oct 2009 11:10:42 -0500 From: "Kevin P. Fleming" <kpfleming@digium.com> Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: SIPCORE <sipcore@ietf.org> References: <4AE5AD21.6070603@ericsson.com> In-Reply-To: <4AE5AD21.6070603@ericsson.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Re-INVITE handling draft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 16:10:29 -0000 Gonzalo Camarillo wrote: > Folks, > > I have just submitted a new version of the re-INVITE handling draft: > > http://www.ietf.org/id/draft-camarillo-sipcore-reinvite-01.txt > > This revision reflects the conclusions reached during the extensive > discussions we had on this topic. Comments on the whole draft are very > welcome. Additionally, there is an issue marked as TODO, which is > related to RFC 3264. You may want to comment on that as well. Quoting from the draft: either. A UA considers the new parameters to be in use when it sends media using them, or when media that uses the new parameters is received, which should be interpreted as follows. From Section 8.3.1 of RFC 3264 [RFC3264]: "Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port." TODO: RFC3264 assumes media streams that carry media continuously. So, it considers that an UA should continue listening to the old port (i.e., using the old parameters) until it sends media or receives media on the new port. An area of complication we have been dealing with when supporting T.38 FAX is that some endpoints will setup the session with a single 'audio' media stream, and then when they desire to switch to T.38, they'll send a re-INVITE dropping that audio stream and adding an image/t38 stream, using the *same port* that the audio stream was using. In addition, a particular implementation assumes that at the moment it receives a non-error final response to the re-INVITE, that it should no longer receive any audio media to that port, but instead will receive only UDPTL media. This is effectively impossible to achieve, given that signaling and media are frequently not controlled by the same application (or even on the same machine), and that there could very well be audio media packets in transit to the receiver at the same time that the final response is sent to the receiver. Would it be appropriate to add recommendations/clarifications to this draft strongly suggesting that this sort of behavior is not a wise implementation choice? I've heard comments from a couple of people that reusing the port "improves NAT traversal abilities", but in reality I don't see how that is possible unless *both* ends make the media stream change without changing port numbers. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@digium.com Check us out at www.digium.com & www.asterisk.org From krisztian.kiss@nokia.com Fri Oct 30 16:33:19 2009 Return-Path: <krisztian.kiss@nokia.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63EAC3A6933 for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 16:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.033 X-Spam-Level: X-Spam-Status: No, score=-5.033 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ntDkOGofpGf for <sipcore@core3.amsl.com>; Fri, 30 Oct 2009 16:33:17 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5C91B3A68DE for <sipcore@ietf.org>; Fri, 30 Oct 2009 16:33:16 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9UNXUY4004620 for <sipcore@ietf.org>; Sat, 31 Oct 2009 01:33:30 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 01:33:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 01:33:25 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sat, 31 Oct 2009 00:33:24 +0100 From: <krisztian.kiss@nokia.com> To: <sipcore@ietf.org> Date: Sat, 31 Oct 2009 00:33:20 +0100 Thread-Topic: draft-ietf-sipcore-event-rate-control-01 Thread-Index: AcpWf2o0MXYN/szqR9qZhptfrT5YKwAXku0gALZ3kLA= Message-ID: <A80667440D58A1469E651BA443BED3C14DE6506D73@NOK-EUMSG-01.mgdnok.nokia.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-OriginalArrivalTime: 30 Oct 2009 23:33:25.0065 (UTC) FILETIME=[6029BB90:01CA59B9] X-Nokia-AV: Clean Subject: [sipcore] draft-ietf-sipcore-event-rate-control-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 30 Oct 2009 23:33:19 -0000 All, An updated version of the event-rate-control draft was recently submitted (= after the IETF76 deadline). Until it appears in the I-D repository, you can= fetch a copy from http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-= control-01.txt The changes include: - All rate control parameters can now be updated in 200-class responses to = a NOTIFY request (in addition to setting the parameters in the SUBSCRIBE re= quest). See related discussion in GEOPRIV: http://www.ietf.org/mail-archive= /web/geopriv/current/msg07766.html. This change also requires mandating the= Event header field in 200-class responses to a NOTIFY request. - Emphasized that rate control parameters can be changed at any time by the= notifier based on local policy or implementation-determined constraints. - In minimum rate mechanism, the NOTIFY request may contain partial or full= state depending on what the event package specifies. Previously, a NOTIFY = with full state was always pushed to the subscriber when the max-interval i= ndicated, even if nothing has changed from the previous NOTIFY. - other minor wordsmithing changes. Cheers, Krisztian From jbemmel@zonnet.nl Sat Oct 31 03:51:08 2009 Return-Path: <jbemmel@zonnet.nl> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EEF3A6830 for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 03:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsNRxZfSCrPt for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 03:51:07 -0700 (PDT) Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by core3.amsl.com (Postfix) with ESMTP id 6DA873A682C for <sipcore@ietf.org>; Sat, 31 Oct 2009 03:51:04 -0700 (PDT) Received: (qmail 6089 invoked by uid 0); 31 Oct 2009 10:51:19 -0000 Received: from ip198-11-212-87.adsl2.static.versatel.nl (HELO [192.168.1.5]) ([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 31 Oct 2009 10:51:19 -0000 Message-ID: <4AEC16A5.6050809@zonnet.nl> Date: Sat, 31 Oct 2009 11:51:17 +0100 From: Jeroen van Bemmel <jbemmel@zonnet.nl> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: krisztian.kiss@nokia.com References: <A80667440D58A1469E651BA443BED3C14DE6506D73@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <A80667440D58A1469E651BA443BED3C14DE6506D73@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-event-rate-control-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 31 Oct 2009 10:51:08 -0000 Krisztian, As input for discussion: - some years ago we submitted a similar draft, but focused on rate control for publications: http://tools.ietf.org/html/draft-brok-simple-regulate-publish-02 - did you consider passing on the rate control information in watcher info? (i.e. extend the winfo package of RFC3857) Regards, Jeroen krisztian.kiss@nokia.com wrote: > All, > > An updated version of the event-rate-control draft was recently submitted (after the IETF76 deadline). Until it appears in the I-D repository, you can fetch a copy from http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-01.txt > > The changes include: > - All rate control parameters can now be updated in 200-class responses to a NOTIFY request (in addition to setting the parameters in the SUBSCRIBE request). See related discussion in GEOPRIV: http://www.ietf.org/mail-archive/web/geopriv/current/msg07766.html. This change also requires mandating the Event header field in 200-class responses to a NOTIFY request. > - Emphasized that rate control parameters can be changed at any time by the notifier based on local policy or implementation-determined constraints. > - In minimum rate mechanism, the NOTIFY request may contain partial or full state depending on what the event package specifies. Previously, a NOTIFY with full state was always pushed to the subscriber when the max-interval indicated, even if nothing has changed from the previous NOTIFY. > - other minor wordsmithing changes. > > Cheers, > Krisztian > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Sat Oct 31 05:28:55 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62853A6897 for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 05:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5JJOvsVNPvT for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 05:28:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 495803A6876 for <sipcore@ietf.org>; Sat, 31 Oct 2009 05:28:51 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-ce-4aec2d9326cf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id C1.7B.04191.39D2CEA4; Sat, 31 Oct 2009 13:29:07 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 13:28:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Oct 2009 13:27:32 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B1685DE@esealmw113.eemea.ericsson.se> In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE2092A7627@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info-Event Open Issue: Dialog Fate Sharing thread-index: AcpYFraLM5T+Z7mhQpCyfWcyz7qSTgATjLegAAGYZGQABLa38AAAwPkwAAaqF7AABOcvYAAJS+QgACK/wWAAAPhxwAAASdAgAABJ9nAAACH0UAAC/D/QACzAUiA= References: <CA9998CD4A020D418654FCDEF4E707DF0B1685C2@esealmw113.eemea.ericsson.se><4AE8B942.1090506@cisco.com><C7FFFFDD779F2047A0FBAC811C5C5A0009AB079D@xmb-rtp-201.amer.cisco.com><CA9998CD4A020D418654FCDEF4E707DF083CD3E1@esealmw113.eemea.ericsson.se><7402509E63C5A145A6095D46C179A5B7148B382D@DEMCHP99E35MSX.ww902.siemens.net><EDC0A1AE77C57744B664A310A0B23AE20925F42C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com><CA9998CD4A020D418654FCDEF4E707DF0B1685CC@esealmw113.eemea.ericsson.se><EDC0A1AE77C57744B664A310A0B23AE2092A749E@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0B1685CD@esealmw113.eemea.ericsson.se> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A07@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75D2@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0A7B@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE2092A75DE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0B22@esealmw1 13.eemea .ericsson.se > <EDC0A1AE77C57744B664A310A0B23AE2092A7627@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Elwell, John" <john.elwell@siemens-enterprise.com>, "Sanjay Sinha (sanjsinh)" <sanjsinh@cisco.com>, "Paul Kyzivat (pkyzivat)" <pkyzivat@cisco.com> X-OriginalArrivalTime: 31 Oct 2009 12:28:07.0690 (UTC) FILETIME=[99F76EA0:01CA5A25] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE <sipcore@ietf.org> Subject: Re: [sipcore] Info-Event Open Issue: Dialog Fate Sharing X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 31 Oct 2009 12:28:55 -0000 Hi,=20 >I think we had a discussion way back about the terms UAC and UAS and understood them to be confusing in the context of INFO. It may be better to use terms "INFO request client" and "INFO request server"=20 >as section titles. Yes, I was thinking about something like that. OR "INFO request sender" and "INFO request receiver". That terminology would also have made lots of specifications easier to write, in my opinion :) Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, October 30, 2009 1:52 PM > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha (sanjsinh); Paul=20 > Kyzivat (pkyzivat) > Cc: SIPCORE > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > The problem is that we don't have "UAC Procedures" and "UAS=20 > Procedures" > sections. We used to have that, but the text got very confusing. > > Having said that, when I look at the text in the "4.2 INFO Request"=20 > and > "4.4 INFO Response" sections, I guess we COULD simply rename them to=20 > "User Agent Client procedures" and "User Agent Server procedures",=20 > without any major changes in the section itself. > It would be more alligned with the structure of section 3. > > Regards, > > Christer > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 30. lokakuuta 2009 15:36 > > To: Christer Holmberg; Elwell, John; Sanjay Sinha (sanjsinh); Paul=20 > > Kyzivat (pkyzivat) > > Cc: SIPCORE > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > > Please keep INFO method sender and INFO method receiver > requirements > > in different sections. > > > > Keith > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Friday, October 30, 2009 1:31 PM > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > Kyzivat (pkyzivat) > > > Cc: SIPCORE > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog Fate Sharing > > > > > > > > > Hi, > > > > > > I could simply divide the paragraphs into two parts, and > > add some text > > > to the end of the new second paragraph: > > > > > > "If a UA receives an INFO request associated with an Info > > Package that > > > the UA has not indicated willingness to receive, the UA > MUST send a > > > 469 Bad INFO Package response Section 11.6. > > > > > > In the terminology of Multiple Dialog Usages [RFC5057], the > > > 469 Bad INFO Package Response represents a Transaction Only > > failure, > > > and a UA MUST NOT terminate the invite dialog usage when it > > sends or > > > receives a 469 response." > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: 30. lokakuuta 2009 15:20 > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > (sanjsinh); Paul > > > > Kyzivat (pkyzivat) > > > > Cc: SIPCORE > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > Fate Sharing > > > > > > > > Which covers the sender of the 469 but not the receiver. > > > > Apply the author guidelines and separate sender and receiver=20 > > > > requirements into different sections. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Friday, October 30, 2009 1:14 PM > > > > > To: Christer Holmberg; DRAGE, Keith (Keith); Elwell, > > John; Sanjay > > > > > Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > Cc: SIPCORE > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > Fate Sharing > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I realized that section 4.4 already contains the following > > > > text about > > > > > 469: > > > > > > > > > > "In the terminology of Multiple Dialog Usages [RFC5057], this=20 > > > > > represents a Transaction Only failure." > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Christer Holmberg > > > > > > Sent: 29. lokakuuta 2009 22:19 > > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > > (sanjsinh); Paul > > > > > > Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > My suggestion is to go with Robert's proposal, then and > > > > > somewhere (in > > > > > > Section 4.x) generally indciate that 469 only affects the > > > > > transaction, > > > > > > and then remote the text from section 7. > > > > > > > > > > > > We used to have a section dedicated to the 469 response, so > > > > > I guess it > > > > > > could have fitted there also, but I was asked to remove it > > > > > because the > > > > > > text at that time didn't really bring anything new. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > > Sent: 29. lokakuuta 2009 17:52 > > > > > > To: Christer Holmberg; Elwell, John; Sanjay Sinha > > > > (sanjsinh); Paul > > > > > > Kyzivat (pkyzivat) > > > > > > Cc: SIPCORE > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > Fate Sharing > > > > > > > > > > > > Treat the 469 dialog handling text and the existing > 7.3 text > > > > > > separately. > > > > > > > > > > > > The 469 dialog handling belongs somewhere around the area > > > > > of (but not > > > > > > in) section 4.4. > > > > > > > > > > > > The 7.3 text should probably stay (in my view), and if it > > > > stays, it > > > > > > belongs where it currently is. If the consensus is to > > > > remove it (as > > > > > > suggested by some other people), then that is also fine, > > > > > but I have no > > > > > > problem keeping it. > > > > > > > > > > > > regards > > > > > > > > > > > > Keith > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: Thursday, October 29, 2009 1:35 PM > > > > > > > To: DRAGE, Keith (Keith); Elwell, John; Sanjay Sinha > > > > > > (sanjsinh); Paul > > > > > > > Kyzivat (pkyzivat) > > > > > > > Cc: SIPCORE > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > Fate Sharing > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I am not sure I understood what you said, but I'll give > > > > it a try. > > > > > > > > > > > > > > >Any specific text on receipt of 469 should go in the most > > > > > > appropriate > > > > > > > section, which is definitely not section 7 - I would > > > > > > suggest somewhere > > > > > > > > > > > > > around > > > > > > > >section 4.4, but not in 4.4 because this is all UAS > > > > > > functionality and > > > > > > > we want UAC functionality. > > > > > > > > > > > > > > Ok, so whatever text we write should not be in > > section 7, but > > > > > > > somewhere else. Then, the section 7 text is > > removed, and the > > > > > > > individual Info Package specifications do not need to say > > > > > anything > > > > > > > about the dialog fate? > > > > > > > > > > > > > > Or? > > > > > > > > > > > > > > >With 469 we do not have a Info-Package, becuase > > the receiver > > > > > > > was unable > > > > > > > to recognise one that was valid. If for example two > > had been > > > > > > > previously > > > > > > > >negotiated with Recv-Info, it could be either of them, or > > > > > > indeed the > > > > > > > unnegotiated appearance of a third. That is why I > think the > > > > > > issue is > > > > > > > generic rather > > > > > > > >than Info Package specific. > > > > > > > > > > > > > > I think you will only send 469 if the INFO request > > contained > > > > > > > Info-Package, and the idea is that the 469 contains the > > > > > > latest set of > > > > > > > packages. One must not use the 469 to CHANGE the set, and > > > > > maybe we > > > > > > > need to make that clear. > > > > > > > > > > > > > > >I would confirm that I see no need to kill the dialog but > > > > > > merely the > > > > > > > transaction. > > > > > > > > > > > > > > I agree with you. The question is whether we need to say > > > > > something > > > > > > > about it. Based on what others say, it seems like we > > > > > > wouldn't need any > > > > > > > > > > > > > text at all about dialog fate. But, my head is so full of > > > > > > INFO that it > > > > > > > > > > > > > soon explodes, so I may have missunderstood :) > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > Elwell, John > > > > > > > > Sent: Thursday, October 29, 2009 10:05 AM > > > > > > > > To: Christer Holmberg; Sanjay Sinha (sanjsinh); > > Paul Kyzivat > > > > > > > > (pkyzivat) > > > > > > > > Cc: SIPCORE > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > Fate Sharing > > > > > > > > > > > > > > > > Christer, > > > > > > > > > > > > > > > > This is in the section on Info Package considerations. I > > > > > > > rather doubt > > > > > > > > there is anything you need to specify on this topic when > > > > > > > defining an > > > > > > > > Info-Package. All Info-Packages should be subject to the > > > > > > same rules: > > > > > > > > i.e., depending on the particular error response > > to an INFO > > > > > > > request, > > > > > > > > the dialog usage will either remain or be terminated. If > > > > > > we need to > > > > > > > > say anything more on this matter (e.g., the impact of > > > > > 469), that > > > > > > > > should be covered elsewhere in the document. I don't > > > > > > think we need > > > > > > > > 7.3. > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: sipcore-bounces@ietf.org=20 > > > > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of > > > > > Christer Holmberg > > > > > > > > > Sent: 29 October 2009 07:42 > > > > > > > > > To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat) > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > So, do people think we should keep the existing text > > > > > > > (section 7.3), > > > > > > > > > which talks about the dialog fate? > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > From: Sanjay Sinha (sanjsinh) > > [mailto:sanjsinh@cisco.com] > > > > > > > > > Sent: Thu 10/29/2009 7:57 AM > > > > > > > > > To: Paul Kyzivat (pkyzivat); Christer Holmberg > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: RE: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree. > > > > > > > > > > > > > > > > > > If the INFO transaction fails, then let the > application > > > > > > > > decide whether > > > > > > > > > it wants to continue with the dialog or not? > > > > > > > > > > > > > > > > > > Sanjay > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: sipcore-bounces@ietf.org > > > > > > > [mailto:sipcore-bounces@ietf.org] On > > > > > > > > > Behalf Of Paul Kyzivat (pkyzivat) > > > > > > > > > Sent: Thursday, October 29, 2009 3:06 AM > > > > > > > > > To: Christer Holmberg > > > > > > > > > Cc: SIPCORE > > > > > > > > > Subject: Re: [sipcore] Info-Event Open Issue: Dialog > > > > > > Fate Sharing > > > > > > > > > > > > > > > > > > I don't think INFO should add any new dialog or usage > > > > > > > failure cases. > > > > > > > > > Errors that generically cause global failure, > > such as 408, > > > > > > > > should of > > > > > > > > > course do so for INFO as well. But specific > failures of > > > > > > > > INFO (legacy > > > > > > > > > or with I-P) should only fail the transaction. > > > > > > > > > > > > > > > > > > If in a particular case an application wants > to consider > > > > > > > > some result > > > > > > > > > of and INFO to be fatal to the call it has > > ample means to > > > > > > > > cause that > > > > > > > > > to happen. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Paul > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I would like to point out the following WGLC comment > > > > > > provided by > > > > > > > > > Keith. > > > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > > "7.3. Dialog Fate Sharing > > > > > > > > > > > > > > > > > > > > As described in [RFC5057], an INFO request > > is always > > > > > > > part of an > > > > > > > > > > INVITE dialog usage. > > > > > > > > > > > > > > > > > > > > One needs to consider the fate of the > dialog usage > > > > > > of an INFO > > > > > > > > > request > > > > > > > > > > is rejected. In some cases it may be > > acceptable that > > > > > > > the whole > > > > > > > > > > dialog usage is terminated, while in other > > > cases is is > > > > > > > > > desirable to > > > > > > > > > > maintain the dialog usage. > > > > > > > > > > > > > > > > > > > > However as we have a specific new response code that > > > > > > > represents a > > > > > > > > > > failure of the INFO method extension rather than any > > > > > > > > > specific package, > > > > > > > > > I > > > > > > > > > > believe the actions for 469 in respect of the > > > dialog usage > > > > > > > > > > > > > > > > > > > > should be defined in this document." > > > > > > > > > > > > > > > > > > > > ------------------ > > > > > > > > > > > > > > > > > > > > Personally I agree with Keith - the fate of > the dialog > > > > > > > should not > > > > > > > > > depend > > > > > > > > > > on the package (and the SIP stack should not need to > > > > > > > know package > > > > > > > > > > specific behavior). > > > > > > > > > > > > > > > > > > > > So, we should, in the main part of the spec talking > > > > > > about INFO > > > > > > > > > > responses, specify whether 469 terminates the > > > > invite dialog > > > > > > > > > usage, or > > > > > > > > > > just the transaction. > > > > > > > > > > > > > > > > > > > > I don't see a reason to terminte the whole invite > > > > > > dialog usage, > > > > > > > > > because > > > > > > > > > > the 469 could come due to a race condition, > > > when I've sent > > > > > > > > > a re-INVITE > > > > > > > > > > > > > > > > > > > with a new set of Info Packages, but the remote > > > UA sent an > > > > > > > > > INFO based > > > > > > > > > on > > > > > > > > > > the old set before it received the re-INVITE. > > > > > > > > > > > > > > > > > > > > But, I guess Robert can give some guidance. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > > ---------- > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > sipcore mailing list sipcore@ietf.org=20 > > > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > _______________________________________________ > > > > > > > > > sipcore mailing list > > > > > > > > > sipcore@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > sipcore mailing list > > > > > > > > > sipcore@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 christer.holmberg@ericsson.com Sat Oct 31 05:50:14 2009 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874C73A68C9 for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 05:50:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYxsYxiiL1Mz for <sipcore@core3.amsl.com>; Sat, 31 Oct 2009 05:50:13 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2E4D93A659B for <sipcore@ietf.org>; Sat, 31 Oct 2009 05:50:12 -0700 (PDT) X-AuditID: c1b4fb3c-b7b3fae00000105f-5c-4aec32950707 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 92.CB.04191.5923CEA4; Sat, 31 Oct 2009 13:50:29 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 13:49:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Oct 2009 13:48:59 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B1685E1@esealmw113.eemea.ericsson.se> In-Reply-To: <4AEAFA5D.4080204@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info thread-index: AcpZbqSl/yUDaDh/Rg65RXcs+6lkMgAt8s5w References: <CA9998CD4A020D418654FCDEF4E707DF083CD3E3@esealmw113.eemea.ericsson.se> <4AE9A6CD.80907@cisco.com> <CA9998CD4A020D418654FCDEF4E707DF0F7E0BB5@esealmw113.eemea.ericsson.se> <4AEAFA5D.4080204@cisco.com> From: "Christer Holmberg" <christer.holmberg@ericsson.com> To: "Paul Kyzivat" <pkyzivat@cisco.com> X-OriginalArrivalTime: 31 Oct 2009 12:49:11.0612 (UTC) FILETIME=[8B529FC0:01CA5A28] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group <sipcore.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/sipcore> List-Post: <mailto:sipcore@ietf.org> List-Help: <mailto:sipcore-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 31 Oct 2009 12:50:14 -0000 Hi,=20 >>You would have to send an extra re-INVITE/UPDATE just because you=20 >>couldn't send the I-P list in the ACK. Or? >>=20 >>And, if there are no rules one can of course send a list both in the=20 >>INVITE and the ACK. I don't know if that is likely to happen, but if=20 >>the ACK trigger the remote entity's list to change it would have to=20 >>trigger a request in order to change the list, since there is no=20 >>response to ACK. > >But this is not a negotiation, just a declaration. >So what harm is there in changing between INVITE and ACK? >(As unlikely as that seems.) Maybe it works. But, would it then also be allowed to send one list in a reliable 18x, and then a new list in the next relaible 18x, and then a third list in the 200 OK - all for the same transaction? OR, should we have a rule saying that a UA can send at most one list per transaction? >>So, maybe we should say that the I-P list can only be sent in INV OR=20 >>ACK, or that the I-P list must be identical if sent in both INV AND ACK. > >I don't feel strongly about it. But every additional requirement is something else to test. >>However, as always, issues can arise from 3pcc. A UA may receive a=20 >>reinvite, and think nothing has changed, but in reality what is=20 >>changing is that it has a peer UA that is not aware of its R-I=20 >>settings. >>So I think it should be recommended that R-I always be sent in=20 >>response to a reinvite. >=20 >Of course, that would require that the R-I header has previously been=20 >used during the dialog. Otherwise the UAS won't even know whether the=20 >sender supports I-P. > >Which dialog? Since this is 3pcc, and the interesting case is a transfer, there are *3* dialogs. > >It should never hurt to send an R-I in the context of a response to a reinvite. The draft says that you don't send a list unless you know that the other party - for that dialog - supports the mechanism. >There may indeed be a problem in one case. Here's a picture to refer to: > > A ----- B ----- C > | > --- D > >Initially A is connected, via B to C. Then B initiates a 3pcc transfer by sending a reinvite to A. > >Now suppose that both A and C support I-P, but D does not. How will A ever learn that D does not? It won't receive an R-I header from D, and so will assume its unchanged from what it had from C. And when=20 >it sends INFOs with an I-P, D will think they are legacy. It will never send a 469, so it won't quench the sending. I assume B has contected D before it sends the re-INVITE to A, right? So, if D does NOT support I-P, I guess B would have to include R-I:nil in the re-INVITE to A. A will of course still think that D supports I-P, but that D is not willing to receive any I-Ps. >>>Also, to cover the case where the two ends get out of sync for some reason, I think it should be allowed, and suggested or required, to=20 >>>include R-I in a 469 response. >>=20 >>At the moment my intention is to require it. > >OK, that's good. I didn't even see it allowed in the 469 response in Table 2 updates. It wasn't :) Regards, Christer