From sip-bounces@ietf.org Tue May 01 11:54:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiufp-0006Gq-Ba; Tue, 01 May 2007 11:53:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hiufo-0006Gl-F3 for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 11:53:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiufo-0006Gd-5U for sip@ietf.org; Tue, 01 May 2007 11:53:52 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiufn-0005UH-R7 for sip@ietf.org; Tue, 01 May 2007 11:53:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HiueQ-0003wt-FB; Tue, 01 May 2007 10:52:26 -0500 From: "Brian Rosen" To: "'Drage, Keith \(Keith\)'" , "'IETF SIP List'" Subject: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations Date: Tue, 1 May 2007 11:53:48 -0400 Message-ID: <0e5201c78c08$e9b66420$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5D1A7985295922448D5550C94DE29180010BFC06@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceJxeRiWYVqzczWSD+GBqRQT3G6egCNsOjQ 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Proposed text for this subject: Sending multiple locations (multiple Geolocation headers, or multiple locationValues in a single Geolocation header is confusing to the UAS. It has no way to decide what these mean, and how to use them. There are a few exceptions to this general statement. The UAC may have both a reference and a value, and may wish to send them together. The value is the current location of the UAC when sent, and the reference may be used to obtain a more current (and possibly more accurate) location later. Also, a proxy server may assert location even if the UAC provided location. In this case, the inserted-by value would be different. Finally, applications of location may specify specific behavior for multiple locations and thus blanket prohibition of such is ill advised. Therefore: A UAC or proxy wishing to supply both a reference and a value, representing the location of the UAC from the same source, MUST provide a single Geolocation header, with two locationValues, and an inserted-by value. Otherwise, and in the absence of application specific guidance, multiple Geolocation headers and multiple locationValues with the same inserted-by value SHOULD NOT be used. Brian > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Saturday, April 28, 2007 4:00 PM > To: IETF SIP List > Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations > > (As SIP WG chair) > > During the review of the WGLC comments, we have identified some issues > where we need consensus calls on the list. These are in one call per > message. > > We had a number of comments that it was not clear whether a message > could contain multiple locations, and if they were, what were the > procedures. > > On the call we identified what we believe the way forward in this area, > which is summarised by the following statements: > > - location conveyance should support the delivery of multiple > locations; > > - the document will make no recommendations as to how the > recipient chooses > which location to use. This is regarded as specific to the using > application, > and therefore beyond the scope of the protocol extension; > > - the recipient should attempt to make use of all the locations > given, and > should only respond with a 424 response if it is unable to use any of > those > locations. This includes resolving all and any locations by reference; > > - as a result of the above, any 424 response is a collective > statement about > all the locations given in the request rather than any specific location > in the > request. > > We will assume that this represents WG consensus unless we hear > otherwise from the WG in 7 calendar days from the posting of this > message. > > Obviously if the WG has an alternative view, some proposal of the > alternative way forward and the expected impact on the text would be > entirely appropriate. > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 12:46:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HivUp-0000rL-1A; Tue, 01 May 2007 12:46:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HivUo-0000rG-A4 for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 12:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HivUo-0000r8-0R for sip@ietf.org; Tue, 01 May 2007 12:46:34 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HivUl-0000MA-OD for sip@ietf.org; Tue, 01 May 2007 12:46:33 -0400 Received: from [160.39.244.242] (dyn-wireless-244-242.dyn.columbia.edu [160.39.244.242]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l41GkChW003149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 May 2007 12:46:15 -0400 (EDT) In-Reply-To: <0e5201c78c08$e9b66420$640fa8c0@cis.neustar.com> References: <0e5201c78c08$e9b66420$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <202BB3DD-FAB2-40D1-87DB-1BF22D7BAEE5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations Date: Tue, 1 May 2007 12:47:48 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'IETF SIP List' , "'Drage, Keith \(Keith\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 1, 2007, at 11:53 AM, Brian Rosen wrote: > Proposed text for this subject: > > Sending multiple locations (multiple Geolocation headers, or multiple > locationValues in a single Geolocation header is confusing to the > UAS. It > has no way to decide what these mean, and how to use them. There > are a few > exceptions to this general statement. The UAC may have both a > reference and > a value, and may wish to send them together. The value is the current > location of the UAC when sent, and the reference may be used to > obtain a > more current (and possibly more accurate) location later. Also, a > proxy > server may assert location even if the UAC provided location. In > this case, > the inserted-by value would be different. Finally, applications of > location different from what? Do you mean that they differ from each other? > may specify specific behavior for multiple locations and thus blanket > prohibition of such is ill advised. > > Therefore: > > A UAC or proxy wishing to supply both a reference and a value, > representing > the location of the UAC from the same source, MUST provide a single > Geolocation header, with two locationValues, and an inserted-by value. > That doesn't work, unless I'm misunderstanding what you mean. Geolocation: x Geolocation: y is exactly the same (syntactic transformation) as Geolocation: x, y > Otherwise, and in the absence of application specific guidance, > multiple > Geolocation headers and multiple locationValues with the same > inserted-by > value SHOULD NOT be used. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 13:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwDr-0006gb-Fo; Tue, 01 May 2007 13:33:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiwDq-0006gV-J9 for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 13:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwDq-0006gN-9f for sip@ietf.org; Tue, 01 May 2007 13:33:06 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiwDp-0000i3-3l for sip@ietf.org; Tue, 01 May 2007 13:33:06 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc12) with ESMTP id <200705011733040120034ug8e>; Tue, 1 May 2007 17:33:04 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l41HX3qi010980 for ; Tue, 1 May 2007 13:33:03 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l41HX3lC010976; Tue, 1 May 2007 13:33:03 -0400 Date: Tue, 1 May 2007 13:33:03 -0400 Message-Id: <200705011733.l41HX3lC010976@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <202BB3DD-FAB2-40D1-87DB-1BF22D7BAEE5@cs.columbia.edu> (hgs@cs.columbia.edu) Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations References: <0e5201c78c08$e9b66420$640fa8c0@cis.neustar.com> <202BB3DD-FAB2-40D1-87DB-1BF22D7BAEE5@cs.columbia.edu> X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Henning Schulzrinne > A UAC or proxy wishing to supply both a reference and a value, > representing > the location of the UAC from the same source, MUST provide a single > Geolocation header, with two locationValues, and an inserted-by value. > That doesn't work, unless I'm misunderstanding what you mean. Geolocation: x Geolocation: y is exactly the same (syntactic transformation) as Geolocation: x, y What it must mean is: A UAC or proxy wishing to supply both a reference and a value, representing the location of the UAC from the same source, MUST provide two locationValues, both containing inserted-by geloloc-params with the same value. For example: Geolocation: ;inserted-by=endpoint Geolocation: ;inserted-by=endpoint or Geolocation: ;inserted-by=endpoint, ;inserted-by=endpoint Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 13:36:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwGv-0008Ne-St; Tue, 01 May 2007 13:36:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiwGt-0008NZ-Sw for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 13:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwGt-0008NR-JQ for sip@ietf.org; Tue, 01 May 2007 13:36:15 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiwGt-0000zh-EC for sip@ietf.org; Tue, 01 May 2007 13:36:15 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id 64B1A32982 for ; Tue, 1 May 2007 17:36:15 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 13:36:15 -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: Tue, 1 May 2007 13:36:13 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location Conveyance only of UAC location Thread-Index: AceMFzaKfkN76wVeSLmVS9o68mgTAg== From: "Rosen, Brian" To: "IETF SIP List" X-OriginalArrivalTime: 01 May 2007 17:36:15.0236 (UTC) FILETIME=[37D79440:01C78C17] X-Spam-Score: -2.8 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Sip] Location Conveyance only of UAC location X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org An issue raised by reviewers for location-conveyance was how it works if the UAS tries to send its location to the UAC. There are several things that are problematic with this, including errors: the UAC can't tell the UAS about an error it finds in the location. We propose to resolve this by specifying that location-conveyance sends the location of the UAC. The header can appear in a message from the UAS to the UAC, but it means that the UAS is looping back the location of the UAC. =20 The other end can send its location with an UPDATE or ReINVITE, turning around the connection (i.e. becoming the UAC). The loopback procedure is useful when proxies insert location. The UAC may not even be aware that it happened, and yet it gets an error or a result it doesn't understand. If the UAS echo's what it gets, the UAC can see it. If this proposal finds favor with the working group, we will modify the text in the next revision of -conveyance to incorporate it. =20 Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 14:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwkY-0001EB-KE; Tue, 01 May 2007 14:06:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiwkX-0001E6-V6 for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 14:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwkX-0001Dy-LU for sip@ietf.org; Tue, 01 May 2007 14:06:53 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiwkV-0003z6-Oj for sip@ietf.org; Tue, 01 May 2007 14:06:53 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 01 May 2007 11:06:51 -0700 X-IronPort-AV: i="4.14,475,1170662400"; d="scan'208"; a="57307781:sNHT63824382" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l41I6pwp019704; Tue, 1 May 2007 11:06:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l41I6mwv010644; Tue, 1 May 2007 18:06:50 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.1830); Tue, 1 May 2007 14:06:36 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 14:06:35 -0400 Message-ID: <463781B3.7040509@cisco.com> Date: Tue, 01 May 2007 14:06:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Sip] Location Conveyance only of UAC location References: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2007 18:06:35.0609 (UTC) FILETIME=[74DE7490:01C78C1B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1354; t=1178042811; x=1178906811; c=relaxed/simple; s=sjdkim6002; 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[Sip]=20Location=20Conveyance=20only=20of=20UAC=20loc ation |Sender:=20; bh=xa0VMnSOx61oDOOfV/QH5Afl113Jsr35TCnFUySNh98=; b=CoEFN2ZJ5rStgoeCxrVCmrvjTFI1v/3CIP5VcGwtW6j0ewDkRRNeVZJ4+UGbbtnumIYWO3n1 6BuHHjWR+G1qQVoF47eMLmKxz0HJDEZTAkBoj7RduL1DMrs8dffVOpbF; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Rosen, Brian wrote: > An issue raised by reviewers for location-conveyance was how it works if > the UAS tries to send its location to the UAC. There are several things > that are problematic with this, including errors: the UAC can't tell the > UAS about an error it finds in the location. > > We propose to resolve this by specifying that location-conveyance sends > the location of the UAC. The header can appear in a message from the > UAS to the UAC, but it means that the UAS is looping back the location > of the UAC. > > The other end can send its location with an UPDATE or ReINVITE, turning > around the connection (i.e. becoming the UAC). > > The loopback procedure is useful when proxies insert location. The UAC > may not even be aware that it happened, and yet it gets an error or a > result it doesn't understand. If the UAS echo's what it gets, the UAC > can see it. > > If this proposal finds favor with the working group, we will modify the > text in the next revision of -conveyance to incorporate it. This sounds wise to me. Something that bears further discussion: is an intermediate node permitted to drop the location from a response? I think there are competing interests here - some intermediate nodes may want to drop it, while the UAC would prefer to have it retained. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 14:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwr3-00067E-GW; Tue, 01 May 2007 14:13:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hiwr1-000679-NR for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 14:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwr1-000671-Du for sip@ietf.org; Tue, 01 May 2007 14:13:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiwr0-0004dI-3k for sip@ietf.org; Tue, 01 May 2007 14:13:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hiwpb-00053i-KU; Tue, 01 May 2007 13:12:07 -0500 From: "Brian Rosen" To: , Subject: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations Date: Tue, 1 May 2007 14:13:28 -0400 Message-ID: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200705011733.l41HX3lC010976@dragon.ariadne.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceMFpm/chQShq7SRHWKP5PmTMzwSQABTGBA 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, I wanted to limit options. I wanted two representations of the same location as a single header. I'm not really stuck on that, but cutting down on options is good. Brian > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Tuesday, May 01, 2007 1:33 PM > To: sip@ietf.org > Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations > > From: Henning Schulzrinne > > > A UAC or proxy wishing to supply both a reference and a value, > > representing > > the location of the UAC from the same source, MUST provide a single > > Geolocation header, with two locationValues, and an inserted-by > value. > > > > That doesn't work, unless I'm misunderstanding what you mean. > > Geolocation: x > Geolocation: y > > is exactly the same (syntactic transformation) as > > Geolocation: x, y > > What it must mean is: > > A UAC or proxy wishing to supply both a reference and a value, > representing the location of the UAC from the same source, > MUST provide two locationValues, both containing inserted-by > geloloc-params with the same value. > > For example: > > Geolocation: ;inserted-by=endpoint > Geolocation: ;inserted- > by=endpoint > > or > > Geolocation: ;inserted-by=endpoint, > ;inserted-by=endpoint > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 14:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwws-0004Yp-PF; Tue, 01 May 2007 14:19:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hiwwr-0004Yk-7g for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 14:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwwq-0004Yc-UV for sip@ietf.org; Tue, 01 May 2007 14:19:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiwwp-0005Tg-Hr for sip@ietf.org; Tue, 01 May 2007 14:19:36 -0400 Received: from [64.101.172.179] ([64.101.172.179]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l41HQb7V010090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 May 2007 12:26:38 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF103F37FC@zrc2hxm0.corp.nortel.com> References: <45FE0336.8010506@cisco.com> <1177686902.24685.3.camel@eeek.ingate.se> <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com> <1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com> <1ECE0EB50388174790F9694F77522CCF103F37FC@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Re: draft-ietf-sip-sips-03 Date: Tue, 1 May 2007 13:19:07 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Apr 30, 2007, at 5:38 PM, Francois Audet wrote: > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> What I think we need is something that says "I do not like >> your scheme. Here's a list of alternatives that I prefer." > You can send 3XX with the scheme(s) you support. > > That's what the document currently describes. > The problem I see, and I may just be imagining this, is that there's no way for the receiver of a 302 to know whether it means 1) The party you have called cannot be reached, please try this other party. or 2) The mechanism (scheme) you have chosen to use cannot be used right now. Please try this other mechanism. or 3) You need some additional parameters to reach the party you have selected along with the scheme you have selected. There are heuristics that might apply. For example, if the only difference between the R-URI of a request and the Contact of a 302 response is in the scheme, then we probably have a scheme change. But with all the parameters appearing on R-URI, that's not a really solid heuristic. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 15:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hixxx-00064I-9L; Tue, 01 May 2007 15:24:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hixxw-00064D-Kv for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 15:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hixxw-000645-BO for sip@ietf.org; Tue, 01 May 2007 15:24:48 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hixxv-0003mb-Vp for sip@ietf.org; Tue, 01 May 2007 15:24:48 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.42449173; Tue, 01 May 2007 15:24:28 -0400 Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 15:24:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 May 2007 15:24:27 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-session-policy-framework-01 Thread-Index: AceMJlYUrfUZ9ITcQS6mHfDK0ec1xw== From: "Khan, Sohel" To: , , , X-OriginalArrivalTime: 01 May 2007 19:24:28.0384 (UTC) FILETIME=[560F5600:01C78C26] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Subject: [Sip] draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1333818230==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1333818230== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78C26.557DEF90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78C26.557DEF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have some concern on the draft-ietf-sip-session-policy-framework-01. IMHO, in a wireless network, an expensive resource is the air-interface and an expensive QoS parameter is the end-to-end call set up delay. Current draft-ietf-sip-session-policy-framework-01 increases message flows between user agents (UAs) and network in both ends of a call. In this draft, a UA is directly communicating both with the Proxy and the Policy servers in both end of the network (in Figure 3 and 4). This will consume air-interface bandwidth and increase end to end delay of a call. Note that, in a large country, the distance between a cell phone user and a office supporting a proxy and policy server is in hundreds of miles. The UA's policy offer/exchange with the proxy and policy server would significantly impact the end-to-end call set up delay performance. A better approach would be direct rendezvous of the Proxy and the Policy servers through SIP. Generally, proxy and policy server are co-located. In emerging devices, proxies and policy servers are embedded inside a single hardware. Direct communication between Proxy and Policy server would reduce messages (2)/ack, (3), (4), (6), (7), (9), and (10) to two message exchange in Figure 3. Similar reduction is possible in Figure (4).=20 =20 Thank you. =20 Sincerely, Sohel Khan, Ph.D. Product Engineering Comcast Cable Communications =20 ------_=_NextPart_001_01C78C26.557DEF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have some concern on the = draft-ietf-sip-session-policy-framework-01.

IMHO, in a wireless network, an expensive resource is = the air-interface and an expensive QoS parameter is the end-to-end call set = up delay.  Current draft-ietf-sip-session-policy-framework-01 = increases message flows between user agents (UAs) and network in both ends of a = call. In this draft, a UA is directly communicating both with the Proxy and the = Policy servers in both end of the network (in Figure 3 and 4). This will = consume air-interface bandwidth and increase end to end delay of a call. =  Note that, in a large country, the distance between a cell phone user and a = office supporting a proxy and policy server is in hundreds of miles. The = UA’s policy offer/exchange with the proxy and policy server would significantly = impact the end-to-end call set up delay performance. A better approach would be = direct rendezvous of the Proxy and the Policy servers through SIP. Generally, proxy and = policy server are co-located. In emerging devices, proxies and policy servers = are embedded inside a single hardware. Direct communication between Proxy and Policy = server would reduce messages (2)/ack, (3), (4), (6), (7), (9), and (10) to two = message exchange in Figure 3.  Similar reduction is possible in Figure (4). =

 

Thank you.

 

Sincerely,


Sohel Khan, = Ph.D.

Product Engineering
Comcast Cable Communications

 

------_=_NextPart_001_01C78C26.557DEF90-- --===============1333818230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1333818230==-- From sip-bounces@ietf.org Tue May 01 17:42:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj06W-0003iu-BO; Tue, 01 May 2007 17:41:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj06U-0003ij-G5 for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 17:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj06U-0003ib-60; Tue, 01 May 2007 17:41:46 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj06T-0008Qw-Um; Tue, 01 May 2007 17:41:46 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id C36FF26EED; Tue, 1 May 2007 21:41:45 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Hj06T-0006PG-Ms; Tue, 01 May 2007 17:41:45 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: pavel.dostal@siemens.com, Antti.K.Laurila@nokia.com From: Dean Willis (IETF SIP WG) Message-Id: Date: Tue, 01 May 2007 17:41:45 -0400 X-Spam-Score: -2.3 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: fluffy@cisco.com, jon.peterson@neustar.biz, sip@ietf.org, drage Keith , dean.willis@softarmor.com, Victoria Gray , Ileana Leuca Subject: [Sip] New Liaison Statement, "IETF SIP WG Response to OMA LS 178 on XCAP diff-event" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dean.willis@softarmor.com, sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Title: IETF SIP WG Response to OMA LS 178 on XCAP diff-event Submission Date: 2007-05-01 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=323 From: Dean Willis(IETF SIP WG) To: Open Mobile Alliance, PAG Working Group(pavel.dostal@siemens.com, Antti.K.Laurila@nokia.com) Cc: drage Keith fluffy@cisco.com jon.peterson@neustar.biz sip@ietf.org Ileana Leuca Victoria Gray Reponse Contact: dean.willis@softarmor.com drage Keith Technical Contact: dean.willis@softarmor.com drage Keith Purpose: In response Body: The IETF SIP working group thanks the OMA PAG working group for communicating with us in regards to PAG's requirements for an XCAP event package. A design team met in an ad-hoc session during IETF 68, and reached the conclusion that a more general solution to the problem of change reporting on XCAP documents than that provided by the current SIPPING config framework draft would be desirable. The team achieved consensus on working from the document draft-urpalainen-sip-xcap-diff-event-01 as baseline text. It has not yet been determined by the IETF leadership as to which working group will develop this event package, but current indicators are that this would be within the scope of the SIPPING working group, and that initial editorial work will be provided in large part by Jari Urpalienen. The largest open issue with this work appears to be related to the initial synchronization phase. Questions related to this were raised by Jari on the SIP mailing list on April 25. The SIP working group would like to encourage OMA PAG to participate in this discussion on the SIP mailing list and to consider whether the limitations of the current mechanism as discussed by Jari are acceptable for PAG's requirements. Attachment(s): No document has been attached _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 19:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1fK-0003ak-IG; Tue, 01 May 2007 19:21:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj1fJ-0003V2-IQ for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 19:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1fJ-0003Ts-8d for sip@ietf.org; Tue, 01 May 2007 19:21:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj1fH-0002Q6-TH for sip@ietf.org; Tue, 01 May 2007 19:21:49 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 May 2007 16:21:47 -0700 X-IronPort-AV: i="4.14,475,1170662400"; d="scan'208"; a="57382948:sNHT49054518" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l41NLlmu032117; Tue, 1 May 2007 16:21:47 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l41NLkA8018758; Tue, 1 May 2007 23:21:46 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.1830); Tue, 1 May 2007 19:21:46 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 19:21:45 -0400 Message-ID: <4637CB89.30509@cisco.com> Date: Tue, 01 May 2007 19:21:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations References: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> In-Reply-To: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2007 23:21:45.0893 (UTC) FILETIME=[7C46CD50:01C78C47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2677; t=1178061707; x=1178925707; c=relaxed/simple; s=sjdkim8002; 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[Sip]=20Location-conveyance=3A=20ISSUE=20#3=20-=20mul tiple=20locations |Sender:=20; bh=dPqPoEJeiPU5ydxpv5AQo2AUKAdLRtLJqYaSpluYe5s=; b=dEb+KTBTe40IVqzTKtGUzr9XO/pRmcA5Gy7iC1Qm1/ky5h/ejHZZaGLxeQJ/SGzbVH9iQGZb Rk5eZbLPOWf/p1c+UdcGIOUsT37r4UEVfyIXFHahE6PxI70zz8IYVIvy; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Brian Rosen wrote: > Yeah, I wanted to limit options. I wanted two representations of the same > location as a single header. I'm not really stuck on that, but cutting down > on options is good. The general approach of allowing multiple valued headers to appear by repeating the header or using comma separated values is quite deeply embedded. Making an exception for one header would IMO be far worse than being consistent with all the other multivalued headers. The stacks I know of handle this internally. An exception will require more code, not less. Paul > Brian >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Tuesday, May 01, 2007 1:33 PM >> To: sip@ietf.org >> Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations >> >> From: Henning Schulzrinne >> >> > A UAC or proxy wishing to supply both a reference and a value, >> > representing >> > the location of the UAC from the same source, MUST provide a single >> > Geolocation header, with two locationValues, and an inserted-by >> value. >> > >> >> That doesn't work, unless I'm misunderstanding what you mean. >> >> Geolocation: x >> Geolocation: y >> >> is exactly the same (syntactic transformation) as >> >> Geolocation: x, y >> >> What it must mean is: >> >> A UAC or proxy wishing to supply both a reference and a value, >> representing the location of the UAC from the same source, >> MUST provide two locationValues, both containing inserted-by >> geloloc-params with the same value. >> >> For example: >> >> Geolocation: ;inserted-by=endpoint >> Geolocation: ;inserted- >> by=endpoint >> >> or >> >> Geolocation: ;inserted-by=endpoint, >> ;inserted-by=endpoint >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 19:27:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1kd-0008T0-0g; Tue, 01 May 2007 19:27:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj1kb-0008Ss-Cc for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 19:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1kb-0008Sk-35 for sip@ietf.org; Tue, 01 May 2007 19:27:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj1kY-0004jY-Lv for sip@ietf.org; Tue, 01 May 2007 19:27:16 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 01 May 2007 19:27:11 -0400 X-IronPort-AV: i="4.14,475,1170651600"; d="scan'208"; a="59160725:sNHT46907740" 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 l41NRAWs016845; Tue, 1 May 2007 19:27:10 -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.12.10/8.12.6) with ESMTP id l41NR6lG012669; Tue, 1 May 2007 23:27:10 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.1830); Tue, 1 May 2007 19:27:05 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 19:27:05 -0400 Message-ID: <4637CCC8.2030906@cisco.com> Date: Tue, 01 May 2007 19:27:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Re: draft-ietf-sip-sips-03 References: <45FE0336.8010506@cisco.com> <1177686902.24685.3.camel@eeek.ingate.se> <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com> <1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com> <1ECE0EB50388174790F9694F77522CCF103F37FC@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2007 23:27:05.0384 (UTC) FILETIME=[3AB54280:01C78C48] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1475; t=1178062030; x=1178926030; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Re=3A=20draft-ietf-sip-sips-03 |Sender:=20 |To:=20Dean=20Willis=20; bh=4nkMXZv+qrHe86gcpZBTGU43NTkFR5DbvbGXpZotOYs=; b=rBT+n1UANEOTgyBKNzEL11YRf7caHnUaS22BBveGNUbis8GndBh3hIKyqMPiuxhheoWpodfV 28UGYYDcQUwcPabE59grO/xKf+zoQM0H7IOFYrY8w5UBbbQGCxo8bPJa; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: SIP IETF , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On Apr 30, 2007, at 5:38 PM, Francois Audet wrote: > >> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> What I think we need is something that says "I do not like >>> your scheme. Here's a list of alternatives that I prefer." > >> You can send 3XX with the scheme(s) you support. >> >> That's what the document currently describes. >> > > The problem I see, and I may just be imagining this, is that there's no > way for the receiver of a 302 to know whether it means > > 1) The party you have called cannot be reached, please try this other > party. > > or > > 2) The mechanism (scheme) you have chosen to use cannot be used right > now. Please try this other mechanism. > > or > > 3) You need some additional parameters to reach the party you have > selected along with the scheme you have selected. > > There are heuristics that might apply. For example, if the only > difference between the R-URI of a request and the Contact of a 302 > response is in the scheme, then we probably have a scheme change. I don't see that the distinction matters. You called URL-1 and are told you should try URL-2. You get a hint on the significance depending on whether it is a 301 or 302 response. (If the recipient doesn't support sip, then 301 is the way to go I think.) Don't think too hard about it - just do what you are told in this case. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 19:30:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1nl-0001SX-7L; Tue, 01 May 2007 19:30:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj1nj-0001SS-0M for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 19:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj1ni-0001SK-N9 for sip@ietf.org; Tue, 01 May 2007 19:30:30 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj1nh-0006K5-Ei for sip@ietf.org; Tue, 01 May 2007 19:30:30 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l41NUPL04715; Tue, 1 May 2007 23:30:25 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: draft-ietf-sip-sips-03 Date: Tue, 1 May 2007 18:30:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF104466F0@zrc2hxm0.corp.nortel.com> In-Reply-To: <4637CCC8.2030906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: draft-ietf-sip-sips-03 Thread-Index: AceMSEAlAEdPugT7SlW42g0Z58ru+QAAEegw References: <45FE0336.8010506@cisco.com> <1177686902.24685.3.camel@eeek.ingate.se> <1ECE0EB50388174790F9694F77522CCF1037E9B4@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00AFAEE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF103F2FEB@zrc2hxm0.corp.nortel.com> <1F1D5F31-5AE2-4AFF-9895-7A5654DC9ACE@softarmor.com> <1ECE0EB50388174790F9694F77522CCF103F37FC@zrc2hxm0.corp.nortel.com> <4637CCC8.2030906@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Paul. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, May 01, 2007 16:27 > To: Dean Willis > Cc: Audet, Francois (SC100:3055); SIP IETF > Subject: Re: [Sip] Re: draft-ietf-sip-sips-03 >=20 >=20 >=20 > Dean Willis wrote: > >=20 > > On Apr 30, 2007, at 5:38 PM, Francois Audet wrote: > >=20 > >> > >>> -----Original Message----- > >>> From: Dean Willis [mailto:dean.willis@softarmor.com] > >>> What I think we need is something that says "I do not like your=20 > >>> scheme. Here's a list of alternatives that I prefer." > >=20 > >> You can send 3XX with the scheme(s) you support. > >> > >> That's what the document currently describes. > >> > >=20 > > The problem I see, and I may just be imagining this, is=20 > that there's=20 > > no way for the receiver of a 302 to know whether it means > >=20 > > 1) The party you have called cannot be reached, please try=20 > this other=20 > > party. > >=20 > > or > >=20 > > 2) The mechanism (scheme) you have chosen to use cannot be=20 > used right=20 > > now. Please try this other mechanism. > >=20 > > or > >=20 > > 3) You need some additional parameters to reach the party you have=20 > > selected along with the scheme you have selected. > >=20 > > There are heuristics that might apply. For example, if the only=20 > > difference between the R-URI of a request and the Contact of a 302=20 > > response is in the scheme, then we probably have a scheme change. >=20 > I don't see that the distinction matters. You called URL-1=20 > and are told you should try URL-2. You get a hint on the=20 > significance depending on whether it is a 301 or 302=20 > response. (If the recipient doesn't support sip, then 301 is=20 > the way to go I think.) >=20 > Don't think too hard about it - just do what you are told in=20 > this case. >=20 > Paul >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 20:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3BI-00007j-UE; Tue, 01 May 2007 20:58:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj3BG-0008Sd-TR for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 20:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3BG-0008Rb-JH for sip@ietf.org; Tue, 01 May 2007 20:58:54 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj3BF-0002zi-7a for sip@ietf.org; Tue, 01 May 2007 20:58:54 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hj3BE-0000ff-4d; Tue, 01 May 2007 20:58:52 -0400 Message-ID: <4637E249.7040507@bbn.com> Date: Tue, 01 May 2007 20:58:49 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations References: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> <4637CB89.30509@cisco.com> In-Reply-To: <4637CB89.30509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Also, it seems like an abuse of syntax to use groupings of header values (which traditionally have no meaning) to indicate groupings of location URIs. If you want to do that, do something like add an inserter-tag=rand12345 parameter. In any case, I don't think we need to go into this much detail for a generic conveyance mechanism. If I may suggest text: " Sending multiple locations in a SIP message (i.e., multiple Geolocation headers, or multiple locationValues in a single Geolocation header) can be confusing to the UAS. Based on the information in the SIP message, the UAS may have no way to make a meaningful choice as to which locations to use, and how to use them. This document defines only one mechanism to distinguish among multiple locations, the inserted-by URI parameter, which is used to differentiate proxy-inserted and endpoint-inserted locations when both a proxy and and endpoint assert locations. Future documents may define additional parameters to express other differences. Beyond these parameters, however, this document provides no other mechanisms for distinguishing among multiple locations included in a SIP message. Thus, it is NOT RECOMMENDED that locations be added to a SIP message that have the same values for these parameters as locations already in the SIP message. For example, if a proxy receives a message that contains a location with inserted-by=server, the proxy SHOULD NOT insert additional locations into the message. For endpoints, this recommendation means that a UAC SHOULD NOT include multiple locations in a SIP request. Should a UAC choose to include multiple locations, all locations MUST indicate the same physical location, namely that of the endpoint. " To sum up: This document gives you inserted-by; might be others in the future. Beyond that, there be dragons! I don't think message-routed-on-this-uri is right to include here, since that tag should be applied to all locations to which it applies. --RB Paul Kyzivat wrote: > > > Brian Rosen wrote: >> Yeah, I wanted to limit options. I wanted two representations of the >> same >> location as a single header. I'm not really stuck on that, but >> cutting down >> on options is good. > > The general approach of allowing multiple valued headers to appear by > repeating the header or using comma separated values is quite deeply > embedded. Making an exception for one header would IMO be far worse than > being consistent with all the other multivalued headers. > > The stacks I know of handle this internally. An exception will require > more code, not less. > > Paul > >> Brian >>> -----Original Message----- >>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Sent: Tuesday, May 01, 2007 1:33 PM >>> To: sip@ietf.org >>> Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations >>> >>> From: Henning Schulzrinne >>> >>> > A UAC or proxy wishing to supply both a reference and a value, >>> > representing >>> > the location of the UAC from the same source, MUST provide a single >>> > Geolocation header, with two locationValues, and an inserted-by >>> value. >>> > >>> >>> That doesn't work, unless I'm misunderstanding what you mean. >>> >>> Geolocation: x >>> Geolocation: y >>> >>> is exactly the same (syntactic transformation) as >>> >>> Geolocation: x, y >>> >>> What it must mean is: >>> >>> A UAC or proxy wishing to supply both a reference and a value, >>> representing the location of the UAC from the same source, >>> MUST provide two locationValues, both containing inserted-by >>> geloloc-params with the same value. >>> >>> For example: >>> >>> Geolocation: ;inserted-by=endpoint >>> Geolocation: ;inserted- >>> by=endpoint >>> >>> or >>> >>> Geolocation: ;inserted-by=endpoint, >>> ;inserted-by=endpoint >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 01 21:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3Da-00011z-3h; Tue, 01 May 2007 21:01:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hj3DY-00011o-7B for sip-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 21:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj3DX-00011g-Tx for sip@ietf.org; Tue, 01 May 2007 21:01:15 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj3DW-0003UD-Lp for sip@ietf.org; Tue, 01 May 2007 21:01:15 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hj3DW-0000ys-3a; Tue, 01 May 2007 21:01:14 -0400 Message-ID: <4637E2D7.1090605@bbn.com> Date: Tue, 01 May 2007 21:01:11 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Sip] Location Conveyance only of UAC location References: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think this is the correct, unambiguous semantic for the Geolocation header. I'm less certain about how well the loopback will work in practice, for the reason Paul noted (you might get push-back on loop-back, haha), but as long as it's not a MUST, that's not a big deal. --Richard Rosen, Brian wrote: > An issue raised by reviewers for location-conveyance was how it works if > the UAS tries to send its location to the UAC. There are several things > that are problematic with this, including errors: the UAC can't tell the > UAS about an error it finds in the location. > > We propose to resolve this by specifying that location-conveyance sends > the location of the UAC. The header can appear in a message from the > UAS to the UAC, but it means that the UAS is looping back the location > of the UAC. > > The other end can send its location with an UPDATE or ReINVITE, turning > around the connection (i.e. becoming the UAC). > > The loopback procedure is useful when proxies insert location. The UAC > may not even be aware that it happened, and yet it gets an error or a > result it doesn't understand. If the UAS echo's what it gets, the UAC > can see it. > > If this proposal finds favor with the working group, we will modify the > text in the next revision of -conveyance to incorporate it. > > Brian > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 02 10:43:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjG1l-000758-S0; Wed, 02 May 2007 10:41:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjG1k-000753-1p for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 10:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjG1j-00074r-OS for sip@ietf.org; Wed, 02 May 2007 10:41:55 -0400 Received: from web63211.mail.re1.yahoo.com ([69.147.97.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjG1i-0000Rf-Gb for sip@ietf.org; Wed, 02 May 2007 10:41:55 -0400 Received: (qmail 88664 invoked by uid 60001); 2 May 2007 14:37:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QxQGajmx82GTqhRxlrAiEjczladOVIQxKx3cV4OPlgLiCN3eBOrlhtEpn0akNFuOJcFPNxDhDV+m0gKIdpku/PJNP6yHNglPSkrei1hv+7euVx+80WeFzJWckFyjuMh2LmJIbEm6NXI3Sy0MJNgcuC/KLSZHnZJwOVJGgz5AUtY=; X-YMail-OSG: Deb0F1oVM1lst9zVntIy448P86a7_2UCpvSahxC_d5rox7Bwd.OuHS_yNThuVcsc5EC9K_yF5YNwjWGVzFTMauvcXUZbm2ZShSY- Received: from [216.191.234.70] by web63211.mail.re1.yahoo.com via HTTP; Wed, 02 May 2007 07:37:47 PDT Date: Wed, 2 May 2007 07:37:47 -0700 (PDT) From: Jerry Yin To: IETF SIP List In-Reply-To: <1ECE0EB50388174790F9694F77522CCF103F32FB@zrc2hxm0.corp.nortel.com> MIME-Version: 1.0 Message-ID: <304721.87247.qm@web63211.mail.re1.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Which sip.instance to use (GRUU and Outbound)? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1954099800==" Errors-To: sip-bounces@ietf.org --===============1954099800== Content-Type: multipart/alternative; boundary="0-3374980-1178116667=:87247" Content-Transfer-Encoding: 8bit --0-3374980-1178116667=:87247 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi There, I have a question regarding to the GRUU and the outbound-08 drafts. In the GRUU draft, it recommends the UA use the sip.instance obtained from the Registrar. But in the outbound-08 draft, it recommended to create a sip.instance (UUID) when doing registration. If the UA supports both GRUU and the outbound, which sip.instance should the UA to use in the INVITE transactions? Thanks, Jerry --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-3374980-1178116667=:87247 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi There,
 
I have a question regarding to the GRUU and the outbound-08 drafts. In the GRUU draft, it recommends the UA use the sip.instance obtained from the Registrar. But in the outbound-08 draft, it recommended to create a sip.instance (UUID) when doing registration. If the UA supports both GRUU and the outbound, which sip.instance should the UA to use in the INVITE transactions?
 
Thanks,
Jerry

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-3374980-1178116667=:87247-- --===============1954099800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1954099800==-- From sip-bounces@ietf.org Wed May 02 11:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGrq-0008QC-Sj; Wed, 02 May 2007 11:35:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjGro-00089F-Pn for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 11:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGro-00086N-Dc for sip@ietf.org; Wed, 02 May 2007 11:35:44 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjGrn-0000xQ-57 for sip@ietf.org; Wed, 02 May 2007 11:35:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Sip] Which sip.instance to use (GRUU and Outbound)? Date: Wed, 2 May 2007 09:35:39 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Sip] Which sip.instance to use (GRUU and Outbound)? Thread-Index: AceMz4kgqzIk//s3RlGwDvA8VVjiow== From: "Peter Musgrave" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0926599736==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0926599736== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78CCF.5B6CC15D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78CCF.5B6CC15D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerry,=20 =20 I believe there should only be one sip-instance in this case.=20 =20 The sip-instance as created by the UA will be unique to that UA instance (and preserved over software/hardware resets etc.). This is used for outbound and if a Supported: gruu is present in the REGISTER it is also used for generating a gruu. =20 Peter=20 ------_=_NextPart_001_01C78CCF.5B6CC15D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jerry,

 

I believe there should only be one sip-instance in = this case.

 

The sip-instance as created by the UA will be unique = to that UA instance (and preserved over software/hardware resets etc.). This is = used for outbound and if a Supported: gruu is present in the REGISTER it is = also used for generating a gruu.

 

Peter

------_=_NextPart_001_01C78CCF.5B6CC15D-- --===============0926599736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0926599736==-- From sip-bounces@ietf.org Wed May 02 11:38:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGtc-0000cc-Dh; Wed, 02 May 2007 11:37:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjGta-0000Yz-IU for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 11:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjGta-0000Yr-91 for sip@ietf.org; Wed, 02 May 2007 11:37:34 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjGta-0001FV-0E for sip@ietf.org; Wed, 02 May 2007 11:37:34 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id l42FbJD0023972; Wed, 2 May 2007 10:37:19 -0500 (CDT) Received: from [135.180.240.247] (volker-hopc2.dnrc.bell-labs.com [135.180.240.247]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l42FbJn07256; Wed, 2 May 2007 11:37:19 -0400 (EDT) Message-ID: <4638B030.2000508@bell-labs.com> Date: Wed, 02 May 2007 11:37:20 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Khan, Sohel" Subject: Re: [Sip] draft-ietf-sip-session-policy-framework-01 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-Scanned-By: MIMEDefang 2.57 on 192.11.226.42 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id l42FbJD0023972 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What you are proposing is essentially the "piggyback model". There has=20 been an extensive discussion of the pros and cons of piggyback vs.=20 separate channel in SIPPING. A brief summary of this discussion can be=20 found in Section 4.2 of draft-ietf-sip-session-policy-framework-01. Thanks, Volker Khan, Sohel wrote: > I have some concern on the draft-ietf-sip-session-policy-framework-01. >=20 > IMHO, in a wireless network, an expensive resource is the air-interface= =20 > and an expensive QoS parameter is the end-to-end call set up delay. =20 > Current draft-ietf-sip-session-policy-framework-01 increases message=20 > flows between user agents (UAs) and network in both ends of a call. In=20 > this draft, a UA is directly communicating both with the Proxy and the=20 > Policy servers in both end of the network (in Figure 3 and 4). This wil= l=20 > consume air-interface bandwidth and increase end to end delay of a call= .=20 > Note that, in a large country, the distance between a cell phone user=20 > and a office supporting a proxy and policy server is in hundreds of=20 > miles. The UA=92s policy offer/exchange with the proxy and policy serve= r=20 > would significantly impact the end-to-end call set up delay performance= .=20 > A better approach would be direct rendezvous of the Proxy and the Polic= y=20 > servers through SIP. Generally, proxy and policy server are co-located.= =20 > In emerging devices, proxies and policy servers are embedded inside a=20 > single hardware. Direct communication between Proxy and Policy server=20 > would reduce messages (2)/ack, (3), (4), (6), (7), (9), and (10) to two= =20 > message exchange in Figure 3. Similar reduction is possible in Figure = (4). >=20 > =20 >=20 > Thank you. >=20 > =20 >=20 > Sincerely, >=20 >=20 > Sohel Khan, Ph.D. >=20 > Product Engineering > Comcast Cable Communications >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 02 13:40:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjImw-0007ST-U4; Wed, 02 May 2007 13:38:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjImv-0007SO-Uy for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 13:38:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjImv-0007SG-LY for sip@ietf.org; Wed, 02 May 2007 13:38:49 -0400 Received: from web63211.mail.re1.yahoo.com ([69.147.97.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjImu-0001oc-BQ for sip@ietf.org; Wed, 02 May 2007 13:38:49 -0400 Received: (qmail 54591 invoked by uid 60001); 2 May 2007 17:38:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3RYz+odIwm0j/yFYcYAXh5rAsrrLUCU2lEpnBGQ8LrMGmdUfQihvuuYtXTj4NXQhl07jdb9Ea8itFmt4KbCLXEig+Fi4shgd7hGj/B9y3qkjXxKk2fWuLRAUU7GGZyf2G3sQNdCFhgCWRb/7oXH3BUFeaxjvZq/tJxl5Yl0WV70=; X-YMail-OSG: jtc7yJQVM1ly7tDt_M1fQXi9qdIn3i6t9UafXvq1kPMuNnSiG5vO8KfCRFurSGjscMQOt642wnBrmNwIJuBymvEM7B5Ztivfapi3.lqbXUTJ.3TFtTKOfT7Q8ryuySQ- Received: from [216.191.234.70] by web63211.mail.re1.yahoo.com via HTTP; Wed, 02 May 2007 10:38:48 PDT Date: Wed, 2 May 2007 10:38:48 -0700 (PDT) From: Jerry Yin Subject: Re: [Sip] Which sip.instance to use (GRUU and Outbound)? To: Peter Musgrave In-Reply-To: MIME-Version: 1.0 Message-ID: <225472.6140.qm@web63211.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0592488545==" Errors-To: sip-bounces@ietf.org --===============0592488545== Content-Type: multipart/alternative; boundary="0-1735416747-1178127528=:6140" Content-Transfer-Encoding: 8bit --0-1735416747-1178127528=:6140 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thanks Peter and Robert. My fault. I overlooked the sip.instance created by the UA in the GRUU draft. Jerry Peter Musgrave wrote: Hi Jerry, I believe there should only be one sip-instance in this case. The sip-instance as created by the UA will be unique to that UA instance (and preserved over software/hardware resets etc.). This is used for outbound and if a Supported: gruu is present in the REGISTER it is also used for generating a gruu. Peter --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-1735416747-1178127528=:6140 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Thanks Peter and Robert.
 
My fault. I overlooked the sip.instance created by the UA in the GRUU draft.
 
Jerry

Peter Musgrave <PMusgrave@newheights.com> wrote:
Hi Jerry,
 
I believe there should only be one sip-instance in this case.
 
The sip-instance as created by the UA will be unique to that UA instance (and preserved over software/hardware resets etc.). This is used for outbound and if a Supported: gruu is present in the REGISTER it is also used for generating a gruu.
 
Peter

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-1735416747-1178127528=:6140-- --===============0592488545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0592488545==-- From sip-bounces@ietf.org Wed May 02 13:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjJ39-0006kZ-W1; Wed, 02 May 2007 13:55:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjJ38-0006kU-M8 for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 13:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjJ38-0006kM-CY for sip@ietf.org; Wed, 02 May 2007 13:55:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjJ37-0003Nr-0b for sip@ietf.org; Wed, 02 May 2007 13:55:34 -0400 Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l42H2beG015158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 May 2007 12:02:37 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 2 May 2007 12:55:05 -0500 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Sip] Fwd: ID Tracker State Update Notice: draft-ietf-sip-mib X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Begin forwarded message: > From: The IESG > Date: May 2, 2007 9:34:01 AM CDT > To: sip-chairs@tools.ietf.org, klingle@cisco.com, fluffy@cisco.com, > dromasca@avaya.com, jf.mule@cablelabs.com > Subject: ID Tracker State Update Notice: draft-ietf-sip-mib > Reply-To: ietf-secretariat-reply@ietf.org > > 'State Changes to RFC Published from RFC Ed Queue by Amy Vezza' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=5191&rfc_flag=0 > I'd like to say "Congratulations" to the whole working group, and especially to Kevin and Jean-Francois. It took nine years, but we finally got this thing done. Hooray! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 02 22:35:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjR8v-0006at-On; Wed, 02 May 2007 22:34:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjR8t-0006Zx-Sy for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 22:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjR8t-0006ZX-E9 for sip@ietf.org; Wed, 02 May 2007 22:34:03 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjR8s-0007b8-6O for sip@ietf.org; Wed, 02 May 2007 22:34:03 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070503023401b1200f7mc8e>; Thu, 3 May 2007 02:34:01 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l432Y0qi025904 for ; Wed, 2 May 2007 22:34:00 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l432Y0WL025900; Wed, 2 May 2007 22:34:00 -0400 Date: Wed, 2 May 2007 22:34:00 -0400 Message-Id: <200705030234.l432Y0WL025900@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> (Brian.Rosen@neustar.biz) Subject: Re: [Sip] Location Conveyance only of UAC location References: <886DD03D15173C43BCE98EA662A0101A0221A8D9@stntexch12.cis.neustar.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Rosen, Brian" An issue raised by reviewers for location-conveyance was how it works if the UAS tries to send its location to the UAC. There are several things that are problematic with this, including errors: the UAC can't tell the UAS about an error it finds in the location. Ouch. That could be quite a problem. We propose to resolve this by specifying that location-conveyance sends the location of the UAC. The header can appear in a message from the UAS to the UAC, but it means that the UAS is looping back the location of the UAC. The other end can send its location with an UPDATE or ReINVITE, turning around the connection (i.e. becoming the UAC). This does seem to be the correct solution. I suppose you could even extend this mechanism to include sending an OPTIONS with a location-conveyance header. The loopback procedure is useful when proxies insert location. The UAC may not even be aware that it happened, and yet it gets an error or a result it doesn't understand. If the UAS echo's what it gets, the UAC can see it. Good point. From: Paul Kyzivat Something that bears further discussion: is an intermediate node permitted to drop the location from a response? I think there are competing interests here - some intermediate nodes may want to drop it, while the UAC would prefer to have it retained. It seems best to require the intermediate node to retain the location-conveyance. At least, unless there is no error or warning referring to it. But assuming that locations aren't added to messages frivolously, why would intermediate nodes want to drop it? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 02 22:37:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjRBp-0008Iw-Vo; Wed, 02 May 2007 22:37:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjRBp-0008Ir-5E for sip-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 22:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjRBo-0008Ij-Rt for sip@ietf.org; Wed, 02 May 2007 22:37:04 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjRBn-0008Q0-M5 for sip@ietf.org; Wed, 02 May 2007 22:37:04 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007050302370301100fh87pe>; Thu, 3 May 2007 02:37:03 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l432b2qi026121 for ; Wed, 2 May 2007 22:37:03 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l432b2G2026117; Wed, 2 May 2007 22:37:02 -0400 Date: Wed, 2 May 2007 22:37:02 -0400 Message-Id: <200705030237.l432b2G2026117@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> (br@brianrosen.net) Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations References: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Brian Rosen" Yeah, I wanted to limit options. I wanted two representations of the same location as a single header. I'm not really stuck on that, but cutting down on options is good. Permit me to exercise one of my peeves -- though it appears that limiting the syntax of the header is beneficial, it is in fact harmful. You want as much uniformity in header syntax as possible, so that implementations can use generic parsers to do the low-level conversion of the character stream to a data structure of names/values/whatever. You also want to allow generic "un-parsing" to convert the data structure to the character stream. But if you make ideosyncratic declarations that a particular header does things *slightly differently* than all similar headers, implementations are reduced to using custom code to generate every header. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 03 06:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjYt1-0001mX-V0; Thu, 03 May 2007 06:50:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjYt1-0001mM-3s for sip-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 06:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjYt0-0001mC-Qd for sip@ietf.org; Thu, 03 May 2007 06:50:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjYsy-0004vI-4F for sip@ietf.org; Thu, 03 May 2007 06:50:10 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 669B420959; Thu, 3 May 2007 12:50:07 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-dd-4639be5f4e67 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 59A5F20985; Thu, 3 May 2007 12:50:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 12:50:07 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 3 May 2007 12:50:06 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> In-Reply-To: <200704301612.l3UGCwsM029162@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUA References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com><9D498630-D070-4E7B-8C94-0EF349C7D29B@cisco.com> <200704301612.l3UGCwsM029162@dragon.ariadne.com> From: "Christer Holmberg \(JO/LMF\)" To: , X-OriginalArrivalTime: 03 May 2007 10:50:07.0261 (UTC) FILETIME=[D0392CD0:01C78D70] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Multipart/alternative is interesting. I guess that, for SDP, it could be used to provide different "offer alternatives". I think it would be good to compare it against some of the other grouping/alternative mechanisms we have defined for that purpose. Regards, Christer =20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: 30. huhtikuuta 2007 19:13 > To: sip@ietf.org > Subject: Re: [Sip] Support for Multipart/MIME >=20 > From: Cullen Jennings >=20 > I think the WG should consider an update to 3261 (likely=20 > done through =20 > the process Keith has proposed) that makes this multipart/MIME =20 > mandatory to implement. >=20 > I assume that the requirement is that if a message has a=20 > multipart/alternative body, and the UA is capable of=20 > understanding one part of the body, then it must be able to=20 > extract that part and use it to process the message. >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 03 10:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjchT-0008DL-6N; Thu, 03 May 2007 10:54:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HhSAP-0000mT-Gw for sip-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:15:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSAP-0000mL-6x for sip@ietf.org; Fri, 27 Apr 2007 11:15:25 -0400 Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSAL-0000xU-1T for sip@ietf.org; Fri, 27 Apr 2007 11:15:25 -0400 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11.20060308/8.12.11) with ESMTP id l3RFFGFK003031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Apr 2007 17:15:16 +0200 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.13.1/8.12.11) with ESMTP id l3RFFBJW024849; Fri, 27 Apr 2007 17:15:11 +0200 Received: (from hasse@localhost) by eeek.ingate.se (8.13.1/8.13.1/Submit) id l3RFF2Id024846; Fri, 27 Apr 2007 17:15:02 +0200 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Sip] Re: draft-ietf-sip-sips-03 From: Hans Persson To: SIP IETF In-Reply-To: <45FE0336.8010506@cisco.com> References: <45FE0336.8010506@cisco.com> Content-Type: multipart/mixed; boundary="=-zlU1uPgeEDEIBNwNTalv" Organization: Ingate Systems Date: Fri, 27 Apr 2007 17:15:02 +0200 Message-Id: <1177686902.24685.3.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27.rhel4.6) X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (usagi.ingate.se [193.180.23.12]); Fri, 27 Apr 2007 17:15:17 +0200 (CEST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f671485bda3f2f1be548f998883cfbd X-Mailman-Approved-At: Thu, 03 May 2007 10:54:29 -0400 Cc: Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --=-zlU1uPgeEDEIBNwNTalv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable s=F6n 2007-03-18 klockan 23:27 -0400 skrev Paul Kyzivat: > Just read the most recent version. Its looking good to me. Just a few=20 > typo comments. And so did I, just now. I have a few comments and questions and a slew of nits. > SIPS URIs however can be used in many other header fields: in Contact > for registration, Contact in dialog-creating requests, Route, Record- > Route, Path, From, To, Refer-To, Refer-By, etc. This specification Referred-By, I assume. > This specification mandates that a resource described by a SIPS > Request-URI can not be "downgraded" to a SIP URI when a proxy is > forwarding a request by changing the scheme, or by sending the > associated request over a non secure link. See Section 4.2. I had trouble parsing this. Suggestion for modification: >>> This specification mandates that when a proxy is >>> forwarding a request a resource described by a SIPS >>> Request-URI can not be "downgraded" to a SIP URI by changing the=20 >>> scheme, or by sending the associated request over a non-secure >>> link. See section 4.2. > Consider this example: If Bob registers with a SIPS Contact header > field (e.g., sips:bob@bobphone.example.com), the registrar and the > location service then know that Bob (bob@example.com) is reachable > at sips:bob@bobphone.example.com,=20 Move "(bob@example.com)" to after "If Bob". > Furthermore, if Bob wants to ensure that every > request delivered to it be always transported over TLS, Bob can use > [I-D.ietf-sip-outbound] when registering. Use "to him" instead of "to it". > However, if Bob had registered instead with a SIP contact header > field instead of a SIPS contact header field (e.g., > sip:bob@bobphone.example.com), then a request to AOR I suggest this instead: >>> However, if Bob had registered with a SIP Contact header >>> field instead of a SIPS Contact header field (e.g., >>> sip:bob@bobphone.example.com), then a request to the AOR > 3.3. Usage of tls transport parameter and TLS Via parameter Suggestion: >>> 3.3. Usage of the transport=3Dtls URI parameter and the TLS Via=20 >>> parameter > If the Request-URI is a SIP URI, a sips option-tag in a > Require header field MUST NOT be used, and a Supported header field > MUST be used instead. If a UAS receives a request with the sips > option-tag in a Supported or Require header field and it accepts the > registration, it MUST include the sips option-tag in Supported or > Require header in a 200 (OK) response.=20 Since this is talking about registration, I assume that "request" should be "REGISTER request". > When a target refresh occurs within a dialog (e.g., re-INVITE, > UPDATE), unless there is a need to change it, the UAC and UAS MUST > include a contact header field with a SIPS URI if the original > request used a SIPS Request-URI. What exactly does "a need" mean here? > 4.1.5. Usage of tls transport parameter Suggestion: >>> 4.1.5. Usage of the transport=3Dtls parameter > Specifically, when a proxy receives a request with a SIPS Request- > URI, the proxy MUST forward or retarget the request to a SIPS > Request-URI. If the target UAS had registered previously using a SIP > Contact header field instead of a SIPS Contact header field, the > proxy MUST NOT forward the request to the URI indicated in the SIPS > Contact header field. If the proxy needs to reject the request for > that reason, it MUST reject it with a 404 (Not Found). Shouldn't this read "the SIP Contact header field"? > Proxies can use the sips option-tag in Supported, Require and Proxy- > Require header fields to detect UAs that do not conform to this > specification.=20 How would a proxy use the Proxy-Require header to detect what a UA supports? > The proxy MAY instead map the request with a 416 > (Unsupported URI Scheme)=20 Where did the word "map" come from? I suggest "respond to". > Using a Redirect Server instead of a Proxy, with TLS has some > limitations that has to be taken into account.=20 Suggestion: >>> Using a Redirect Server with TLS instead of a Proxy has some >>> limitations that have to be taken into account. > When a redirect server receives a request with a SIPS Request-URI, > the redirect server MAY redirect with a 3XX response to either a SIP > or a SIPS Contact header field. If the target UAS had registered > previously using a SIPS Contact header field, the redirect server > SHOULD return a SIPS Contact header field to "upgrade" to SIPS if it > is in an environment where TLS is usable (as described in the > previous paragraph). =20 There is no "upgrade" here. Both the request and the registration are SIPS already. In the call flow chart in section 5.1, the image for the second 200 OK for each REGISTER points the wrong way. In general, I feel that I don't understand the reasoning behind when to respond 403 and when to respond 404 in this draft. The rest of my nits is minor stuff like typos, incorrect pluralization, capitalization errors, etc. I attach a diff below. Note that the diff also contains a few of my notes (and the above changes), so don't apply it indiscriminately. Hans --=20 Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210857 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ --=-zlU1uPgeEDEIBNwNTalv Content-Disposition: attachment; filename=sips-diff.txt Content-Type: text/plain; name=sips-diff.txt; charset=ISO-8859-1 Content-Transfer-Encoding: base64 LS0tIGRyYWZ0LWlldGYtc2lwLXNpcHMtMDMudHh0CTIwMDctMDQtMTYgMjA6MTk6NDIuMDAwMDAw MDAwICswMjAwDQorKysgZHJhZnQtaWV0Zi1zaXAtc2lwcy0wMy1ocC50eHQJMjAwNy0wNC0yNyAx NjozMzowNi41NDA2NTQyNzYgKzAyMDANCkBAIC0xNCw3ICsxNCw3IEBADQogICAgQnkgc3VibWl0 dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55 DQogICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBv ciBzaGUgaXMgYXdhcmUNCiAgICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBh bnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCi0gICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3Nl ZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQorICAgYXdhcmUgd2ls bCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBzZWN0aW9uIDYgb2YgQkNQIDc5Lg0K IA0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVy bmV0IEVuZ2luZWVyaW5nDQogICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0 cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KQEAgLTQxLDcgKzQxLDcgQEANCiBBYnN0cmFj dA0KIA0KICAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgY2xhcmlmaWNhdGlvbnMgYW5kIGd1aWRl bGluZXMgY29uY2VybmluZyB0aGUNCi0gICB1c2Ugb2YgU0lQUyBVUkkgc2NoZW1lIGluIHRoZSBT ZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkuICBJdA0KKyAgIHVzZSBvZiB0aGUgU0lQ UyBVUkkgc2NoZW1lIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkuICBJ dA0KICAgIGFsc28gbWFrZXMgbm9ybWF0aXZlIGNoYW5nZXMgdG8gU0lQLiAgVGhpcyBkb2N1bWVu dCBhbHNvIHByb3ZpZGVzIGENCiAgICBkaXNjdXNzaW9uIG9mIHBvc3NpYmxlIGZ1dHVyZSBzdGVw cyBpbiBzcGVjaWZpY2F0aW9uLg0KIA0KQEAgLTExNSw3ICsxMTUsNyBAQA0KIDEuICBJbnRyb2R1 Y3Rpb24NCiANCiAgICBUaGUgbWVhbmluZyBhbmQgdXNhZ2Ugb2YgdGhlIFNJUFMgVVJJIHNjaGVt ZSBhbmQgb2YgVExTIFtSRkM0MzQ2XSBpcw0KLSAgIHVuZGVyc3BlY2lmaWVkIGluIFNJUCBbUkZD MzI2MV0gYW5kIGhhcyBiZWVuIHRoZSBzb3VyY2Ugb2YgY29uZnVzaW9uDQorICAgdW5kZXJzcGVj aWZpZWQgaW4gU0lQIFtSRkMzMjYxXSBhbmQgaGFzIGJlZW4gYSBzb3VyY2Ugb2YgY29uZnVzaW9u DQogICAgZm9yIGltcGxlbWVudGVycy4NCiANCiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGNs YXJpZmljYXRpb25zIGFuZCBndWlkZWxpbmVzIGNvbmNlcm5pbmcgdGhlDQpAQCAtMjI1LDcgKzIy NSw3IEBADQogDQogDQogICAgc2F0aXNmYWN0b3J5IHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbS4g IFtJLUQuaWV0Zi1zaXAtb3V0Ym91bmRdIGFsc28NCi0gICBzb2x2ZSB0aGUgcHJvYmxlbSB0aGF0 IGlmIFVBIGIgaXMgYmVoaW5kIGEgTkFUIG9yIEZpcmV3YWxsLCBwcm94eSBCDQorICAgc29sdmVz IHRoZSBwcm9ibGVtIHRoYXQgaWYgVUEgYiBpcyBiZWhpbmQgYSBOQVQgb3IgRmlyZXdhbGwsIHBy b3h5IEINCiAgICB3b3VsZCBub3QgZXZlbiBiZSBhYmxlIHRvIGVzdGFibGlzaCBhIFRDUCBzZXNz aW9uIGluIHRoZSBmaXJzdCBwbGFjZS4NCiANCiAgICBGdXJ0aGVybW9yZSwgY29uc2lkZXIgdGhl IHByb2JsZW0gb2YgdXNpbmcgU0lQUyBpbnNpZGUgYSBkaWFsb2cuICBJZg0KQEAgLTI0Myw3ICsy NDMsNyBAQA0KIA0KICAgIEJlY2F1c2Ugb2YgYWxsIHRoZSBwcm9ibGVtcyBjYXVzZWQgYnkgdGhl IGxhc3QgaG9wIGV4Y2VwdGlvbiwgdGhpcw0KICAgIHNwZWNpZmljYXRpb24gZGVwcmVjYXRlcyB0 aGUgbGFzdCBob3AgZXhjZXB0aW9uIHdoZW4gZm9yd2FyZGluZyBhDQotICAgcmVxdWVzdCB0byB0 aGUgbGFzdCBob3AgKHNlZSBTZWN0aW9uIDQuMikuICBUaGlzIHdpbGwgZW5zdXJlIHRoYXQgVExT DQorICAgcmVxdWVzdCB0byB0aGUgbGFzdCBob3AgKHNlZSBzZWN0aW9uIDQuMikuICBUaGlzIHdp bGwgZW5zdXJlIHRoYXQgVExTDQogICAgaXMgdXNlZCBvbiBhbGwgaG9wcyBhbGwgdGhlIHdheSB1 cCB0byB0aGUgcmVtb3RlIHRhcmdldC4NCiANCiAgICBUaGUgU0lQUyBzY2hlbWUgaW1wbGllcyB0 cmFuc2l0aXZlIHRydXN0LiAgT2J2aW91c2x5LCB0aGVyZSBpcw0KQEAgLTI2NSw3ICsyNjUsNyBA QA0KICAgIFtSRkM0NDc0XSBwcm92aWRlcyBhbiBhdXRoZW50aWNhdGVkIGlkZW50aXR5IG1lY2hh bmlzbSBhbmQgYSBkb21haW4tDQogICAgdG8tZG9tYWluIGludGVncml0eSBwcm90ZWN0aW9uIG1l Y2hhbmlzbS4NCiANCi0gICBTb21lIGhhdmUgYXNrZWQgd2h5IGlzIFNJUFMgdXNlZnVsIGluIGEg Z2xvYmFsIG9wZW4gZW52aXJvbm1lbnQgc3VjaA0KKyAgIFNvbWUgaGF2ZSBhc2tlZCB3aHkgU0lQ UyBpcyB1c2VmdWwgaW4gYSBnbG9iYWwgb3BlbiBlbnZpcm9ubWVudCBzdWNoDQogICAgYXMgdGhl IEludGVybmV0LCBpZiAod2hlbiB1c2VkIGluIGEgUmVxdWVzdC1VUkkpIGl0IGlzIG5vdCBhbg0K ICAgIGFic29sdXRlIGd1YXJhbnRlZSB0aGF0IHRoZSByZXF1ZXN0IHdpbGwgaW4gZmFjdCBiZSBk ZWxpdmVyZWQgb3Zlcg0KICAgIFRMUyBvbiBlYWNoIGhvcD8gIFdoeSBpcyBTSVBTIGFueSBkaWZm ZXJlbnQgdGhhbiBqdXN0IHVzaW5nIFRMUw0KQEAgLTI5MCw3ICsyOTAsNyBAQA0KICAgIHdvdWxk IG9ubHkgYmUgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgdG8gdXNpbmcgU0lQUyBpbiBhIFJlcXVl c3QtVVJJLg0KICAgIFNJUFMgVVJJcyBob3dldmVyIGNhbiBiZSB1c2VkIGluIG1hbnkgb3RoZXIg aGVhZGVyIGZpZWxkczogaW4gQ29udGFjdA0KICAgIGZvciByZWdpc3RyYXRpb24sIENvbnRhY3Qg aW4gZGlhbG9nLWNyZWF0aW5nIHJlcXVlc3RzLCBSb3V0ZSwgUmVjb3JkLQ0KLSAgIFJvdXRlLCBQ YXRoLCBGcm9tLCBUbywgUmVmZXItVG8sIFJlZmVyLUJ5LCBldGMuICBUaGlzIHNwZWNpZmljYXRp b24NCisgICBSb3V0ZSwgUGF0aCwgRnJvbSwgVG8sIFJlZmVyLVRvLCBSZWZlcnJlZC1CeSwgZXRj LiAgVGhpcyBzcGVjaWZpY2F0aW9uDQogICAgY2xhcmlmaWVzIHRoZSBzaWduaWZpY2FuY2Ugb2Yg dXNpbmcgU0lQUyBVUklzIGluIHRoZXNlIGNhc2VzLiAgU0lQUw0KICAgIFVSSXMgY2FuIGFsc28g YmUgdXNlZCBpbiBodW1hbi11c2FibGUgZm9ybWF0IChlLmcuLCBidXNpbmVzcyBjYXJkcywNCiAg ICB1c2VyIGludGVyZmFjZSwgZXRjLikuICBTSVBTIFVSSXMgY2FuIGV2ZW4gYmUgdXNlZCBpbiBv dGhlciBwcm90b2NvbHMNCkBAIC0zMzYsMTAgKzMzNiwxMCBAQA0KIEludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgICBTSVBTICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNw0K IA0KIA0KLSAgIFVSSXMuICBUaGUgcHJveGllcyBtYXkgaW5zZXJ0IFJlY29yZC1Sb3V0ZSB1c2lu ZyBTSVAgVVJJcyBldmVuIGlmIGl0DQorICAgVVJJcy4gIFRoZSBwcm94aWVzIG1heSBpbnNlcnQg UmVjb3JkLVJvdXRlIGhlYWRlcnMgdXNpbmcgU0lQIFVSSXMgZXZlbiBpZiBpdA0KICAgIHVzZXMg VExTIHRyYW5zcG9ydC4NCiANCi0gICBTb21lIHVzZXIgYWdlbnRzLCByZWRpcmVjdCBzZXJ2ZXIg YW5kIHByb3hpZXMgbWF5IGhhdmUgbG9jYWwgcG9saWNpZXMNCisgICBTb21lIHVzZXIgYWdlbnRz LCByZWRpcmVjdCBzZXJ2ZXJzIGFuZCBwcm94aWVzIG1heSBoYXZlIGxvY2FsIHBvbGljaWVzDQog ICAgdGhhdCBlbmZvcmNlIFRMUyBvbiBhbGwgY29ubmVjdGlvbnMsIGluZGVwZW5kZW50bHkgb2Yg aWYgU0lQUyBpcyB1c2VkDQogICAgb3Igbm90Lg0KIA0KQEAgLTM1NCwzMiArMzU0LDMyIEBADQog ICAgdGhlIFNJUFMgVVJJIHdpbGwgbmVjZXNzYXJpbHkgYmUgcmVhY2hhYmxlLCBpbiBwYXJ0aWN1 bGFyLCBpZiB0aGUNCiAgICBwcm94eSBjYW4gbm90IGVzdGFibGlzaCBhIHNlY3VyZSBjb25uZWN0 aW9uIHRvIGEgY2xpZW50IG9yIGFub3RoZXINCiAgICBwcm94eS4gIFRoaXMgZG9lcyBub3Qgc3Vn Z2VzdCBlaXRoZXIgdGhhdCBwcm94aWVzIHNob3VsZCBhcmJpdHJhcmlseQ0KLSAgICJ1cGdyYWRl IiBTSVAgVVJJcyB0byBTSVBTIFVSSXMgd2hlbiBmb3J3YXJkaW5nIGEgcmVxdWVzdCAoU2VlDQot ICAgU2VjdGlvbiA0LjIpLiAgUmF0aGVyLCBpdCBtZWFucyB0aGF0IHdoZW4gYSByZXNvdXJjZSBp cyBhZGRyZXNzYWJsZQ0KKyAgICJ1cGdyYWRlIiBTSVAgVVJJcyB0byBTSVBTIFVSSXMgd2hlbiBm b3J3YXJkaW5nIGEgcmVxdWVzdCAoc2VlDQorICAgc2VjdGlvbiA0LjIpLiAgUmF0aGVyLCBpdCBt ZWFucyB0aGF0IHdoZW4gYSByZXNvdXJjZSBpcyBhZGRyZXNzYWJsZQ0KICAgIHdpdGggU0lQLCBp dCB3aWxsIGFsc28gYmUgYWRkcmVzc2FibGUgd2l0aCBTSVBTLg0KIA0KLSAgIEZvciBleGFtcGxl LCBjb25zaWRlciB0aGUgY2FzZSBvZiBhIFVBIHRoYXQgaGFzIHJlZ2lzdGVyZWQgd2l0aCBTSVBT DQotICAgY29udGFjdCBoZWFkZXIgZmllbGQuICBJZiBhIFVBQyBsYXRlciBhZGRyZXNzZXMgYSBy ZXF1ZXN0IHVzaW5nIGEgU0lQDQorICAgRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBjYXNlIG9m IGEgVUEgdGhhdCBoYXMgcmVnaXN0ZXJlZCB3aXRoIGEgU0lQUw0KKyAgIENvbnRhY3QgaGVhZGVy IGZpZWxkLiAgSWYgYSBVQUMgbGF0ZXIgYWRkcmVzc2VzIGEgcmVxdWVzdCB1c2luZyBhIFNJUA0K ICAgIFJlcXVlc3QtVVJJLCB0aGUgcHJveHkgd2lsbCBmb3J3YXJkIHRoZSByZXF1ZXN0IGFkZHJl c3NlZCB0byBhIFNJUA0KICAgIFJlcXVlc3QtVVJJIHRvIHRoZSBlbmRwb2ludCwgYXMgaWxsdXN0 cmF0ZWQgYnkgbWVzc2FnZSBGMTMgaW4NCi0gICBTZWN0aW9uIDUuMyBhbmQgaW4gU2VjdGlvbiA1 LjQuICBUaGUgcHJveHkgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8NCisgICBzZWN0aW9uIDUuMyBh bmQgaW4gc2VjdGlvbiA1LjQuICBUaGUgcHJveHkgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8NCiAg ICB0aGUgVUEgdXNpbmcgYSBTSVAgUmVxdWVzdC1VUkkgYW5kIG5vdCB0aGUgU0lQUyBSZXF1ZXN0 LVVSSSB1c2VkIGluDQotICAgcmVnaXN0cmF0aW9uIChhbmQgaXQgZG9lcyB0aGlzIGJ5IHN1YnN0 aXR1dGluZyB0aGUgc2lwIHNjaGVtZSB0byB0aGUNCi0gICBzaXBzIHNjaGVtZSBpbiB0aGUgcmVn aXN0ZXJlZCBjb250YWN0IGhlYWRlciBmaWVsZCBiaW5kaW5nKS4gIElmIHRoZQ0KKyAgIHJlZ2lz dHJhdGlvbiAoYW5kIGl0IGRvZXMgdGhpcyBieSBzdWJzdGl0dXRpbmcgdGhlIFNJUCBzY2hlbWUg Zm9yIHRoZQ0KKyAgIFNJUFMgc2NoZW1lIGluIHRoZSByZWdpc3RlcmVkIENvbnRhY3QgaGVhZGVy IGZpZWxkIGJpbmRpbmcpLiAgSWYgdGhlDQogICAgcHJveHkgZGlkIG5vdCBkbyB0aGlzLCBhbmQg aW5zdGVhZCB1c2VkIGEgU0lQUyBSZXF1ZXN0LVVSSSwgdGhlbiB0aGUNCiAgICByZXNwb25zZSAo ZS5nLiwgYSAyMDAgdG8gYW4gSU5WSVRFKSB3b3VsZCBoYXZlIHRvIGluY2x1ZGUgYSBTSVBTDQot ICAgY29udGFjdCBoZWFkZXIgZmllbGQuICBUaGF0IFNJUFMgY29udGFjdCBoZWFkZXIgZmllbGQg d291bGQgdGhlbg0KLSAgIGZvcmNlIHRoZSBvdGhlciBVQSB0byB1c2UgYSBTSVBTIGNvbnRhY3Qg aGVhZGVyIGZpZWxkIGluIGFueSBtaWQtDQorICAgQ29udGFjdCBoZWFkZXIgZmllbGQuICBUaGF0 IFNJUFMgQ29udGFjdCBoZWFkZXIgZmllbGQgd291bGQgdGhlbg0KKyAgIGZvcmNlIHRoZSBvdGhl ciBVQSB0byB1c2UgYSBTSVBTIENvbnRhY3QgaGVhZGVyIGZpZWxkIGluIGFueSBtaWQtDQogICAg ZGlhbG9nIHJlcXVlc3QsIGluY2x1ZGluZyB0aGUgQUNLICh3aGljaCB3b3VsZG4ndCBiZSBwb3Nz aWJsZSBpZiB0aGF0DQogICAgVUEgZGlkIG5vdCBzdXBwb3J0IFNJUFMpLg0KIA0KLSAgIFRoaXMg c3BlY2lmaWNhdGlvbiBtYW5kYXRlcyB0aGF0IGEgcmVzb3VyY2UgZGVzY3JpYmVkIGJ5IGEgU0lQ Uw0KLSAgIFJlcXVlc3QtVVJJIGNhbiBub3QgYmUgImRvd25ncmFkZWQiIHRvIGEgU0lQIFVSSSB3 aGVuIGEgcHJveHkgaXMNCi0gICBmb3J3YXJkaW5nIGEgcmVxdWVzdCBieSBjaGFuZ2luZyB0aGUg c2NoZW1lLCBvciBieSBzZW5kaW5nIHRoZQ0KLSAgIGFzc29jaWF0ZWQgcmVxdWVzdCBvdmVyIGEg bm9uIHNlY3VyZSBsaW5rLiAgU2VlIFNlY3Rpb24gNC4yLg0KKyAgIFRoaXMgc3BlY2lmaWNhdGlv biBtYW5kYXRlcyB0aGF0IHdoZW4gYSBwcm94eSBpcw0KKyAgIGZvcndhcmRpbmcgYSByZXF1ZXN0 IGEgcmVzb3VyY2UgZGVzY3JpYmVkIGJ5IGEgU0lQUw0KKyAgIFJlcXVlc3QtVVJJIGNhbiBub3Qg YmUgImRvd25ncmFkZWQiIHRvIGEgU0lQIFVSSSBieSBjaGFuZ2luZyB0aGUgc2NoZW1lLCBvciBi eSBzZW5kaW5nIHRoZQ0KKyAgIGFzc29jaWF0ZWQgcmVxdWVzdCBvdmVyIGEgbm9uLXNlY3VyZSBs aW5rLiAgU2VlIHNlY3Rpb24gNC4yLg0KIA0KICAgIEZvciBleGFtcGxlLCB0aGUgc2lwOmJvYkBl eGFtcGxlLmNvbSBhbmQgc2lwczpib2JAZXhhbXBsZS5jb20gQU9Scw0KLSAgIG11c3QgcmVmZXIg dG8gdGhlIHNhbWUgdXNlciAiQm9iIiBpbiBkb21haW4gImV4YW1wbGUuY29tIjogdGhlIGZpcnN0 DQorICAgbXVzdCByZWZlciB0byB0aGUgc2FtZSB1c2VyICJCb2IiIGluIHRoZSBkb21haW4gImV4 YW1wbGUuY29tIjogdGhlIGZpcnN0DQogICAgVVJJIGlzIHRoZSBTSVAgdmVyc2lvbiwgYW5kIHRo ZSBzZWNvbmQgb25lIGlzIHRoZSBTSVBTIHZlcnNpb24uICBGcm9tDQogICAgdGhlIHBvaW50IG9m IHZpZXcgb2Ygcm91dGluZywgcmVxdWVzdHMgdG8gZWl0aGVyIHNpcDpib2JAZXhhbXBsZS5jb20N CiAgICBhbmQgc2lwczpib2JAZXhhbXBsZS5jb20gYXJlIHRyZWF0ZWQgdGhlIHNhbWUgd2F5LiAg TG9jYXRpb24gc2VydmljZXMNCkBAIC0zOTcsMzIgKzM5NywzMiBAQA0KICAgIHRoZSBzYW1lIHVz ZXIuICBBdCBmaXJzdCBnbGFuY2UsIHNlY3Rpb24gW1JGQzMyNjFdLzE5LjEuNCBzZWVtcyB0bw0K ICAgIGNvbnRyYWRpY3QgdGhpcyBpZGVhIGJ5IHN0YXRpbmcgdGhhdCBhIFNJUCBhbmQgYSBTSVBT IFVSSSBhcmUgbmV2ZXINCiAgICBlcXVpdmFsZW50LiAgU3BlY2lmaWNhbGx5LCBpdCBzYXlzIHRo YXQgdGhleSBhcmUgbmV2ZXIgZXF1aXZhbGVudCBmb3INCi0gICB0aGUgcHVycG9zZSBvZiBjb21w YXJpbmcgYmluZGluZ3MgaW4gY29udGFjdCBoZWFkZXIgZmllbGQgVVJJcyBpbg0KKyAgIHRoZSBw dXJwb3NlIG9mIGNvbXBhcmluZyBiaW5kaW5ncyBpbiBDb250YWN0IGhlYWRlciBmaWVsZCBVUklz IGluDQogICAgUkVHSVNURVIgcmVxdWVzdHMuICBUaGUga2V5IHBvaW50IGlzIHRoYXQgdGhpcyBz dGF0ZW1lbnQgYXBwbGllcyB0bw0KLSAgIHRoZSBjb250YWN0IGhlYWRlciBmaWVsZCBiaW5kaW5n cyBpbiBhIHJlZ2lzdHJhdGlvbjogaXQgaXMgdGhlDQotICAgYXNzb2NpYXRpb24gb2YgdGhlIGNv bnRhY3QgaGVhZGVyIGZpZWxkIHdpdGggdGhlIEFPUiB0aGF0IHdpbGwNCisgICB0aGUgQ29udGFj dCBoZWFkZXIgZmllbGQgYmluZGluZ3MgaW4gYSByZWdpc3RyYXRpb246IGl0IGlzIHRoZQ0KKyAg IGFzc29jaWF0aW9uIG9mIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCB3aXRoIHRoZSBBT1IgdGhh dCB3aWxsDQogICAgZGV0ZXJtaW5lIGlmIHRoZSB1c2VyIGlzIHJlYWNoYWJsZSBvciBub3Qgd2l0 aCBhIFNJUFMgVVJJLg0KIA0KLSAgIENvbnNpZGVyIHRoaXMgZXhhbXBsZS4gIElmIEJvYiByZWdp c3RlcnMgd2l0aCBhIFNJUFMgY29udGFjdCBoZWFkZXINCisgICBDb25zaWRlciB0aGlzIGV4YW1w bGU6ICBJZiBCb2IgKGJvYkBleGFtcGxlLmNvbSkgcmVnaXN0ZXJzIHdpdGggYSBTSVBTIENvbnRh Y3QgaGVhZGVyDQogICAgZmllbGQgKGUuZy4sIHNpcHM6Ym9iQGJvYnBob25lLmV4YW1wbGUuY29t KSwgdGhlIHJlZ2lzdHJhciBhbmQgdGhlDQotICAgbG9jYXRpb24gc2VydmljZSB0aGVuIGtub3dz IHRoYXQgQm9iIChib2JAZXhhbXBsZS5jb20pIGlzIHJlYWNoYWJsZQ0KKyAgIGxvY2F0aW9uIHNl cnZpY2UgdGhlbiBrbm93IHRoYXQgQm9iIGlzIHJlYWNoYWJsZQ0KICAgIGF0IHNpcHM6Ym9iQGJv YnBob25lLmV4YW1wbGUuY29tLCBhbmQgYXQNCi0gICBzaXA6Ym9iQGJvYnBob25lLmV4YW1wbGUu Y29tLiAgSWYgYSByZXF1ZXN0IGlzIHNlbnQgdG8gQU9SDQotICAgc2lwczpib2JAZXhhbXBsZS5j b20sIEJvYidzIHByb3h5IHdpbGwgcm91dGUgaXQgdG8gQm9iIGF0IFJlcXVlc3QtVVJJDQotICAg c2lwczpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20uICBJZiBhIHJlcXVlc3QgaXMgc2VudCB0byBB T1INCi0gICBzaXA6Ym9iQGV4YW1wbGUuY29tLCBCb2IncyBwcm94eSB3aWxsIHJvdXRlIGl0IHRv IEJvYiBhdCBSZXF1ZXN0LVVSSQ0KKyAgIHNpcDpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20uICBJ ZiBhIHJlcXVlc3QgaXMgc2VudCB0byB0aGUgQU9SDQorICAgc2lwczpib2JAZXhhbXBsZS5jb20s IEJvYidzIHByb3h5IHdpbGwgcm91dGUgaXQgdG8gQm9iIGF0IHRoZSBSZXF1ZXN0LVVSSQ0KKyAg IHNpcHM6Ym9iQGJvYnBob25lLmV4YW1wbGUuY29tLiAgSWYgYSByZXF1ZXN0IGlzIHNlbnQgdG8g dGhlIEFPUg0KKyAgIHNpcDpib2JAZXhhbXBsZS5jb20sIEJvYidzIHByb3h5IHdpbGwgcm91dGUg aXQgdG8gQm9iIGF0IHRoZSBSZXF1ZXN0LVVSSQ0KICAgIHNpcDpib2JAYm9icGhvbmUuZXhhbXBs ZS5jb20uICBUaGUgcHJveHkgc2hvdWxkIGF0dGVtcHQgdG8gdHJhbnNwb3J0DQogICAgdGhlIHJl cXVlc3Qgb3ZlciBUTFMgaWYgYSBUTFMgY29ubmVjdGlvbiBjYW4gYmUgZXN0YWJsaXNoZWQgZXZl biBpZiBhDQogICAgU0lQIFVSSSBpcyB1c2VkLiAgSW5kZWVkLCBzb21lIHByb3hpZXMgbWF5IGV2 ZW4gaGF2ZSBsb2NhbCBwb2xpY2llcw0KICAgIG9mIGFsd2F5cyB1c2luZyBUTFMuICBGdXJ0aGVy bW9yZSwgaWYgQm9iIHdhbnRzIHRvIGVuc3VyZSB0aGF0IGV2ZXJ5DQotICAgcmVxdWVzdCBkZWxp dmVyZWQgdG8gaXQgYmUgYWx3YXlzIHRyYW5zcG9ydGVkIG92ZXIgVExTLCBCb2IgY2FuIHVzZQ0K KyAgIHJlcXVlc3QgZGVsaXZlcmVkIHRvIGhpbSBiZSBhbHdheXMgdHJhbnNwb3J0ZWQgb3ZlciBU TFMsIEJvYiBjYW4gdXNlDQogICAgW0ktRC5pZXRmLXNpcC1vdXRib3VuZF0gd2hlbiByZWdpc3Rl cmluZy4NCiANCi0gICBIb3dldmVyLCBpZiBCb2IgaGFkIHJlZ2lzdGVyZWQgaW5zdGVhZCB3aXRo IGEgU0lQIGNvbnRhY3QgaGVhZGVyDQotICAgZmllbGQgaW5zdGVhZCBvZiBhIFNJUFMgY29udGFj dCBoZWFkZXIgZmllbGQgKGUuZy4sDQotICAgc2lwOmJvYkBib2JwaG9uZS5leGFtcGxlLmNvbSks IHRoZW4gYSByZXF1ZXN0IHRvIEFPUg0KKyAgIEhvd2V2ZXIsIGlmIEJvYiBoYWQgcmVnaXN0ZXJl ZCB3aXRoIGEgU0lQIENvbnRhY3QgaGVhZGVyDQorICAgZmllbGQgaW5zdGVhZCBvZiBhIFNJUFMg Q29udGFjdCBoZWFkZXIgZmllbGQgKGUuZy4sDQorICAgc2lwOmJvYkBib2JwaG9uZS5leGFtcGxl LmNvbSksIHRoZW4gYSByZXF1ZXN0IHRvIHRoZSBBT1INCiAgICBzaXBzOmJvYkBleGFtcGxlLmNv bSB3b3VsZCBub3QgYmUgcm91dGVkIHRvIEJvYiwgc2luY2UgdGhlcmUgaXMgbm8NCi0gICBTSVBT IGNvbnRhY3QgaGVhZGVyIGZpZWxkIGZvciBCb2IsIGFuZCAiZG93bmdyYWRlcyIgZnJvbSBTSVBT IHRvIFNJUA0KKyAgIFNJUFMgQ29udGFjdCBoZWFkZXIgZmllbGQgZm9yIEJvYiwgYW5kICJkb3du Z3JhZGVzIiBmcm9tIFNJUFMgdG8gU0lQDQogICAgYXJlIG5vdCBhbGxvd2VkLg0KIA0KICAgIFNl ZSBTZWN0aW9uIDUgZm9yIGlsbHVzdHJhdGl2ZSBjYWxsIGZsb3dzLg0KQEAgLTQ0OCwxOSArNDQ4 LDE5IEBADQogSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNJUFMgICAgICAgICAg ICAgICAgICAgICAgICBBcHJpbCAyMDA3DQogDQogDQotICAgU0lQUyBVUkkgd2l0aCBhIGNvbnRh Y3QgaGVhZGVyIGZpZWxkIGNvbnRhaW5pbmcgYSBTSVAgVVJJLg0KLSAgIFtSRkMzMjYxXS84LjEu My40IHN0YXRlcyB0aGF0IGlmIHRoZSBVQUMgZGVjaWRlIHRvIHJlY3Vyc2UgdG8gdGhlIFNJUA0K KyAgIFNJUFMgVVJJIHdpdGggYSBDb250YWN0IGhlYWRlciBmaWVsZCBjb250YWluaW5nIGEgU0lQ IFVSSS4NCisgICBbUkZDMzI2MV0vOC4xLjMuNCBzdGF0ZXMgdGhhdCBpZiB0aGUgVUFDIGRlY2lk ZXMgdG8gcmVjdXJzZSB0byB0aGUgU0lQDQogICAgVVJJLCBpdCAiU0hPVUxEIGluZm9ybSB0aGUg dXNlciIuICBXaGVuIGEgcHJveHkgaXMgaGFuZGxpbmcgdGhlIDNYWCwNCi0gICBpdCBjYW4gb2J2 aW91c2x5IG5vdCBpbmRpY2F0ZSBhbnl0aGluZyB0byB0aGUgdXNlciB0aGF0IGl0IGlzIGJlaW5n DQorICAgaXQgb2J2aW91c2x5IGNhbiBub3QgaW5kaWNhdGUgYW55dGhpbmcgdG8gdGhlIHVzZXIg dGhhdCBpcyBiZWluZw0KICAgIHJlZGlyZWN0ZWQgZnJvbSBTSVBTIHRvIFNJUDogdGhlcmVmb3Jl LCBwcm94aWVzIHdvdWxkIG5vdCBiZSBhYmxlDQotICAgcmVjdXJzZSBvbiB0aGUgY29udGFjdCBo ZWFkZXIgZmllbGQsIGFuZCBpbnN0ZWFkIHdvdWxkIGVpdGhlciBmb3J3YXJkDQorICAgcmVjdXJz ZSBvbiB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGQsIGFuZCBpbnN0ZWFkIHdvdWxkIGVpdGhlciBm b3J3YXJkDQogICAgdGhlIDNYWCB0byB0aGUgVUFDIG9yIHJlamVjdCB0aGUgcmVxdWVzdC4NCiAN CiAzLjIuMS4gIERldGVjdGlvbiBvZiBob3AtYnktaG9wIHNlY3VyaXR5DQogDQogICAgVGhlIHBy ZXNlbmNlIG9mIGEgU0lQUyBSZXF1ZXN0LVVSSSBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbmRpY2F0 ZSB0aGF0DQogICAgdGhlIHJlcXVlc3Qgd2FzIHNlbnQgc2VjdXJlbHkgb24gZWFjaCBob3AuICBT byBob3cgZG9lcyBhIFVBUyBrbm93IGlmDQotICAgdGhlIFNJUFMgd2FzIHVzZWQgZm9yIHRoZSBl bnRpcmUgcmVxdWVzdCBwYXRoIHRvIHNlY3VyZSB0aGUgcmVxdWVzdA0KKyAgIFNJUFMgd2FzIHVz ZWQgZm9yIHRoZSBlbnRpcmUgcmVxdWVzdCBwYXRoIHRvIHNlY3VyZSB0aGUgcmVxdWVzdA0KICAg IGVuZC10by1lbmQ/ICBFZmZlY3RpdmVseSwgdGhlIFVBUyBjYW4gbm90IGtub3cgZm9yIHN1cmUu ICBIb3dldmVyLA0KICAgIFtSRkMzMjYxXS8yNi40LjQgcmVjb21tZW5kcyBob3cgYSBVQVMgbWF5 IG1ha2Ugc29tZSBjaGVja3MgdG8NCiAgICB2YWxpZGF0ZSB0aGUgc2VjdXJpdHkuICBBZGRpdGlv bmFsbHksIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyDQpAQCAtNDc2LDkgKzQ3Niw5IEBADQogICAg YmUgY29uZmlndXJlZCB0byBvbmx5IHJvdXRlIFNJUFMuICBTb21lIHByb3hpZXMgbWF5IGJlIGNv bmZpZ3VyZWQgdG8NCiAgICBkZXRlY3Qgbm9uLWNvbXBsaWFuY2VzIGFuZCByZWplY3QgdW4tc2Vj dXJlIHJlcXVlc3RzLiAgRm9yIGV4YW1wbGUsDQogICAgcHJveGllcyBjb3VsZCBpbnNwZWN0IFJl cXVlc3QtVVJJcywgUGF0aCwgUmVjb3JkLVJvdXRlLCBUbywgRnJvbSwNCi0gICBjb250YWN0IGhl YWRlciBmaWVsZCBhbmQgVmlhIGhlYWRlcnMgdG8gZW5mb3JjZSBTSVBTLg0KKyAgIENvbnRhY3Qg aGVhZGVyIGZpZWxkcyBhbmQgVmlhIGhlYWRlcnMgdG8gZW5mb3JjZSBTSVBTLg0KIA0KLSAgIFtS RkMzMjYxXS8yNi40LjQgYWxzbyBleHBsYWlucyB0aGF0IFMvTUlNRSBtYXkgYWxzbyBiZSB1c2Vk IGJ5IHRoZQ0KKyAgIFtSRkMzMjYxXS8yNi40LjQgZXhwbGFpbnMgdGhhdCBTL01JTUUgbWF5IGFs c28gYmUgdXNlZCBieSB0aGUNCiAgICBvcmlnaW5hdGluZyBVQUMgdG8gZW5zdXJlIHRoYXQgdGhl IG9yaWdpbmFsIGZvcm0gb2YgdGhlIFRvIGhlYWRlcg0KICAgIGZpZWxkIGlzIGNhcnJpZWQgZW5k LXRvLWVuZC4gIFdoaWxlIG5vdCBzcGVjaWZpY2FsbHkgbWVudGlvbmVkIGluDQogICAgW1JGQzMy NjFdLzI2LjQuNCwgdGhpcyBpcyBtZWFudCB0byBpbXBseSB0aGF0IFtSRkMzODkzXSB3b3VsZCBi ZSB1c2VkDQpAQCAtNTc0LDcgKzU3NCw3IEBADQogDQogICAgTm90ZSB0aGF0IHRoZSBzYW1lIHJ1 bGVzIGFwcGx5IHRvIHRoZSBQYXRoIEhlYWRlciBbUkZDMzMyN10uDQogDQotMy4zLiAgVXNhZ2Ug b2YgdGxzIHRyYW5zcG9ydCBwYXJhbWV0ZXIgYW5kIFRMUyBWaWEgcGFyYW1ldGVyDQorMy4zLiAg VXNhZ2Ugb2YgdGhlIHRyYW5zcG9ydD10bHMgVVJJIHBhcmFtZXRlciBhbmQgdGhlIFRMUyBWaWEg cGFyYW1ldGVyDQogDQogICAgW1JGQzMyNjFdLzI2LjIuMiBtYWtlcyBpdCBjbGVhciB0aGF0IHRo ZSB1c2Ugb2YgdGhlICJ0cmFuc3BvcnQ9dGxzIg0KICAgIFVSSSB0cmFuc3BvcnQgcGFyYW1ldGVy IGluIFNJUFMgb3IgU0lQIFVSSXMgaGFzIGJlZW4gZGVwcmVjYXRlZDoNCkBAIC02MjUsNyArNjI1 LDcgQEANCiAgICBhcyBhIHJlc3VsdCBvZiB0aGUgcmVkaXJlY3Rpb24uDQogDQogICAgQSBVQUMg dGhhdCBjb25mb3JtcyB0byB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBpbmNsdWRlIGEgc2lwcyBv cHRpb24tDQotICAgdGFnIGluIFN1cHBvcnRlZCBvciBSZXF1aXJlIGhlYWRlciBmaWVsZCB3aGVu IHNlbmRpbmcgYSByZXF1ZXN0LiAgVGhlDQorICAgdGFnIGluIHRoZSBTdXBwb3J0ZWQgb3IgUmVx dWlyZSBoZWFkZXIgZmllbGQgd2hlbiBzZW5kaW5nIGEgcmVxdWVzdC4gIFRoZQ0KICAgIFN1cHBv cnRlZCBoZWFkZXIgaXMgdXNlZnVsIGZvciBhICJiYWNrd2FyZCBjb21wYXRpYmxlIG1vZGUiIHdo ZXJlIHRoZQ0KICAgIFVBUyBtYXkgbm90IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uLCBidXQg c3RpbGwgc3VwcG9ydCBTSVBTIGFzIHBlcg0KICAgIFtSRkMzMjYxXSAobm90ZSBob3dldmVyIHRo YXQgc2luY2UgdGhlIHVzYWdlIG9mIFNJUFMgd2FzIGdyZWF0bHkNCkBAIC02MzUsMTIgKzYzNSwx MiBAQA0KICAgIHRoZSBuZXR3b3JrIChmb3IgZXhhbXBsZSwgdG8gZW5mb3JjZSB0aGUgZGVwcmVj YXRpb24gb2YgdGhlIGxhc3QgaG9wDQogICAgZXhjZXB0aW9uKS4gIElmIHRoZSBSZXF1ZXN0LVVS SSBpcyBhIFNJUCBVUkksIGEgc2lwcyBvcHRpb24tdGFnIGluIGENCiAgICBSZXF1aXJlIGhlYWRl ciBmaWVsZCBNVVNUIE5PVCBiZSB1c2VkLCBhbmQgYSBTdXBwb3J0ZWQgaGVhZGVyIGZpZWxkDQot ICAgTVVTVCBiZSB1c2VkIGluc3RlYWQuICBJZiBhIFVBUyByZWNlaXZlcyBhIHJlcXVlc3Qgd2l0 aCB0aGUgc2lwcw0KKyAgIE1VU1QgYmUgdXNlZCBpbnN0ZWFkLiAgSWYgYSBVQVMgcmVjZWl2ZXMg YSBSRUdJU1RFUiByZXF1ZXN0IHdpdGggdGhlIHNpcHMNCiAgICBvcHRpb24tdGFnIGluIGEgU3Vw cG9ydGVkIG9yIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGFuZCBpdCBhY2NlcHRzIHRoZQ0KICAgIHJl Z2lzdHJhdGlvbiwgaXQgTVVTVCBpbmNsdWRlIHRoZSBzaXBzIG9wdGlvbi10YWcgaW4gU3VwcG9y dGVkIG9yDQogICAgUmVxdWlyZSBoZWFkZXIgaW4gYSAyMDAgKE9LKSByZXNwb25zZS4gIElmIHRo ZSBVQVMgZG9lcyBub3Qgc3VwcG9ydA0KICAgIHRoZSBzaXBzIG9wdGlvbi10YWcsIGl0IHdpbGwg cmVqZWN0IGEgcmVxdWVzdCB3aXRoIGEgc2lwcyBvcHRpb24tdGFnDQotICAgaW4gYSBSZXF1aXJl IGhlYWRlciBmaWVsZCwgYW5kIGl0IHdpbGwgbm8gaW5jbHVkZSB0aGUgc2lwcyBvcHRpb24tdGFn DQorICAgaW4gYSBSZXF1aXJlIGhlYWRlciBmaWVsZCwgYW5kIGl0IHdpbGwgbm90IGluY2x1ZGUg dGhlIHNpcHMgb3B0aW9uLXRhZw0KICAgIGluIGEgMjAwIChPSykgc2VudCBpbiByZXNwb25zZSB0 byBhIHJlcXVlc3Qgd2l0aCBhIHNpcHMgb3B0aW9uLXRhZyBpbg0KICAgIGEgU3VwcG9ydGVkIGhl YWRlci4gIElmIGEgVUFDIHNlbnQgYSByZXF1ZXN0IHdpdGggYSBzaXBzIG9wdGlvbi10YWcNCiAg ICBpbiBhIFN1cHBvcnRlZCBoZWFkZXIsIGFuZCB0aGUgMjAwIChPSykgZGlkIG5vdCBpbmNsdWRl IGEgc2lwcw0KQEAgLTY1Nyw4ICs2NTcsOCBAQA0KICAgIG1hbmRhdGVkIGJ5IFtSRkMzMjYxXS8x Mi4xLjEsICJJZiB0aGUgcmVxdWVzdCB0aGF0IGluaXRpYXRlZCB0aGUNCiAgICBkaWFsb2cgY29u dGFpbmVkIGEgU0lQUyBVUkkgaW4gdGhlIFJlcXVlc3QtVVJJIG9yIGluIHRoZSB0b3AgUmVjb3Jk LQ0KICAgIFJvdXRlIGhlYWRlciBmaWVsZCB2YWx1ZSwgaWYgdGhlcmUgd2FzIGFueSwgb3IgdGhl IENvbnRhY3QgaGVhZGVyDQotICAgZmllbGQgaWYgdGhlcmUgd2FzIG5vIFJlY29yZC1Sb3V0ZSBo ZWFkZXIgZmllbGQsIHRoZSBjb250YWN0IGhlYWRlcg0KLSAgIGZpbGVkIGluIHRoZSByZXNwb25z ZSBNVVNUIGJlIGEgU0lQUyBVUkkiLg0KKyAgIGZpZWxkIGlmIHRoZXJlIHdhcyBubyBSZWNvcmQt Um91dGUgaGVhZGVyIGZpZWxkLCB0aGUgQ29udGFjdCBoZWFkZXINCisgICBmaWVsZCBpbiB0aGUg cmVzcG9uc2UgTVVTVCBiZSBhIFNJUFMgVVJJIi4NCiANCiAgICBJZiBhIFVBUyBkb2VzIG5vdCBz dXBwb3J0IFNJUFMsICJpdCBTSE9VTEQgcmVqZWN0IHRoZSByZXF1ZXN0IHdpdGggYQ0KICAgIDQx NiAoVW5zdXBwb3J0ZWQgVVJJIHNjaGVtZSkgcmVzcG9uc2UiIGFzIGRlc2NyaWJlZCBpbiBbUkZD MzI2MV0vDQpAQCAtNjc1LDcgKzY3NSw3IEBADQogICAgZGVzY3JpYmVkIGluIFtSRkMzMjYxXS84 LjEuMy41IGFzIGl0IHdvdWxkIGJlIGEgc2VjdXJpdHkNCiAgICB2dWxuZXJhYmlsaXR5LiAgSWYg dGhlIFVBQyBkb2VzIHJlLWF0dGVtcHQgdGhlIGNhbGwgd2l0aCBhIFNJUCBVUkksDQogICAgaXQg U0hPVUxEIGdldCBhIGNvbmZpcm1hdGlvbiBmcm9tIHRoZSB1c2VyIHRvIGF1dGhvcml6ZSByZS1p bml0aWF0aW5nDQotICAgdGhlIHNlc3Npb24gd2l0aCBhIFNJUCBSZXF1c3QtVVJJIGluc3RlYWQg b2YgYSBTSVBTIFJlcXVlc3QtVVJJLg0KKyAgIHRoZSBzZXNzaW9uIHdpdGggYSBTSVAgUmVxdWVz dC1VUkkgaW5zdGVhZCBvZiBhIFNJUFMgUmVxdWVzdC1VUkkuDQogDQogICAgSWYgYSBVQVMgZG9l cyBub3Qgd2lzaCB0byBiZSBjb250YWN0ZWQgd2l0aCBhIFNJUCBVUkksIGl0IE1BWSByZWplY3QN CiAgICBhIHJlcXVlc3QgdG8gYSBTSVAgUmVxdWVzdC1VUkkgd2l0aCByZXNwb25zZSBjb2RlIDQw NCAoTm90IEZvdW5kKSwgb3INCkBAIC02ODcsMzEgKzY4NywzMSBAQA0KICAgIFVwb24gcmVjZWl2 aW5nIGEgM1hYIHJlc3BvbnNlIHdpdGggYSBTSVBTIENvbnRhY3QgaGVhZGVyIGZpZWxkLCB0aGUN CiAgICBVQUMgU0hPVUxEIGF1dG9tYXRpY2FsbHkgcmUtaW5pdGlhdGUgdGhlIHJlcXVlc3QgdXNp bmcgYSBTSVBTDQogICAgUmVxdWVzdC1VUkkgKGkuZS4sIGl0IGRvZXMgbm90IG5lZWQgdG8gZ2V0 IGEgY29uZmlybWF0aW9uIGZyb20gdGhlDQotICAgdXNlciB0byBhdXRvcml6ZSByZS1pbml0aWF0 aW5nIHRoZSBzZXNzaW9uIHdpdGggYSBTSVBTIFJlcXVlc3QtVVJJDQorICAgdXNlciB0byBhdXRo b3JpemUgcmUtaW5pdGlhdGluZyB0aGUgc2Vzc2lvbiB3aXRoIGEgU0lQUyBSZXF1ZXN0LVVSSQ0K ICAgIGluc3RlYWQgb2YgYSBTSVAgUmVxdWVzdC1VUkkpLg0KIA0KIDQuMS4xLiAgU2VydmljZSBy b3V0ZXMNCiANCi0gICBJZiBhIFVBIHJlZ2lzdGVycyB3aXRoIGEgU0lQUyBjb250YWN0IGhlYWRl ciBmaWVsZCwgdGhlIHJlZ2lzdHJhcg0KKyAgIElmIGEgVUEgcmVnaXN0ZXJzIHdpdGggYSBTSVBT IENvbnRhY3QgaGVhZGVyIGZpZWxkLCB0aGUgcmVnaXN0cmFyDQogICAgcmV0dXJuaW5nIGEgc2Vy dmljZSByb3V0ZSBNVVNUIHJldHVybiBhIHNlcnZpY2Ugcm91dGUgY29uc2lzdGluZyBvZg0KICAg IFNJUCBVUklzIGlmIHRoZSBpbnRlbnQgb2YgdGhlIHJlZ2lzdHJhciBpcyB0byBhbGxvdyBib3Ro IFNJUCBhbmQgU0lQUw0KICAgIHRvIGJlIHVzZWQgaW4gcmVxdWVzdHMgc2VudCBieSB0aGF0IGNs aWVudC4gIElmIGEgVUEgcmVnaXN0ZXJzIHdpdGggYQ0KLSAgIFNJUFMgY29udGFjdCBoZWFkZXIg ZmllbGQsIHRoZSByZWdpc3RyYXIgcmV0dXJuaW5nIGEgc2VydmljZSByb3V0ZQ0KKyAgIFNJUFMg Q29udGFjdCBoZWFkZXIgZmllbGQsIHRoZSByZWdpc3RyYXIgcmV0dXJuaW5nIGEgc2VydmljZSBy b3V0ZQ0KICAgIE1VU1QgcmV0dXJuIGEgc2VydmljZSByb3V0ZSBjb25zaXN0aW5nIG9mIFNJUFMg VVJJcyBpZiB0aGUgaW50ZW50IG9mDQogICAgdGhlIHJlZ2lzdHJhciBpcyB0byBhbGxvdyBvbmx5 IFNJUFMgVVJJcyB0byBiZSB1c2VkIGluIHJlcXVlc3RzIHNlbnQNCiAgICBieSB0aGF0IFVBLiAg SXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBVQUMgdG8gdXNlIGEgUm91dGUNCiAgICBo ZWFkZXIgY29uc2lzdGluZyBvZiBhbGwgU0lQUyBVUklzIHdoZW4gdXNpbmcgYSBTSVBTIFJlcXVl c3QtVVJJIGFuZA0KLSAgIGNvbnRhY3QgaGVhZGVyIGZpZWxkLiAgU3BlY2lmaWNhbGx5LCBJZiB0 aGUgc2VydmljZSByb3V0ZSBpbmNsdWRlZA0KKyAgIENvbnRhY3QgaGVhZGVyIGZpZWxkLiAgU3Bl Y2lmaWNhbGx5LCBpZiB0aGUgc2VydmljZSByb3V0ZSBpbmNsdWRlZCBhDQogICAgU0lQIFVSSSwg dGhlIFVBQyBNVVNUIHVwZ3JhZGUgdGhlIFNJUCBVUklzIHRvIFNJUFMgVVJJcyBzaW1wbHkgYnkN CiAgICBjaGFuZ2luZyB0aGUgc2NoZW1lIGZyb20gInNpcCIgdG8gInNpcHMiIGJlZm9yZSBzZW5k aW5nIHRoZSByZXF1ZXN0Lg0KLSAgIE5vdGUgdGhhdCB0aGlzIGFsbG93cyBmb3IgY29uZmlndXJp bmcgb3IgZGlzY292ZXJpbmcgb25lIFNlcnZpY2UNCi0gICBSb3V0ZSB3aXRoIGFsbCBTSVAgVVJJ cyBhbmQgYWxsb3dpbmcgc2VuZGluZyByZXF1ZXN0cyB0byBib3RoIFNJUCBhbmQNCisgICBOb3Rl IHRoYXQgdGhpcyBhbGxvd3MgZm9yIGNvbmZpZ3VyaW5nIG9yIGRpc2NvdmVyaW5nIG9uZSBzZXJ2 aWNlDQorICAgcm91dGUgd2l0aCBvbmx5IFNJUCBVUklzIGFuZCBhbGxvd2luZyBzZW5kaW5nIHJl cXVlc3RzIHRvIGJvdGggU0lQIGFuZA0KICAgIFNJUFMgVVJJcy4NCiANCiA0LjEuMi4gIFJlZ2lz dHJhdGlvbg0KIA0KICAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZWR1cmVzIG9mIFNJUFMgdmVyc3VzIFNJUA0KLSAgIGNvbnRhY3QgaGVhZGVyIGZpZWxkIHRo YXQgZm9sbG93cyBmcm9tIHRoZSBkaXNjdXNzaW9uIGluIFNlY3Rpb24gMy4yLg0KKyAgIENvbnRh Y3QgaGVhZGVyIGZpZWxkcyB0aGF0IGZvbGxvd3MgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpbiBzZWN0 aW9uIDMuMi4NCiANCiAgICBUaGUgVUFDIHJlZ2lzdGVycyBlaXRoZXIgYSBTSVBTIG9yIGEgU0lQ IEFPUi4gIEZyb20gYSByb3V0aW5nDQogICAgcGVyc3BlY3RpdmUsIGl0IGRvZXMgbm90IG1hdHRl ciB3aGljaCBvbmUgaXMgdXNlZCBmb3IgcmVnaXN0cmF0aW9uIGFzDQpAQCAtNzI4LDMxICs3Mjgs MzEgQEANCiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU0lQUyAgICAgICAgICAg ICAgICAgICAgICAgIEFwcmlsIDIwMDcNCiANCiANCi0gICBhIFNJUFMgY29udGFjdCBoZWFkZXIg ZmllbGQuICBSZXF1ZXN0cyBhZGRyZXNzZWQgdG8gdGhhdCBVQSdzIEFPUg0KKyAgIGEgU0lQUyBD b250YWN0IGhlYWRlciBmaWVsZC4gIFJlcXVlc3RzIGFkZHJlc3NlZCB0byB0aGF0IFVBJ3MgQU9S DQogICAgdXNpbmcgZWl0aGVyIGEgU0lQIG9yIFNJUFMgUmVxdWVzdC1VUkkgd2lsbCBiZSByb3V0 ZWQgdG8gdGhhdCBVQS4NCi0gICBOb3RlIHRoYXQgdGhpcyBpbmNsdWRlcyBVQSB0aGF0IHN1cHBv cnQgYm90aCBTSVAgYW5kIFNJUFMuDQorICAgTm90ZSB0aGF0IHRoaXMgaW5jbHVkZXMgVUFzIHRo YXQgc3VwcG9ydCBib3RoIFNJUCBhbmQgU0lQUy4NCiANCiAgICBJZiBhIFVBIGRvZXMgbm90IHdp c2ggdG8gYmUgcmVhY2hlZCB3aXRoIGEgU0lQUyBVUkksIGl0IE1VU1QgcmVnaXN0ZXINCi0gICB3 aXRoIGEgU0lQIGNvbnRhY3QgaGVhZGVyIGZpZWxkLiAgVGhlIFVBIE1VU1QgTk9UIGluY2x1ZGUg YSBzaXBzDQorICAgd2l0aCBhIFNJUCBDb250YWN0IGhlYWRlciBmaWVsZC4gIFRoZSBVQSBNVVNU IE5PVCBpbmNsdWRlIGEgc2lwcw0KICAgIG9wdGlvbi10YWcgaW4gdGhhdCBjYXNlLg0KIA0KLSAg IEJlY2F1c2UgcmVnaXN0ZXJpbmcgd2l0aCBhIFNJUFMgY29udGFjdCBoZWFkZXIgZmllbGQgaW1w bGllcyBhDQorICAgQmVjYXVzZSByZWdpc3RlcmluZyB3aXRoIGEgU0lQUyBDb250YWN0IGhlYWRl ciBmaWVsZCBpbXBsaWVzIGENCiAgICBiaW5kaW5nIHRvIGJvdGggYSBTSVBTIENvbnRhY3QgYW5k IGEgY29ycmVzcG9uZGluZyBTSVAgQ29udGFjdCwgYSBVQQ0KICAgIE1VU1QgTk9UIGluY2x1ZGUg Ym90aCB0aGUgU0lQUyBhbmQgdGhlIFNJUCB2ZXJzaW9uIG9mIHRoZSBzYW1lDQotICAgY29udGFj dCBoZWFkZXIgZmllbGQgaW4gYSBSRUdJU1RFUjogaXQgTVVTVCBvbmx5IHVzZSB0aGUgU0lQUyB2 ZXJzaW9uDQotICAgaW4gdGhpcyBjYXNlLiAgU2ltaWxhcmx5LCBhIFVBIFNIT1VMRCBOT1QgcmVn aXN0ZXIgYm90aCBhIFNJUCBjb250YWN0DQotICAgaGVhZGVyIGZpZWxkIGFuZCBhIFNJUFMgY29u dGFjdCBoZWFkZXIgZmllbGQgaW4gc2VwYXJhdGUNCi0gICByZWdpc3RyYXRpb25zIGFzIHRoZSBT SVAgY29udGFjdCBoZWFkZXIgZmllbGQgd291bGQgYmUgc3VwZXJmbHVvdXMuDQotICAgTm90ZSBo b3dldmVyIHRoYXQgYSBVQSBjb3VsZCByZWdpc3RlciBmaXJzdCB3aXRoIGEgU0lQIGNvbnRhY3Qg aGVhZGVyDQorICAgQ29udGFjdCBoZWFkZXIgZmllbGQgaW4gYSBSRUdJU1RFUjogaXQgTVVTVCBv bmx5IHVzZSB0aGUgU0lQUyB2ZXJzaW9uDQorICAgaW4gdGhpcyBjYXNlLiAgU2ltaWxhcmx5LCBh IFVBIFNIT1VMRCBOT1QgcmVnaXN0ZXIgYm90aCBhIFNJUCBDb250YWN0DQorICAgaGVhZGVyIGZp ZWxkIGFuZCBhIFNJUFMgQ29udGFjdCBoZWFkZXIgZmllbGQgaW4gc2VwYXJhdGUNCisgICByZWdp c3RyYXRpb25zIGFzIHRoZSBTSVAgQ29udGFjdCBoZWFkZXIgZmllbGQgd291bGQgYmUgc3VwZXJm bHVvdXMuDQorICAgTm90ZSBob3dldmVyIHRoYXQgYSBVQSBjb3VsZCByZWdpc3RlciBmaXJzdCB3 aXRoIGEgU0lQIENvbnRhY3QgaGVhZGVyDQogICAgZmllbGQgKG1lYW5pbmcgaXQgZG9lcyBub3Qg c3VwcG9ydCBTSVBTKSwgYW5kIGxhdGVyIHJlZ2lzdGVyIHdpdGggYQ0KLSAgIFNJUFMgY29udGFj dCBoZWFkZXIgZmllbGQgKG1lYW5pbmcgaXQgbm93IHN1cHBvcnRzIFNJUFMpLg0KKyAgIFNJUFMg Q29udGFjdCBoZWFkZXIgZmllbGQgKG1lYW5pbmcgaXQgbm93IHN1cHBvcnRzIFNJUFMpLg0KIA0K ICAgIElmIGEgVUEgd2FudHMgdG8gZW5zdXJlIHRoYXQgbm8gcmVxdWVzdHMgYXJlIGRlbGl2ZXJl ZCB3aXRob3V0IHVzaW5nDQotICAgVExTIG9uIHRoYXQgbGFzdCBob3AsIHRoZSBVQSBNVVNUIHVz ZSBbSS1ELmlldGYtc2lwLW91dGJvdW5kXS4NCisgICBUTFMgb24gdGhlIGxhc3QgaG9wLCB0aGUg VUEgTVVTVCB1c2UgW0ktRC5pZXRmLXNpcC1vdXRib3VuZF0uDQogDQotICAgSWYgYWxsIHRoZSBj b250YWN0IGhlYWRlciBmaWVsZHMgaW4gYSBSRUdJU1RFUiBhcmUgU0lQUywgYSBTSVBTIEFPUg0K KyAgIElmIGFsbCB0aGUgQ29udGFjdCBoZWFkZXIgZmllbGRzIGluIGEgUkVHSVNURVIgYXJlIFNJ UFMsIGEgU0lQUyBBT1INCiAgICBNVVNUIGJlIHVzZWQgYnkgdGhlIFVBQyBpbiB0aGUgUkVHSVNU RVIuICBJZiBhdCBsZWFzdCBvbmUgb2YgdGhlDQotICAgY29udGFjdCBoZWFkZXIgZmllbGRzIGlz IFNJUCBvciBpcyBuZWl0aGVyIFNJUCBub3IgU0lQUyAoZS5nLiwNCisgICBDb250YWN0IGhlYWRl ciBmaWVsZHMgaXMgU0lQIG9yIGlzIG5laXRoZXIgU0lQIG5vciBTSVBTIChlLmcuLA0KICAgIG1h aWx0bywgdGVsLCBodHRwLCBodHRwcyksIGEgU0lQIEFPUiBNVVNUIGFsc28gYmUgdXNlZCBieSB0 aGUgVUFDLg0KICAgIEhvd2V2ZXIsIHRoZSByZWdpc3RyYXIgTVVTVCB0cmVhdCB0aGUgU0lQIGFu ZCBTSVBTIHNjaGVtZXMgb2YgdGhlIEFPUg0KICAgIHRoZSBzYW1lIHdheSAoaS5lLiwgaXQgTVVT VCBub3QgY2FyZSBpZiBpdCBpcyBTSVAgb3IgU0lQUykuICBUaGVzZQ0KQEAgLTc2MiwxNyArNzYy LDE3IEBADQogICAgaW5jb21pbmcgcmVxdWVzdHMgYWRkcmVzc2VkIHRvIGEgVVJJIHNjaGVtZSB0 aGF0IGRvZXMgbm90IGNvcnJlc3BvbmQNCiAgICB0byB3aGF0IGl0IHVzZWQgZm9yIHJlZ2lzdHJh dGlvbi4gIEZvciBleGFtcGxlLCBhIFVBIHdpdGggYSBwb2xpY3kgb2YNCiAgICAiYWx3YXlzIFNJ UFMiIHdvdWxkIGFkZHJlc3MgdGhlIFJlZ2lzdHJhciB1c2luZyBhIFNJUFMgUmVxdWVzdC1VUkkN Ci0gICBvdmVyIFRMUywgd291bGQgcmVnaXN0ZXIgd2l0aCBhIFNJUFMgY29udGFjdCBoZWFkZXIg ZmllbGQsIGFuZCB3b3VsZA0KKyAgIG92ZXIgVExTLCB3b3VsZCByZWdpc3RlciB3aXRoIGEgU0lQ UyBDb250YWN0IGhlYWRlciBmaWVsZCwgYW5kIHdvdWxkDQogICAgcmVqZWN0IHJlcXVlc3RzIGFk ZHJlc3NlZCB0byBhIFNJUCBSZXF1ZXN0LVVSSSB3aXRoIDQwMyAoRm9yYmlkZGVuKS4NCiAgICBB IFVBIHdpdGggYSBwb2xpY3kgb2YgImJlc3QtZWZmb3J0IFNJUFMiIHdvdWxkIGFkZHJlc3MgdGhl IFJlZ2lzdHJhcg0KLSAgIHVzaW5nIGEgU0lQUyBSZXF1ZXN0LVVSSSBvdmVyIFRMUywgd291bGQg cmVnaXN0ZXIgd2l0aCBhIFNJUFMgY29udGFjdA0KKyAgIHVzaW5nIGEgU0lQUyBSZXF1ZXN0LVVS SSBvdmVyIFRMUywgd291bGQgcmVnaXN0ZXIgd2l0aCBhIFNJUFMgQ29udGFjdA0KICAgIGhlYWRl ciBmaWVsZCwgYW5kIHdvdWxkIGFjY2VwdCByZXF1ZXN0cyBhZGRyZXNzZWQgdG8gZWl0aGVyIFNJ UCBvcg0KICAgIFNJUFMgUmVxdWVzdC1VUklzLiAgQSBVQSB3aXRoIGEgcG9saWN5IG9mICJObyBT SVBTIiB3b3VsZCBhZGRyZXNzIHRoZQ0KICAgIFJlZ2lzdHJhciB1c2luZyBhIFNJUCBSZXF1ZXN0 LVVSSSwgY291bGQgdXNlIFRMUyBvciBub3QsIHdvdWxkDQotICAgcmVnaXN0ZXIgd2l0aCBhIFNJ UCBBT1IgYW5kIGEgU0lQIGNvbnRhY3QgaGVhZGVyIGZpZWxkLCBhbmQgd291bGQNCisgICByZWdp c3RlciB3aXRoIGEgU0lQIEFPUiBhbmQgYSBTSVAgQ29udGFjdCBoZWFkZXIgZmllbGQsIGFuZCB3 b3VsZA0KICAgIGFjY2VwdCByZXF1ZXN0cyBhZGRyZXNzZWQgdG8gYSBTSVAgUmVxdWVzdC1VUkku DQogDQotICAgQSByZWdpc3RyYXIgTVVTVCBvbmx5IGFjY2VwdCBhIGJpbmRpbmcgdG8gYSBTSVBT IGNvbnRhY3QgaGVhZGVyIGZpZWxkDQorICAgQSByZWdpc3RyYXIgTVVTVCBvbmx5IGFjY2VwdCBh IGJpbmRpbmcgdG8gYSBTSVBTIENvbnRhY3QgaGVhZGVyIGZpZWxkDQogICAgaWYgYWxsIHRoZSBh cHByb3ByaWF0ZSBVUklzIGFyZSBvZiB0aGUgU0lQUyBzY2hlbWUsIG90aGVyd2lzZSB0aGVyZQ0K ICAgIGNvdWxkIGJlIGFuIGluYWR2ZXJ0ZW50IGJpbmRpbmcgb2YgYSBzZWN1cmUgcmVzb3VyY2Ug KFNJUFMpIHRvIGFuDQogICAgdW5zZWN1cmVkIG9uZSAoU0lQKS4gIFRoaXMgaW5jbHVkZXMgdGhl IFJlcXVlc3QtVVJJLCB0aGUgQ29udGFjdHMgYW5kDQpAQCAtNzg4LDE1ICs3ODgsMTUgQEANCiAg ICBJZiB0aGUgVVJJcyBhcmUgbm90IG9mIHRoZSBwcm9wZXIgU0lQUyBzY2hlbWUsIHRoZSByZWdp c3RyYXIgTVVTVA0KICAgIHJlamVjdCB0aGUgUkVHSVNURVIgd2l0aCBhIDQwMyAoRm9yYmlkZGVu KS4NCiANCi0gICBUaGUgdXNhZ2Ugb2YgdGhlICJ0cmFuc3BvcnQiIFVSSSBwYXJhbWV0ZXIgaW4g Y29udGFjdCBoZWFkZXIgZmllbGRzDQorICAgVGhlIHVzYWdlIG9mIHRoZSAidHJhbnNwb3J0IiBV UkkgcGFyYW1ldGVyIGluIENvbnRhY3QgaGVhZGVyIGZpZWxkcw0KICAgIGluIHJlZ2lzdHJhdGlv biBpcyBvZiBkdWJpb3VzIHVzZWZ1bG5lc3MuICBUaGUgYXNzdW1wdGlvbiBpcyB0aGF0IGENCiAg ICBVQUMgd291bGQgY2hvb3NlIG9uZSB0cmFuc3BvcnQgZm9yIHRoZSByZWdpc3RyYXRpb24gaXRz ZWxmLCBhbmQgYQ0KICAgIGRpZmZlcmVudCB0cmFuc3BvcnQgZm9yIHJlY2VpdmluZyByZXF1ZXN0 cy4gIFVzaW5nIHRoZSB0cmFuc3BvcnQgVVJJDQogICAgcGFyYW1ldGVycyBhbHNvIHJlc3VsdHMg aW4gc29tZSBjb21wbGV4IHByb2JsZW1zLiAgRm9yIGV4YW1wbGUsDQotICAgc2hvdWxkIGFsbCB0 aGUgdHJhbnNwb3J0cyBiZSBsaXN0ZWQgYXMgc2VwYXJhdGUgY29udGFjdCBoZWFkZXIgZmllbGRz DQotICAgKGUuZywgdWRwLCBUQ1AsIHNjdHAsIHRscyBvdmVyIFRDUCwgdGxzIG92ZXIgc2N0cCk/ ICBJZiBzbywgdGhlcmUgaXMNCi0gICBubyB3YXkgdG8gc2lnbmFsIHRscyBvdmVyIHNjdHAgZGVm aW5lZCB5ZXQuICBGdXJ0aGVybW9yZSwgaG93IHNob3VsZA0KLSAgIHRoZXkgYmUgcHJpb3JpdGl6 ZWQgdXNpbmcgYSBxLXZhbHVlPyAgSWYgc28sIGl0IGlzIHBvc3NpYmxlIHRoYXQNCisgICBzaG91 bGQgYWxsIHRoZSB0cmFuc3BvcnRzIGJlIGxpc3RlZCBhcyBzZXBhcmF0ZSBDb250YWN0IGhlYWRl ciBmaWVsZHMNCisgICAoZS5nLCBVRFAsIFRDUCwgU0NUUCwgVExTIG92ZXIgVENQLCBUTFMgb3Zl ciBTQ1RQKT8gIElmIHNvLCB0aGVyZSBpcw0KKyAgIG5vIHdheSB0byBzaWduYWwgVExTIG92ZXIg U0NUUCBkZWZpbmVkIHlldC4gIEZ1cnRoZXJtb3JlLCBob3cgc2hvdWxkDQorICAgdGhleSBiZSBw cmlvcml0aXplZCB1c2luZyBhIHEtdmFsdWU/ICBJZiBzbywgaXQgaXMgYWxzbyBwb3NzaWJsZSB0 aGF0DQogICAgY2VydGFpbiBwcm94aWVzIHdpbGwgaW50ZXJwcmV0IHRoaXMgYXMgYSBmb3JraW5n IHNjZW5hcmlvIGFuZCB0aGV5DQogICAgbWlnaHQgZGVjaWRlIHRvIHNlbmQgb25lIGluY29taW5n IHJlcXVlc3QgcGVyIHRyYW5zcG9ydC4gIEFub3RoZXINCiAgICBpc3N1ZSBpcyB3aGF0IGhhcHBl bnMgaWYgYSBVQUMgZmV0Y2hlcyBiaW5kaW5ncyBieSBzZW5kaW5nIGFuIGVtcHR5DQpAQCAtODA0 LDMzICs4MDQsMzQgQEANCiAgICBwb3NzaWJsZSB0cmFuc3BvcnQ/ICBBbGwgdGhpcyB3b3VsZCBn ZW5lcmF0ZSB1bndhcnJhbnRlZCBjb21wbGV4aXR5Lg0KIA0KICAgIEl0IGlzIHRoZXJlZm9yZSBS RUNPTU1FTkRFRCB0aGF0IFVBQ3MgZG8gbm90IHVzZSBhbnkgdHJhbnNwb3J0IFVSSQ0KLSAgIHBh cmFtZXRlcnMgaW4gY29udGFjdCBoZWFkZXIgZmllbGRzIGluIFJFR0lTVEVSLg0KKyAgIHBhcmFt ZXRlcnMgaW4gQ29udGFjdCBoZWFkZXIgZmllbGRzIGluIFJFR0lTVEVSLg0KIA0KICAgIEZvciBi YWNrd2FyZCBjb21wYXRpYmlsaXR5LCBhIHJlZ2lzdHJhciBzaG91bGQgYWNjZXB0IGEgUkVHSVNU RVINCi0gICBtZXNzYWdlIHdpdGggYSB0cmFuc3BvcnQgVVJJIHBhcmFtZXRlciBpbiB0aGUgY29u dGFjdCBoZWFkZXIgZmllbGQuDQorICAgbWVzc2FnZSB3aXRoIGEgdHJhbnNwb3J0IFVSSSBwYXJh bWV0ZXIgaW4gdGhlIENvbnRhY3QgaGVhZGVyIGZpZWxkLg0KICAgIEl0IGlzIHJlY29tbWVuZGVk IHRoYXQgYSByZWdpc3RyYXIgaWdub3JlcyB0aGF0IHBhcmFtZXRlciwgaS5lLiwgdGhhdA0KICAg IGl0IHdpbGwgbm90IGluZmx1ZW5jZSByb3V0aW5nLg0KIA0KIDQuMS4zLiAgU0lQUyBpbiBhIGRp YWxvZw0KIA0KICAgIElmIHRoZSBSZXF1ZXN0LVVSSSBpbiBhIHJlcXVlc3QgdGhhdCBpbml0aWF0 ZXMgYSBkaWFsb2cgaXMgYSBTSVAgVVJJLA0KLSAgIHRoZW4gdGhlIFVBQyBuZWVkcyB0byBiZSBj YXJlZnVsIGFib3V0IHdoYXQgdG8gdXNlIGluIHRoZSBjb250YWN0DQorICAgdGhlbiB0aGUgVUFD IG5lZWRzIHRvIGJlIGNhcmVmdWwgYWJvdXQgd2hhdCB0byB1c2UgaW4gdGhlIENvbnRhY3QNCiAg ICBoZWFkZXIgZmllbGQgKGluIGNhc2UgUmVjb3JkLVJvdXRlIGlzIG5vdCB1c2VkIGZvciB0aGlz IGhvcCkuICBJZiB0aGUNCi0gICBjb250YWN0IGhlYWRlciBmaWVsZCB3YXMgYSBTSVBTIFVSSSwg aXQgd291bGQgbWVhbiB0aGF0IGl0IHdvdWxkIG9ubHkNCi0gICBhY2NlcHQgbWlkLWRpYWxvZyBy ZXF1ZXN0cyB0aGF0IGFyZSBzZW50IG92ZXIgc2VjdXJlIHRyYW5zcG9ydCBvbg0KLSAgIGVhY2gg aG9wLiAgU2luY2UgdGhlIFJlcXVlc3QtVVJJIGlzIGluIHRoaXMgY2FzZSBhIFNJUCBVUkksIGl0 IGlzDQorICAgQ29udGFjdCBoZWFkZXIgZmllbGQgd2FzIGEgU0lQUyBVUkksIGl0IHdvdWxkIG1l YW4gdGhhdCBpdCB3b3VsZCBvbmx5DQorICAgYWNjZXB0IG1pZC1kaWFsb2cgcmVxdWVzdHMgdGhh dCBhcmUgc2VudCBvdmVyIGEgc2VjdXJlIHRyYW5zcG9ydCBvbg0KKyAgIGVhY2ggaG9wLiAgU2lu Y2UgdGhlIFJlcXVlc3QtVVJJIGluIHRoaXMgY2FzZSBpcyBhIFNJUCBVUkksIGl0IGlzDQogICAg cXVpdGUgcG9zc2libGUgdGhhdCB0aGUgVUEgc2VuZGluZyBhIHJlcXVlc3QgdG8gdGhhdCBVUkkg bWF5IG5vdCBiZQ0KICAgIGFibGUgdG8gc2VuZCByZXF1ZXN0cyB0byBTSVBTIFVSSXMuICBJZiB0 aGUgdG9wIFJvdXRlIGhlYWRlciBmaWVsZA0KLSAgIGRvZXMgbm90IGNvbnRhaW4gYSBTSVBTIFVS SSwgdGhlIGNvbnRhY3QgaGVhZGVyIGZpZWxkIE1VU1QgYmUgYSBTSVANCisgICBkb2VzIG5vdCBj b250YWluIGEgU0lQUyBVUkksIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZCBNVVNUIGJlIGEgU0lQ DQogICAgVVJJLCBldmVuIGlmIHRoZSByZXF1ZXN0IGlzIHNlbnQgb3ZlciBhIHNlY3VyZSB0cmFu c3BvcnQgKGUuZy4sIHRoZQ0KICAgIGZpcnN0IGhvcCBjb3VsZCBiZSByZS11c2luZyBhIFRMUyBj b25uZWN0aW9uIHRvIHRoZSBwcm94eSBhcyB3b3VsZCBiZQ0KICAgIHRoZSBjYXNlIHdpdGggW0kt RC5pZXRmLXNpcC1vdXRib3VuZF0pLg0KIA0KICAgIFdoZW4gYSB0YXJnZXQgcmVmcmVzaCBvY2N1 cnMgd2l0aGluIGEgZGlhbG9nIChlLmcuLCByZS1JTlZJVEUsDQogICAgVVBEQVRFKSwgdW5sZXNz IHRoZXJlIGlzIGEgbmVlZCB0byBjaGFuZ2UgaXQsIHRoZSBVQUMgYW5kIFVBUyBNVVNUDQotICAg aW5jbHVkZSBhIGNvbnRhY3QgaGVhZGVyIGZpZWxkIHdpdGggYSBTSVBTIFVSSSBpZiB0aGUgb3Jp Z2luYWwNCisgICBpbmNsdWRlIGEgQ29udGFjdCBoZWFkZXIgZmllbGQgd2l0aCBhIFNJUFMgVVJJ IGlmIHRoZSBvcmlnaW5hbA0KICAgIHJlcXVlc3QgdXNlZCBhIFNJUFMgUmVxdWVzdC1VUkkuDQog DQorRXhhY3RseSB3aGF0IGRvZXMgImEgbmVlZCIgbWVhbiBoZXJlPw0KIA0KIA0KIA0KQEAgLTg1 MiwxMCArODUzLDEwIEBADQogDQogICAgRm9yIGV4YW1wbGUsIHdoZW4gYSBSRUZFUiByZXF1ZXN0 IGlzIHVzZWQgdG8gcGVyZm9ybSBhIGNhbGwgdHJhbnNmZXIsDQogICAgaXQgcmVzdWx0cyBpbiBh biBleGlzdGluZyBkaWFsb2cgYmVpbmcgdGVybWluYXRlZCBhbmQgYW5vdGhlciBvbmUNCi0gICBi ZWluZyBjcmVhdGVkIGJhc2VkIG9uIHRoZSBSZWZlci10byBVUkkuICBJZiB0aGF0IGluaXRpYWwg ZGlhbG9nIHdhcw0KKyAgIGJlaW5nIGNyZWF0ZWQgYmFzZWQgb24gdGhlIFJlZmVyLVRvIFVSSS4g IElmIHRoYXQgaW5pdGlhbCBkaWFsb2cgd2FzDQogICAgZXN0YWJsaXNoZWQgdXNpbmcgU0lQUywg dGhlbiB0aGUgbmV3IG9uZSBNVVNUIE5PVCBiZSBlc3RhYmxpc2hlZA0KICAgIHVzaW5nIFNJUCwg dW5sZXNzIHRoZXJlIGlzIGFuIGV4cGxpY2l0IGF1dGhvcml6YXRpb24gZ2l2ZW4gYnkgdGhlDQot ICAgcmVjaXBpZW50IG9mIFJFRkVSLiAgVGhpcyBjb3VsZCBiZSBhIHdhcm5pbmcgcHJvdmlkZWQg dG8gdGhlIHVzZXIuDQorICAgcmVjaXBpZW50IG9mIHRoZSBSRUZFUi4gIFRoaXMgY291bGQgYmUg YSB3YXJuaW5nIHByb3ZpZGVkIHRvIHRoZSB1c2VyLg0KICAgIEhhdmluZyBzdWNoIGEgd2Fybmlu ZyBjb3VsZCBiZSB1c2VmdWwgZm9yIGV4YW1wbGUgZm9yIGEgc2VjdXJlDQogICAgZGlyZWN0b3J5 IHNlcnZpY2UgYXBwbGljYXRpb24sIHJlc3VsdGluZyBpbiBiZWluZyByb3V0ZWQgdG8gYSBVQSB0 aGF0DQogICAgZG9lcyBub3Qgc3VwcG9ydCBTSVBTLiAgSWYgdGhlIHByb3BlciB0cmVhdG1lbnQg aXMgdG8gcmVqZWN0IHRoZQ0KQEAgLTg2Myw2ICs4NjQsOSBAQA0KICAgIHdpdGggdmVyeSBzaW1w bGUgcGhvbmVzLCBpdCBjb3VsZCBiZSByZWplY3RlZCB3aXRoIGVycm9yIHJlc3BvbnNlIDQwNA0K ICAgIChOb3QgRm91bmQpLg0KIA0KK0kgZG9uJ3QgcmVhbGx5IHNlZSB0aGUgcmVhc29uaW5nIGJl aGluZCB3aGVuIDQwMyBpcyBzZW50IGFuZCB3aGVuIDQwNA0KK2lzIHNlbnQuDQorDQogICAgTm90 ZSB0aGF0IGEgUkVGRVIgbWF5IGFsc28gYmUgdXNlZCBmb3IgcmVmZXJyaW5nIHRvIHJlc291cmNl cyB0aGF0IGRvDQogICAgbm90IHJlc3VsdCBpbiBkaWFsb2dzIGJlaW5nIGNyZWF0ZWQuICBJbiBm YWN0LCBhIFJFRkVSIG1heSBiZSB1c2VkIHRvDQogICAgcG9pbnQgdG8gcmVzb3VyY2VzIHRoYXQg YXJlIG9mIGEgZGlmZmVyZW50IHR5cGUgdGhhbiB0aGUgb3JpZ2luYWwgb25lDQpAQCAtODcwLDEy ICs4NzQsMTIgQEANCiAgICBjb25zaWRlcmF0aW9ucyByZWxhdGVkIHRvIHRoaXMuDQogDQogICAg T3RoZXIgZXhhbXBsZXMgb2YgZGVyaXZlZCBkaWFsb2dzIGFuZCB0cmFuc2FjdGlvbnMgaW5jbHVk ZSB0aGUgdXNlIG9mDQotICAgVGhpcmQtUGFydHkgQ2FsbCBDb250cm9sIFtSRkMzNzI1XSwgdGhl IFJlcGxhY2VzIGhlYWRlciBbUkZDMzg5MV0sDQorICAgVGhpcmQtUGFydHkgQ2FsbCBDb250cm9s IFtSRkMzNzI1XSwgdGhlIFJlcGxhY2VzIGhlYWRlciBbUkZDMzg5MV0sIGFuZA0KICAgIHRoZSBK b2luIGhlYWRlciBbUkZDMzkxMV0uICBBZ2FpbiwgdGhlIGdlbmVyYWwgcHJpbmNpcGxlIGlzIHRo YXQNCiAgICB0aGVzZSBtZWNoYW5pc20gU0hPVUxEIE5PVCByZXN1bHQgaW4gYW4gZWZmZWN0aXZl IGRvd25ncmFkaW5nIG9mIFNJUFMNCiAgICB0byBTSVAsIHdpdGhvdXQgdGhlIHByb3BlciBhdXRo b3JpemF0aW9uLg0KIA0KLTQuMS41LiAgVXNhZ2Ugb2YgdGxzIHRyYW5zcG9ydCBwYXJhbWV0ZXIN Cis0LjEuNS4gIFVzYWdlIG9mIHRoZSB0cmFuc3BvcnQ9dGxzIHBhcmFtZXRlcg0KIA0KICAgIFRo ZSAidHJhbnNwb3J0PXRscyIgcGFyYW1ldGVyIE1VU1QgTk9UIGJlIHVzZWQgYnkgVUFzLiAgSG93 ZXZlciwgZm9yDQogICAgYmFja3dhcmQgY29tcGF0aWJpbGl0eSwgaWYgYSAidHJhbnNwb3J0PXRs cyIgcGFyYW1ldGVyIGlzIHJlY2VpdmVkIGJ5DQpAQCAtODk4LDE4ICs5MDIsMTggQEANCiANCiAg ICAgICBOT1QgYmUgdXNlZCBpbiBSb3V0ZSwgUmVjb3JkLVJvdXRlIG9yIFBhdGggaGVhZGVycywg YW5kIE1VU1QgYmUNCiAgICAgICBpZ25vcmVkLg0KLSAgIG8gIEluIGEgY29udGFjdCBoZWFkZXIg ZmllbGQgaW4gYSBkaWFsb2csIGl0IGNvdWxkIGJlIGludGVycHJldGVkIGFzDQorICAgbyAgSW4g YSBDb250YWN0IGhlYWRlciBmaWVsZCBpbiBhIGRpYWxvZywgaXQgY291bGQgYmUgaW50ZXJwcmV0 ZWQgYXMNCiAgICAgICBhIHJlcXVlc3QgdG8gc2VuZCBpbmNvbWluZyBtaWQtZGlhbG9nIHJlcXVl c3RzIHVzaW5nIFRMUy4gIE5vdGUNCiAgICAgICB0aGF0IHRoaXMgd291bGQgb25seSBoYXZlIGEg c2lnbmlmaWNhbmNlIGlmDQogICAgICAgW0ktRC5pZXRmLXNpcC1vdXRib3VuZF0gYW5kIFJlY29y ZC1Sb3V0ZSBhcmUgbm90IHVzZWQsIGFuZCBpZiB0aGF0DQogICAgICAgVVJJIGlzIG5ldmVydGhl bGVzcyByZWFjaGFibGUgd2l0aCBUTFMgd2hpY2ggaXMgZXh0cmVtZWx5DQogICAgICAgdW5saWtl bHkuICBJZiBpdCB3YXMgdGhlIGNhc2UgdGhhdCBpdCB3YXMgcmVhY2hhYmxlIHdpdGggVExTLCBz YXkNCiAgICAgICBiZWNhdXNlIHRoZXJlIGlzIGFuIGFjdGl2ZSBUTFMgY29ubmVjdGlvbiwgdGhl biB0aGF0IGNvbm5lY3Rpb24NCi0gICAgICBjb3VsZCBiZSByZS11c2VkIGFueXdheXMsIHJlZ2Fy ZGxlc3Mgb2YgdGhlIHByZXNlbmNlIG9mIHRoZQ0KKyAgICAgIGNvdWxkIGJlIHJlLXVzZWQgYW55 d2F5LCByZWdhcmRsZXNzIG9mIHRoZSBwcmVzZW5jZSBvZiB0aGUNCiAgICAgICB0cmFuc3BvcnQg cGFyYW1ldGVyLiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgInRyYW5zcG9ydD10bHMiDQog ICAgICAgcGFyYW1ldGVyIGluIGEgQ29udGFjdCBoZWFkZXIgZmllbGQgaW4gYSBkaWFsb2cgYmUg aWdub3JlZCBieSB0aGUNCiAgICAgICBVQVMuDQotICAgbyAgSW4gYSBjb250YWN0IGhlYWRlciBm aWVsZCBpbiBhIFJFR0lTVEVSLCBpdCB0ZWxscyB0aGUgcmVnaXN0cmFyDQorICAgbyAgSW4gYSBD b250YWN0IGhlYWRlciBmaWVsZCBpbiBhIFJFR0lTVEVSLCBpdCB0ZWxscyB0aGUgcmVnaXN0cmFy DQogICAgICAgdGhhdCB0aGUgVUFDIGlzIHJlYWNoYWJsZSB0aHJvdWdoIFRMUy4gIElmIHRoZSBy ZWdpc3RyYXIgYW5kIHByb3h5DQogICAgICAgYXJlIGNvLWxvY2F0ZWQsIGFuZCBhcmUgdGhlIHBy b3h5IG9mIHRoYXQgVUFDLCBpdCB0ZWxscyB3aGF0IGlzDQogICAgICAgYWxyZWFkeSBrbm93biBi ZWNhdXNlIHRoZSByZXF1ZXN0IHdhcyBzZW50IG92ZXIgVExTIChpLmUuLCB0aGF0IGl0DQpAQCAt OTIxLDcgKzkyNSw3IEBADQogICAgbyAgSW4gYSBSZXF1ZXN0LVVSSSwgdGhlIHRyYW5zcG9ydCBw YXJhbWV0ZXIgaXMgcHJvYmxlbWF0aWMuICBPbiB0aGUNCiAgICAgICBsYXN0IGhvcCwgaXQgaXMg dXNlbGVzcyBiZWNhdXNlIHRoZSB0cmFuc3BvcnQgaXMgZXZpZGVudC4gIEEgVUFTDQogICAgICAg TVVTVCBpZ25vcmUgdGhlICJ0cmFuc3BvcnQ9dGxzIiBwYXJhbWV0ZXIgaW4gYSBSZXF1ZXN0LVVS SS4NCi0gICBvICBJbiBhIGNvbnRhY3QgaGVhZGVyIGZpZWxkIGluIGEgM1hYIHJlc3BvbnNlLCBp dCB3b3VsZCBlc3NlbnRpYWxseQ0KKyAgIG8gIEluIGEgQ29udGFjdCBoZWFkZXIgZmllbGQgaW4g YSAzWFggcmVzcG9uc2UsIGl0IHdvdWxkIGVzc2VudGlhbGx5DQogICAgICAgbWVhbiBhIHJlcXVl c3QgdG8gYXR0ZW1wdCB0byByZS1zZW5kIHRoZSByZXF1ZXN0LCB1c2luZyBUTFMNCiAgICAgICB0 cmFuc3BvcnQuICBTaW5jZSB0aGUgdHJhbnNwb3J0PXRscyBwYXJhbWV0ZXIgb25seSBoYXMgbG9j YWwNCiAgICAgICBzaWduaWZpY2FuY2UsIGl0IHdpbGwgb25seSBiZSBzdWNjZXNzZnVsIGlmIHRo ZSAzWFggaXMgcmVjdXJzZWQgYnkNCkBAIC05MzQsNyArOTM4LDcgQEANCiAgICBwYWlyLCBib3Ro IFNJUCBhbmQgU0lQUyBHUlVVcyB3aWxsIGJlIGFzc2lnbmVkLiAgV2hlbiBhIEdSVVUgaXMNCiAg ICBvYnRhaW5lZCB0aHJvdWdoIHJlZ2lzdHJhdGlvbiwgaWYgdGhlIENvbnRhY3QgaGVhZGVyIGlu IHRoZSBSRUdJU1RFUg0KICAgIHJlcXVlc3QgY29udGFpbnMgYSBTSVAgVVJJLCB0aGUgU0lQIHZl cnNpb24gb2YgdGhlIEdSVVUgaXMgcmV0dXJuZWQuDQotICAgSWYgdGhlIENvbnRhY3QgaGVhZGVy IGZpbGVkIGluIHRoZSBSRUdJU1RFUiByZXF1ZXN0IGNvbnRhaW5zIGEgU0lQUw0KKyAgIElmIHRo ZSBDb250YWN0IGhlYWRlciBmaWVsZCBpbiB0aGUgUkVHSVNURVIgcmVxdWVzdCBjb250YWlucyBh IFNJUFMNCiAgICBVUkksIHRoZSBTSVBTIHZlcnNpb24gb2YgdGhlIEdSVVUgaXMgcmV0dXJuZWQu DQogDQogICAgSWYgdGhlIHdyb25nIHNjaGVtZSBpcyByZWNlaXZlZCBpbiB0aGUgR1JVVSAod2hp Y2ggd291bGQgYmUgYW4gZXJyb3INCkBAIC05NjAsMTIgKzk2NCwxMiBAQA0KICAgIFVSSSwgdGhl IHByb3h5IE1VU1QgZm9yd2FyZCBvciByZXRhcmdldCB0aGUgcmVxdWVzdCB0byBhIFNJUFMNCiAg ICBSZXF1ZXN0LVVSSS4gIElmIHRoZSB0YXJnZXQgVUFTIGhhZCByZWdpc3RlcmVkIHByZXZpb3Vz bHkgdXNpbmcgYSBTSVANCiAgICBDb250YWN0IGhlYWRlciBmaWVsZCBpbnN0ZWFkIG9mIGEgU0lQ UyBDb250YWN0IGhlYWRlciBmaWVsZCwgdGhlDQotICAgcHJveHkgTVVTVCBOT1QgZm9yd2FyZCB0 aGUgcmVxdWVzdCB0byB0aGUgVVJJIGluZGljYXRlZCBpbiB0aGUgU0lQUw0KKyAgIHByb3h5IE1V U1QgTk9UIGZvcndhcmQgdGhlIHJlcXVlc3QgdG8gdGhlIFVSSSBpbmRpY2F0ZWQgaW4gdGhlIFNJ UCg/KQ0KICAgIENvbnRhY3QgaGVhZGVyIGZpZWxkLiAgSWYgdGhlIHByb3h5IG5lZWRzIHRvIHJl amVjdCB0aGUgcmVxdWVzdCBmb3INCiAgICB0aGF0IHJlYXNvbiwgaXQgTVVTVCByZWplY3QgaXQg d2l0aCBhIDQwNCAoTm90IEZvdW5kKS4NCiANCiAgICBQcm94aWVzIFNIT1VMRCB0cmFuc3BvcnQg cmVxdWVzdHMgdXNpbmcgYSBTSVAgVVJJIG92ZXIgVExTIHdoZW4gaXQgaXMNCi0gICBwb3NzaWJs ZSB0byBzZXQtdXAgYSBUTFMgY29ubmVjdGlvbiwgb3IgcmUtdXNlIGFuIGV4aXN0aW5nIG9uZS4N CisgICBwb3NzaWJsZSB0byBzZXQgdXAgYSBUTFMgY29ubmVjdGlvbiwgb3IgcmUtdXNlIGFuIGV4 aXN0aW5nIG9uZS4NCiAgICBbSS1ELmlldGYtc2lwLW91dGJvdW5kXSBmb3IgZXhhbXBsZSwgYWxs b3dzIGZvciByZS11c2luZyBhbiBleGlzdGluZw0KICAgIFRMUyBjb25uZWN0aW9uLiAgU29tZSBw cm94aWVzIE1BWSBoYXZlIHBvbGljaWVzIHRoYXQgcHJvaGliaXRzDQogICAgc2VuZGluZyBhbnkg cmVxdWVzdCBvdmVyIGFueXRoaW5nIGJ1dCBUTFMuDQpAQCAtOTc0LDggKzk3OCw4IEBADQogICAg TVVTVCBOT1QgZm9yd2FyZCB0aGUgcmVxdWVzdCB0byBhIFNJUFMgUmVxdWVzdC1VUkkuICBJZiB0 aGUgdGFyZ2V0DQogICAgVUFTIGhhZCByZWdpc3RlcmVkIHByZXZpb3VzbHkgdXNpbmcgYSBTSVBT IENvbnRhY3QgaGVhZGVyIGZpZWxkLCBhbmQNCiAgICB0aGUgcHJveHkgZGVjaWRlcyB0byBmb3J3 YXJkIHRoZSByZXF1ZXN0LCBpdCBNVVNUIHN1YnN0aXR1dGUgdGhlIFNJUA0KLSAgIHNjaGVtZSB0 byB0aGUgU0lQUyBzY2hlbWUgb2YgdGhlIFVSSSBmb3VuZCBpbiB0aGUgcmVnaXN0ZXJlZCBDb250 YWN0DQotICAgaGVhZGVyIGZpZWxkIGJpbmRpbmcgYW5kIHVzZSBpdCBpbiB0aGUgUmVxdWVzdC1V Ukkgb2YgdGhlIGZvcndhcmRlZA0KKyAgIHNjaGVtZSBmb3IgdGhlIFNJUFMgc2NoZW1lIG9mIHRo ZSBVUkkgZm91bmQgaW4gdGhlIHJlZ2lzdGVyZWQgQ29udGFjdA0KKyAgIGhlYWRlciBmaWVsZCBi aW5kaW5nIGFuZCB1c2UgdGhlIHJlc3VsdGluZyBVUkkgaW4gdGhlIFJlcXVlc3QtVVJJIG9mIHRo ZSBmb3J3YXJkZWQNCiAgICByZXF1ZXN0LCBhbmQgdGhvc2UgcHJveGllcyBNVVNUIHVzZSBUTFMg dG8gZm9yd2FyZCB0aGUgcmVxdWVzdCB0byB0aGUNCiAgICBVQVMuICBTb21lIHByb3hpZXMgTUFZ IGhhdmUgYSBwb2xpY3kgb2Ygbm90IGZvcndhcmRpbmcgYXQgYWxsDQogICAgcmVxdWVzdHMgdXNp bmcgYSBub24tU0lQUyBSZXF1ZXN0LVVSSSBpZiB0aGUgVUFTIGhhZCByZWdpc3RlZCB1c2luZyBh DQpAQCAtOTk5LDYgKzEwMDMsOCBAQA0KICAgIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIG5vbi1j b21wbGlhbnQgcHJvY2VkdXJlcyB0byBoYW5kbGUgbGVnYWN5DQogICAgaW1wbGVtZW50YXRpb25z Lg0KIA0KK0hvdyB3b3VsZCB1c2luZyBhIFByb3h5LVJlcXVpcmUgaGVhZGVyIGRldGVjdCBhIG5v bi1jb25mb3JtaW5nIFVBPw0KKw0KICAgIEl0IGlzIFJFQ09NTUVOREVEIHRvIHVzZSBhbiBvdXRi b3VuZCBwcm94eSBhcyBwZXIgdGhlIHByb2NlZHVyZXMNCiANCiANCkBAIC0xMDI1LDcgKzEwMzEs NyBAQA0KICAgIDNYWCByZXNwb25zZSB3aXRoIGEgU0lQUyBDb250YWN0IGhlYWRlciBmaWVsZCwg aXQgTVVTVCBOT1QgcmVjdXJzZSBvbg0KICAgIHRoZSBDb250YWN0IGhlYWRlciBmaWVsZC4gIFRo ZSBQcm94eSBTSE9VTEQgZm9yd2FyZCB0aGUgM1hYIHRvIHRoZQ0KICAgIFVBQyBpbnN0ZWFkIG9m IHJlY3Vyc2luZywgaW4gb3JkZXIgdG8gYWxsb3cgZm9yIHRoZSBVQUMgdG8gdGFrZSB0aGUNCi0g ICBhcHByb3ByaWF0ZSBhY3Rpb24uICBUaGUgcHJveHkgTUFZIGluc3RlYWQgbWFwIHRoZSByZXF1 ZXN0IHdpdGggYSA0MTYNCisgICBhcHByb3ByaWF0ZSBhY3Rpb24uICBUaGUgcHJveHkgTUFZIGlu c3RlYWQgcmVzcG9uZCB0byB0aGUgcmVxdWVzdCB3aXRoIGEgNDE2DQogICAgKFVuc3VwcG9ydGVk IFVSSSBTY2hlbWUpIGlmIGl0IGlzIG5vdCBpdHMgcG9saWN5IHRvIGFsbG93IHJlZGlyZWN0aW9u DQogICAgdG8gYmUgZG9uZSBieSB0aGUgVUEuDQogDQpAQCAtMTA0MSwxMyArMTA0NywxMyBAQA0K IA0KIDQuMy4gIFJlZGlyZWN0IFNlcnZlciBCZWhhdmlvcg0KIA0KLSAgIFVzaW5nIGEgUmVkaXJl Y3QgU2VydmVyIGluc3RlYWQgb2YgYSBQcm94eSwgd2l0aCBUTFMgaGFzIHNvbWUNCi0gICBsaW1p dGF0aW9ucyB0aGF0IGhhcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQuICBTaW5jZSB0aGVyZSBu byBwcmUtDQorICAgVXNpbmcgYSBSZWRpcmVjdCBTZXJ2ZXIgd2l0aCBUTFMgaW5zdGVhZCBvZiBh IFByb3h5IGhhcyBzb21lDQorICAgbGltaXRhdGlvbnMgdGhhdCBoYXZlIHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudC4gIFNpbmNlIHRoZXJlIGlzIG5vIHByZS0NCiAgICBlc3RhYmxpc2hlZCBjb25u ZWN0aW9uIChzdWNoIGFzIHdpdGggW0ktRC5pZXRmLXNpcC1vdXRib3VuZF0pIGJldHdlZW4NCiAg ICB0aGUgUHJveHkgYW5kIHRoZSBVQVMsIGl0IGlzIG9ubHkgYXBwcm9wcmlhdGUgZm9yIHNjZW5h cmlvcyB3aGVyZQ0KICAgIGluYm91bmQgY29ubmVjdGlvbnMgYXJlIGFsbG93ZWQuICBGb3IgZXhh bXBsZSwgaXQgY291bGQgYmUgdXNlZCBpbiBhDQogICAgc2VydmVyIHRvIHNlcnZlciBlbnZpcm9u bWVudCAocmVkaXJlY3Qgc2VydmVyIG9yIHByb3h5IHNlcnZlcikgd2hlcmUNCi0gICBtdXR1YWwg VExTIGlzIHVzZWQsIGFuZCB3aGVyZSB0aGVyZSBpcyBubyBOQVQgdHJhdmVyc2FsIGlzc3Vlcy4g IEENCisgICBtdXR1YWwgVExTIGlzIHVzZWQsIGFuZCB3aGVyZSB0aGVyZSBhcmUgbm8gTkFUIHRy YXZlcnNhbCBpc3N1ZXMuICBBDQogICAgcmVkaXJlY3Qgc2VydmVyIHdvdWxkIG5vdCBiZSB1c2Fi bGUgaWYgc2VydmVyLXNpZGUgYXV0aGVudGljYXRpb24gaXMNCiAgICB1c2VkIG9yIGlmIHRoZXJl IGlzIGEgTkFUIGJldHdlZW4gdGhlIHNlcnZlciBhbmQgdGhlIFVBUy4NCiANCkBAIC0xMDc2LDcg KzEwODIsMTAgQEANCiAgICBwcmV2aW91c2x5IHVzaW5nIGEgU0lQUyBDb250YWN0IGhlYWRlciBm aWVsZCwgdGhlIHJlZGlyZWN0IHNlcnZlcg0KICAgIFNIT1VMRCByZXR1cm4gYSBTSVBTIENvbnRh Y3QgaGVhZGVyIGZpZWxkIHRvICJ1cGdyYWRlIiB0byBTSVBTIGlmIGl0DQogICAgaXMgaW4gYW4g ZW52aXJvbm1lbnQgd2hlcmUgVExTIGlzIHVzYWJsZSAoYXMgZGVzY3JpYmVkIGluIHRoZQ0KLSAg IHByZXZpb3VzIHBhcmFncmFwaCkuICBJZiB0aGUgdGFyZ2V0IFVBUyBoYWQgcmVnaXN0ZXJlZCBw cmV2aW91c2x5DQorICAgcHJldmlvdXMgcGFyYWdyYXBoKS4gIA0KK1RoaXMgaXMgbm90IGFuIHVw Z3JhZGU7IGJvdGggdGhlIHJlcXVlc3QgYW5kIHRoZSByZWdpc3RyYXRpb24gYXJlIFNJUFMNCith bHJlYWR5LiANCisgICBJZiB0aGUgdGFyZ2V0IFVBUyBoYWQgcmVnaXN0ZXJlZCBwcmV2aW91c2x5 DQogICAgdXNpbmcgYSBTSVAgQ29udGFjdCBoZWFkZXIgZmllbGQsIHRoZSByZWRpcmVjdCBzZXJ2 ZXIgTVVTVCByZXR1cm4gYQ0KICAgIFNJUCBDb250YWN0IGhlYWRlciBmaWVsZCBpbiBhIDNYWCBy ZXNwb25zZSBpZiBpdCBjaG9vc2VzIHRvIHJlZGlyZWN0Ow0KICAgIG90aGVyd2lzZSBpdCBtYXkg cmVqZWN0IHRoZSByZXF1ZXN0IHdpdGggYSA0MTYgKFVuc3VwcG9ydGVkIFVSSQ0KQEAgLTExMDYs NyArMTExNSw3IEBADQogICAgICAgICAgICAgICAgIHxfX19fX198ICAgICAgICBPIC8gXCBPICAg ICAgICAgICAgTyAvIFwgTw0KICAgICAgICAgICAgICAgIC9fX19fX19fLyAgICAgICAgIC9fX19c ICAgICAgICAgICAgICAvX19fXA0KIA0KLSAgICAgICAgICAgICAgIGJvYkBib2JwcGMgICAgIGJv YkBib2JwaG9uZSAgICAgICAgICBBbGljZQ0KKyAgICAgICAgICAgICAgIGJvYkBib2JwYyAgICAg IGJvYkBib2JwaG9uZSAgICAgICAgICBBbGljZQ0KIA0KIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFRvcG9sb2d5DQpAQCAtMTEyMiwxNSArMTEzMSwxNSBAQA0KIA0KICAgIGNs aWVudCBydW5uaW5nIG9uIGhpcyBjb21wdXRlciwgYW5kIHRoZSBvdGhlciBvbmUgaXMgYSBTSVAg UGhvbmUuDQogICAgVGhlIFBDIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IFNJUFMgYW5kIGNvbnNl cXVlbnRseSBvbmx5IHJlZ2lzdGVycw0KLSAgIHdpdGggYSBTSVAgY29udGFjdCBoZWFkZXIgZmll bGQuICBUaGUgU0lQIHBob25lIGhvd2V2ZXIgZG9lcyBzdXBwb3J0DQotICAgU0lQUyBhbmQgVExT LCBhbmQgY29uc2VxdWVudGx5IHJlZ2lzdGVycyB3aXRoIGEgU0lQUyBjb250YWN0IGhlYWRlcg0K KyAgIHdpdGggYSBTSVAgQ29udGFjdCBoZWFkZXIgZmllbGQuICBUaGUgU0lQIHBob25lIGhvd2V2 ZXIgZG9lcyBzdXBwb3J0DQorICAgU0lQUyBhbmQgVExTLCBhbmQgY29uc2VxdWVudGx5IHJlZ2lz dGVycyB3aXRoIGEgU0lQUyBDb250YWN0IGhlYWRlcg0KICAgIGZpZWxkLiAgQm90aCBvZiBCb2In cyBkZXZpY2VzIGFyZSBnb2luZyB0aHJvdWdoIE91dGJvdW5kIFByb3h5IEIsIGFuZA0KICAgIGNv bnNlcXVlbnRseSwgdGhleSBpbmNsdWRlIGEgUm91dGUgaGVhZGVyIGluZGljYXRpbmcgUHJveHkg Qi4gUHJveHkgQg0KICAgIHJlbW92ZXMgdGhlIFJvdXRlIGhlYWRlciBjb3JyZXNwb25kaW5nIHRv IGl0c2VsZiwgYW5kIGFkZHMgaXRzZWxmIGluDQogICAgYSBQYXRoIGhlYWRlci4gIFRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBjYWxsIGZsb3cgaXMgaWxsdXN0cmF0ZWQgaW4NCiAgICBTZWN0aW9u IDUuMS4NCiANCi0gICBBZnRlciByZWdpc3RyYXRpb24sIHRoZXJlIGFyZSAyIGNvbnRhY3QgYmlu ZGluZ3MgYXNzb2NpYXRlZCB3aXRoDQorICAgQWZ0ZXIgcmVnaXN0cmF0aW9uLCB0aGVyZSBhcmUg dHdvIENvbnRhY3QgYmluZGluZ3MgYXNzb2NpYXRlZCB3aXRoDQogICAgQm9iJ3MgQU9SIG9mIGJv YkBleGFtcGxlLmNvbTogc2lwczpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20gYW5kDQogICAgc2lw OmJvYkBib2JwYy5leGFtcGxlLmNvbS4NCiANCkBAIC0xMTQyLDEwICsxMTUxLDEwIEBADQogICAg aW4gdGhlIFJlY29yZC1Sb3V0ZSBhbmQgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8gT3V0Ym91bmQg UHJveHkgQi4NCiANCiAgICBUaGUgZm9sbG93aW5nIHN1YnNlY3Rpb25zIGlsbHVzdHJhdGVzIHJl Z2lzdHJhdGlvbiBhbmQgdGhyZWUNCi0gICBleGFtcGxlcy4gIEluIHRoZSBmaXJzdCBleGFtcGxl IChTZWN0aW9uIDUuMiksIEFsaWNlIGNhbGxzIEJvYiB1c2luZw0KLSAgIEJvYidzIFNJUFMgVVJJ LiAgSW4gdGhlIHNlY29uZCBleGFtcGxlIChTZWN0aW9uIDUuMyksIEFsaWNlIGNhbGxzDQorICAg ZXhhbXBsZXMuICBJbiB0aGUgZmlyc3QgZXhhbXBsZSAoc2VjdGlvbiA1LjIpLCBBbGljZSBjYWxs cyBCb2IgdXNpbmcNCisgICBCb2IncyBTSVBTIFVSSS4gIEluIHRoZSBzZWNvbmQgZXhhbXBsZSAo c2VjdGlvbiA1LjMpLCBBbGljZSBjYWxscw0KICAgIEJvYidzIFNJUCBBT1IgdXNpbmcgVENQIHRy YW5zcG9ydC4gIEluIHRoZSB0aGlyZCBleGFtcGxlDQotICAgKFNlY3Rpb24gNS40KSwgQWxpY2Ug Y2FsbHMgQm9iJ3MgU0lQIEFPUiB1c2luZyBUTFMgdHJhbnNwb3J0Lg0KKyAgIChzZWN0aW9uIDUu NCksIEFsaWNlIGNhbGxzIEJvYidzIFNJUCBBT1IgdXNpbmcgVExTIHRyYW5zcG9ydC4NCiANCiA1 LjEuICBCb2IgUmVnaXN0ZXJzIEhpcyBDb250YWN0cw0KIA0KQEAgLTExODQsNyArMTE5Myw3IEBA DQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0+ fA0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAyMDAgRjMgICAg IHwNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgMjAwIEY0ICAgICAgIHw8LS0tLS0tLS0tLS0t LS18DQotICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAg ICAgfA0KKyAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tfCAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgfCAgIEJvYkBib2JwaG9uZSAgICB8ICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgIHwgICAgICB8ICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwNCkBAIC0xMTkzLDcgKzEyMDIsNyBAQA0KICAgICAgICAgICAgICAgICAgIHwgICAg ICB8ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICB8ICAg ICAgfCAgICAgICAgICAgIHwgICAgMjAwIEY3ICAgICB8DQogICAgICAgICAgICAgICAgICAgfCAg ICAgIHwgICAyMDAgRjggICB8PC0tLS0tLS0tLS0tLS0tfA0KLSAgICAgICAgICAgICAgICAgIHwg ICAgICB8LS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICB8 ICAgICAgfDwtLS0tLS0tLS0tLXwgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAg fCAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0KIA0KIA0KQEAgLTE0MTksMTQg KzE0MjgsMTQgQEANCiANCiA1LjIuICBBbGljZSBDYWxscyBCb2IncyBTSVBTIEFPUg0KIA0KLSAg IEJvYidzIHJlZ2lzdHJhdGlvbiBoYXMgYWxyZWFkeSBvY2N1cnJlZCBhcyBwZXIgU2VjdGlvbiA1 LjEuDQorICAgQm9iJ3MgcmVnaXN0cmF0aW9uIGhhcyBhbHJlYWR5IG9jY3VycmVkIGFzIHBlciBz ZWN0aW9uIDUuMS4NCiANCiAgICBJbiB0aGlzIGZpcnN0IGV4YW1wbGUsIEFsaWNlIGNhbGxzIEJv YidzIFNJUFMgQU9SDQogICAgKHNpcHM6Ym9iQGV4YW1wbGUuY29tKS4gIFByb3h5IEIgY29uc3Vs dHMgdGhlIGJpbmRpbmcgaW4gdGhlDQotICAgcmVnaXN0cmF0aW9uIGRhdGFiYXNlLCBhbmQgZmlu ZHMgdGhlIDIgY29udGFjdCBoZWFkZXIgZmllbGQgYmluZGluZ3MuDQorICAgcmVnaXN0cmF0aW9u IGRhdGFiYXNlLCBhbmQgZmluZHMgdGhlIHR3byBDb250YWN0IGhlYWRlciBmaWVsZCBiaW5kaW5n cy4NCiAgICBBbGljZSBoYWQgYWRkcmVzc2VkIEJvYiB3aXRoIGEgU0lQUyBSZXF1ZXN0LVVSSQ0K ICAgIChzaXBzOmJvYkBleGFtcGxlLmNvbSksIHNvIFByb3h5IEIgZGV0ZXJtaW5lcyB0aGF0IHRo ZSBjYWxscyBuZWVkcyB0bw0KLSAgIGJlIHJvdXRlZCBvbmx5IHRvIGEgU0lQUyBjb250YWN0IGhl YWRlciBmaWVsZCwgYW5kIHRoZXJlZm9yZSB0aGUNCisgICBiZSByb3V0ZWQgb25seSB0byBhIFNJ UFMgQ29udGFjdCBoZWFkZXIgZmllbGQsIGFuZCB0aGVyZWZvcmUgdGhlDQogICAgcmVxdWVzdCBp cyBvbmx5IHNlbnQgdG8gc2lwczpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20uICBQcm94eSBCDQog ICAgaW5zZXJ0cyBpdHNlbGYgaW4gdGhlIFJlY29yZC1Sb3V0ZS4gIEJvYiBhbnN3ZXJzIGF0DQog ICAgc2lwczpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20uDQpAQCAtMTcyMywxMSArMTczMiwxMSBA QA0KIA0KIDUuMy4gIEFsaWNlIENhbGxzIEJvYidzIFNJUCBBT1IgdXNpbmcgVENQDQogDQotICAg Qm9iJ3MgcmVnaXN0cmF0aW9uIGhhcyBhbHJlYWR5IG9jY3VycmVkIGFzIHBlciBTZWN0aW9uIDUu MS4NCisgICBCb2IncyByZWdpc3RyYXRpb24gaGFzIGFscmVhZHkgb2NjdXJyZWQgYXMgcGVyIHNl Y3Rpb24gNS4xLg0KIA0KICAgIEluIHRoZSBzZWNvbmQgZXhhbXBsZSwgQWxpY2UgY2FsbHMgQm9i J3MgU0lQIEFPUiBpbnN0ZWFkDQogICAgKHNpcDpib2JAZXhhbXBsZS5jb20pLCBhbmQgc2hlIHVz ZXMgVENQIGFzIGEgdHJhbnNwb3J0LiAgUHJveHkgQg0KLSAgIGNvbnN1bHRzIHRoZSBiaW5kaW5n IGluIHRoZSByZWdpc3RyYXRpb24gZGF0YWJhc2UsIGFuZCBmaW5kcyB0aGUgMg0KKyAgIGNvbnN1 bHRzIHRoZSBiaW5kaW5nIGluIHRoZSByZWdpc3RyYXRpb24gZGF0YWJhc2UsIGFuZCBmaW5kcyB0 aGUgdHdvDQogDQogDQogDQpAQCAtMTczNiwxMiArMTc0NSwxMiBAQA0KIEludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBTSVBTICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAw Nw0KIA0KIA0KLSAgIGNvbnRhY3QgaGVhZGVyIGZpZWxkIGJpbmRpbmdzLiAgQWxpY2UgaGFkIGFk ZHJlc3NlZCBCb2Igd2l0aCBhIFNJUA0KKyAgIENvbnRhY3QgaGVhZGVyIGZpZWxkIGJpbmRpbmdz LiAgQWxpY2UgaGFkIGFkZHJlc3NlZCBCb2Igd2l0aCBhIFNJUA0KICAgIFJlcXVlc3QtVVJJIChz aXA6Ym9iQGV4YW1wbGUuY29tKSwgc28gUHJveHkgQiBkZXRlcm1pbmVzIHRoYXQgdGhlDQotICAg Y2FsbHMgbmVlZHMgdG8gYmUgcm91dGVkIGJvdGggdG8gdGhlIFNJUCBjb250YWN0IGhlYWRlciBm aWVsZCBhbmQgdGhlDQotICAgU0lQUyBjb250YWN0IGhlYWRlciBmaWVsZCwgYW5kIHRoZXJlZm9y ZSB0aGUgcmVxdWVzdCBpcyBmb3JrZWQgc2VudA0KLSAgIHRvIHNpcDpib2JAYm9wcGMuZXhhbXBs ZS5jb20gYW5kIHNpcDpib2JAYm9icGhvbmUuZXhhbXBsZS5jb20uICBOb3RlDQotICAgdGhhdCB0 aGUgcHJveHkgc3Vic3RpdHV0ZWQgdGhlIFNJUCBzY2hlbWUgdG8gdGhlIFNJUFMgc2NoZW1lIGZv cg0KKyAgIGNhbGxzIG5lZWRzIHRvIGJlIHJvdXRlZCBib3RoIHRvIHRoZSBTSVAgQ29udGFjdCBo ZWFkZXIgZmllbGQgYW5kIHRoZQ0KKyAgIFNJUFMgQ29udGFjdCBoZWFkZXIgZmllbGQsIGFuZCB0 aGVyZWZvcmUgdGhlIHJlcXVlc3QgaXMgZm9ya2VkIGFuZCBzZW50DQorICAgdG8gc2lwOmJvYkBi b2JwYy5leGFtcGxlLmNvbSBhbmQgc2lwOmJvYkBib2JwaG9uZS5leGFtcGxlLmNvbS4gIE5vdGUN CisgICB0aGF0IHRoZSBwcm94eSBzdWJzdGl0dXRlZCB0aGUgU0lQIHNjaGVtZSBmb3IgdGhlIFNJ UFMgc2NoZW1lIGZvcg0KICAgIGJvYkBib2JwaG9uZS5leGFtcGxlLmNvbS4gIE91dGJvdW5kIFBy b3h5IEIgaW5zZXJ0cyBpdHNlbGYgaW4gdGhlDQogICAgUmVjb3JkLVJvdXRlLiAgQm9iJ3MgcGhv bmUncyBwb2xpY3kgaXMgdG8gYWNjZXB0IGNhbGxzIHRvIFNJUCBhbmQNCiAgICBTSVBTIChpLmUu LCAiYmVzdCBlZmZvcnQiKSBzbyBib3RoIGhpcyBQQyBDbGllbnQgYW5kIGhpcyBTSVAgUGhvbmUN CkBAIC0xODI3LDYgKzE4MzYsNyBAQA0KICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0+ fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwNCiANCitObyAxODAgZnJvbSBi b2JwaG9uZT8NCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgQWxpY2UgQ2FsbHMgQm9iJ3Mg U0lQIEFPUg0KIA0KQEAgLTIyNTQsNyArMjI2NCw3IEBADQogDQogNS40LiAgQWxpY2UgQ2FsbHMg Qm9iJ3MgU0lQIEFPUiB1c2luZyBUTFMNCiANCi0gICBCb2IncyByZWdpc3RyYXRpb24gaGFzIGFs cmVhZHkgb2NjdXJyZWQgYXMgcGVyIFNlY3Rpb24gNS4xLg0KKyAgIEJvYidzIHJlZ2lzdHJhdGlv biBoYXMgYWxyZWFkeSBvY2N1cnJlZCBhcyBwZXIgc2VjdGlvbiA1LjEuDQogDQogICAgVGhlIHRo aXJkIGV4YW1wbGUgaXMgaWRlbnRpY2FsIHRvIHRoZSBzZWNvbmQgb25lLCBleGNlcHQgdGhhdCBB bGljZQ0KICAgIHVzZXMgVExTIGFzIHRoZSB0cmFuc3BvcnQgZm9yIGhlciBjb25uZWN0aW9uIHRv IGhlciBvdXRib3VuZCBwcm94eS4NCkBAIC0yMjY3LDExICsyMjc3LDExIEBADQogICAgSXQgc2hv dWxkIGJlIG5vdGVkIHRoYXQgd2hlbiB1c2luZyBhIFNJUCBVUkkgaW4gdGhlIFJlcXVlc3QtVVJJ LCBidXQNCiAgICBUTFMgYXMgYSB0cmFuc3BvcnQgZm9yIHNlbmRpbmcgdGhlIHJlcXVlc3QsIHRo ZSBWaWEgZmllbGQgaW5kaWNhdGVzDQogICAgVExTLiAgVGhlIFJvdXRlIGhlYWRlciAoaWYgcHJl c2VudCkgdHlwaWNhbGx5IHdvdWxkIHVzZSBhIFNJUCBVUkkNCi0gICAoYnV0IGl0IGNvdWxkIGFs c28gYmUgYSBTSVBTIFVSSSkuICBUaGUgY29udGFjdCBoZWFkZXIgZmllbGRzLCBUbyBhbmQNCisg ICAoYnV0IGl0IGNvdWxkIGFsc28gYmUgYSBTSVBTIFVSSSkuICBUaGUgQ29udGFjdCBoZWFkZXIg ZmllbGRzLCBUbyBhbmQNCiAgICBGcm9tIGhvd2V2ZXIgd291bGQgYWxzbyBub3JtYWxseSBpbmRp Y2F0ZSBhIFNJUCBVUkkuDQogDQogICAgVGhlIGNhbGwgZmxvdyB3b3VsZCBiZSBleGFjdGx5IGFz IHBlciB0aGUgc2Vjb25kIGV4YW1wbGUNCi0gICAoU2VjdGlvbiA1LjMpLg0KKyAgIChzZWN0aW9u IDUuMykuDQogDQogICAgTWVzc2FnZXMgRjIwJy1GMjInIGFyZSBpZGVudGljYWwgdG8gdGhlIG9u ZXMgaW4gU2VjdGlvbiA1LjMuICBUaGUNCiAgICBvdGhlciBtZXNzYWdlcyBhcmUgYXMgZm9sbG93 cy4NCkBAIC0yNjUwLDE0ICsyNjYwLDE0IEBADQogDQogICAgU0lQIFtSRkMzMjYxXSBpdHNlbGYg aW50cm9kdWNlcyBzb21lIGNvbXBsaWNhdGlvbnMgd2l0aCB1c2luZyBTSVBTLA0KICAgIGZvciBl eGFtcGxlIHdoZW4gdXNpbmcgc3RyaWN0IHJvdXRpbmcgaW5zdGVhZCBvZiBsb29zZSByb3V0aW5n LiAgV2hlbg0KLSAgIGEgU0lQUyBVUkkgaXMgdXNlZCBpbiBhIGNvbnRhY3QgaGVhZGVyIGZpZWxk IGluIGEgZGlhbG9nIGluaXRpYXRpbmcNCisgICBhIFNJUFMgVVJJIGlzIHVzZWQgaW4gYSBDb250 YWN0IGhlYWRlciBmaWVsZCBpbiBhIGRpYWxvZy1pbml0aWF0aW5nDQogICAgcmVxdWVzdCBhbmQg UmVjb3JkLVJvdXRlIGlzIG5vdCB1c2VkLCB0aGF0IFNJUFMgVVJJIG1heSBub3QgYmUgdXNhYmxl DQogICAgYnkgdGhlIG90aGVyIGVuZC4gIElmIHRoZSBvdGhlciBlbmQgZG9lcyBub3Qgc3VwcG9y dCBTSVBTIGFuZC9vciBUTFMsDQogICAgaXQgd2lsbCBub3QgYmUgYWJsZSB0byB1c2UgaXQuICBU aGUgImxhc3QtaG9wIGV4Y2VwdGlvbiIgaXMgYW4NCiAgICBleGFtcGxlIG9mIHdoZW4gdGhpcyBt YXkgb2NjdXIuICBJbiB0aGlzIGNhc2UsIHVzaW5nIFJlY29yZC1Sb3V0ZSBzbw0KICAgIHRoYXQg dGhlIHJlcXVlc3RzIGFyZSBzZW50IHRocm91Z2ggcHJveGllcyBtYXkgaGVscCBpbiBtYWtpbmcg aXQNCiAgICB3b3JrLiAgQW5vdGhlciBleGFtcGxlIG9mIGlzc3VlcyB3aXRoIHN0cmljdCByb3V0 aW5nIGlzIHRoYXQgZXZlbiBpbg0KLSAgIGEgY2FzZSB3aGVyZSB0aGUgY29udGFjdCBoZWFkZXIg ZmllbGQgaXMgYSBTSVBTIFVSSSwgbm8gUmVjb3JkLVJvdXRlDQorICAgYSBjYXNlIHdoZXJlIHRo ZSBDb250YWN0IGhlYWRlciBmaWVsZCBpcyBhIFNJUFMgVVJJLCBubyBSZWNvcmQtUm91dGUNCiAg ICBpcyB1c2VkLCBhbmQgdGhlIGZhciBlbmQgc3VwcG9ydHMgU0lQUyBhbmQgVExTLCBpdCBtYXkg c3RpbGwgbm90IGJlDQogICAgcG9zc2libGUgZm9yIHRoZSBmYXIgZW5kIHRvIGVzdGFibGlzaCBh IFRMUyBjb25uZWN0aW9uIHdpdGggdGhlIFNJUA0KICAgIG9yaWdpbmF0aW5nIGVuZCBpZiB0aGUg Y2VydGlmaWNhdGUgY2FuIG5vdCBiZSB2YWxpZGF0ZWQgYnkgdGhlIGZhcg0KQEAgLTI2NjksOSAr MjY3OSw5IEBADQogICAgIlNlcnZlci1zaWRlIGF1dGhlbnRpY2F0aW9uIiAod2hlcmUgdGhlIHNl cnZlciBzaWRlIHByb3ZpZGVzIGl0cw0KICAgIGNlcnRpZmljYXRlIGJ1dCB0aGUgY2xpZW50IHNp ZGUgZG9lcyBub3QpIGlzIHR5cGljYWxseSB1c2VkIGJldHdlZW4gYQ0KICAgIFNJUCBlbmQtdXNl ciBkZXZpY2UgYWN0aW5nIGFzIHRoZSBUTFMgY2xpZW50IHNpZGUgKGUuZy4sIGEgcGhvbmUgb3Ig YQ0KLSAgIHBlcnNvbmFsIGNvbXB1dGVyKSwgYW5kIGl0J3MgU0lQIHNlcnZlciAocHJveHkgb3Ig cmVnaXN0cmFyKSBhY3RpbmcNCisgICBwZXJzb25hbCBjb21wdXRlciksIGFuZCBpdHMgU0lQIHNl cnZlciAocHJveHkgb3IgcmVnaXN0cmFyKSBhY3RpbmcNCiAgICBhcyB0aGUgVExTIHNlcnZlciBz aWRlLiAgIk11dHVhbCBUTFMiICh3aGVyZSBib3RoIHRoZSBjbGllbnQgYW5kIHRoZQ0KLSAgIHNl cnZlciBzaWRlIHByb3ZpZGUgdGhlaXIgcmVzcGVjdGl2ZSBjZXJ0aWZpY2F0ZSkgaXMgdHlwaWNh bGx5IHVzZWQNCisgICBzZXJ2ZXIgc2lkZSBwcm92aWRlIHRoZWlyIHJlc3BlY3RpdmUgY2VydGlm aWNhdGVzKSBpcyB0eXBpY2FsbHkgdXNlZA0KICAgIGJldHdlZW4gU0lQIHNlcnZlcnMgKHByb3hp ZXMsIHJlZ2lzdHJhcnMpLCBvciBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQNCiAgICBkZXZpY2VzIHN1 Y2ggYXMgUFNUTiBnYXRld2F5cyBvciBtZWRpYSBzZXJ2ZXJzLiAgSW4gdGhlIG11dHVhbCBUTFMN CiAgICBtb2RlbCwgZm9yIHR3byBlbnRpdGllcyB0byBiZSBhYmxlIHRvIGVzdGFibGlzaCBhIFRM UyBjb25uZWN0aW9uLCBpdA0KQEAgLTI2OTUsMTQgKzI3MDUsMTQgQEANCiAgICBbSS1ELmlldGYt c2lwLW91dGJvdW5kXSBpcyB0aGUgcmVjb21tZW5kZWQgYXBwcm9hY2guICBGb3IgbXV0dWFsIFRM UywNCiAgICBpdCBtZWFucyB0aGF0IG9uZSBzaG91bGQgYmUgdmVyeSBjYXJlZnVsIHRoYXQgdGhl IGFyY2hpdGVjdHVyZSBvZiB0aGUNCiAgICBuZXR3b3JrIGlzIHN1Y2ggdGhhdCBjb25uZWN0aW9u cyBhcmUgbWFkZSBiZXR3ZWVuIGVudGl0aWVzIHRoYXQgaGF2ZQ0KLSAgIGFjY2VzcyB0byBlYWNo IG90aGVyJ3MgY3JlZGVudGlhbC4gIFJlY29yZC1Sb3V0ZSBbUkZDMzI2MV0gYW5kIFBhdGgNCisg ICBhY2Nlc3MgdG8gZWFjaCBvdGhlcidzIGNyZWRlbnRpYWxzLiAgUmVjb3JkLVJvdXRlIFtSRkMz MjYxXSBhbmQgUGF0aA0KICAgIFtSRkMzMzI3XSBhcmUgdmVyeSB1c2VmdWwgaW4gZW5zdXJpbmcg dGhhdCBwcmV2aW91c2x5IGVzdGFibGlzaGVkIFRMUw0KLSAgIGNvbm5lY3Rpb25zIGNhbiBiZSBy ZS11c2VkLiAgT3RoZXIgbWVjaGFuaXNtIG1heSBhbHNvIGJlIHVzZWQgaW4NCi0gICBjZXJ0YWlu IGNpcmN1bXN0YW5jZXM6IGZvciBleGFtcGxlLCB1c2luZyByb290LWNlcnRpZmljYXRlcyB0aGF0 IGFyZQ0KKyAgIGNvbm5lY3Rpb25zIGNhbiBiZSByZS11c2VkLiAgT3RoZXIgbWVjaGFuaXNtcyBt YXkgYWxzbyBiZSB1c2VkIGluDQorICAgY2VydGFpbiBjaXJjdW1zdGFuY2VzOiBmb3IgZXhhbXBs ZSwgdXNpbmcgcm9vdCBjZXJ0aWZpY2F0ZXMgdGhhdCBhcmUNCiAgICB3aWRlbHkgcmVjb2duaXpl ZCBtYXkgYWxsb3cgZm9yIG1vcmUgZWFzaWx5IGNyZWF0ZWQgVExTIGNvbm5lY3Rpb25zLg0KIA0K ICAgIFRoZSAibGFzdCBob3AgZXhjZXB0aW9uIiBpbnRyb2R1Y2VzIHNpZ25pZmljYW50IHBvdGVu dGlhbA0KLSAgIHZ1bG5lcmFiaWxpdGllcyBpbiBTSVAgYW5kIHRoZXJlZm9yZSBoYXMgYmVlbiBk ZXByZWNhdGVkIGJ5IHRoaXMNCisgICB2dWxuZXJhYmlsaXRpZXMgaW4gU0lQIGFuZCBpdCBoYXMg dGhlcmVmb3JlIGJlZW4gZGVwcmVjYXRlZCBieSB0aGlzDQogICAgc3BlY2lmaWNhdGlvbi4NCiAN CiANCkBAIC0yNzIxLDcgKzI3MzEsNyBAQA0KIA0KICAgIE5hbWU6ICBzaXBzDQogICAgRGVzY3Jp cHRpb246ICBUaGlzIG9wdGlvbi10YWcgaXMgdXNlZCB0byBpZGVudGlmeSBVQUNzLCBVQVNzIGFu ZA0KLSAgICAgIFJlZ2lzdHJhcnMgdGhhdCBzdXBwb3J0IHRoZSBwcm9jZWR1cmVzIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi4NCisgICAgICByZWdpc3RyYXJzIHRoYXQgc3VwcG9ydCB0aGUgcHJvY2Vk dXJlcyBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQogDQogDQogOS4gIElBQiBDb25zaWRlcmF0aW9u cw0KQEAgLTI4OTEsNyArMjkwMSw3IEBADQogDQogICAgICAgQWN0dWFsbHkgdXNpbmcgVExTIG9u IGV2ZXJ5IHNlZ21lbnQgb2YgYSByZXF1ZXN0IHBhdGggZW50YWlscyB0aGF0DQogICAgICAgdGhl IHRlcm1pbmF0aW5nIFVBUyBtdXN0IGJlIHJlYWNoYWJsZSBvdmVyIFRMUyAoYnkgcmVnaXN0ZXJp bmcNCi0gICAgICB3aXRoIGEgU0lQUyBVUkkgYXMgYSBjb250YWN0KS4gIFRoZSBTSVBTIHNjaGVt ZSBpbXBsaWVzIHRyYW5zaXRpdmUNCisgICAgICB3aXRoIGEgU0lQUyBVUkkgYXMgYSBDb250YWN0 KS4gIFRoZSBTSVBTIHNjaGVtZSBpbXBsaWVzIHRyYW5zaXRpdmUNCiAgICAgICB0cnVzdC4gIE9i dmlvdXNseSwgdGhlcmUgaXMgbm90aGluZyB0aGF0IHByZXZlbnRzIHByb3hpZXMgZnJvbQ0KICAg ICAgIGNoZWF0aW5nLiAgVGh1cyBTSVBTIGNhbm5vdCBndWFyYW50ZWUgdGhhdCBUTFMgdXNhZ2Ug d2lsbCBiZSB0cnVseQ0KICAgICAgIHJlc3BlY3RlZCBlbmQtdG8tZW5kIG9uIGVhY2ggc2VnbWVu dCBvZiBhIHJlcXVlc3QgcGF0aC4gIE5vdGUgdGhhdA0K --=-zlU1uPgeEDEIBNwNTalv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=-zlU1uPgeEDEIBNwNTalv-- From sip-bounces@ietf.org Thu May 03 14:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjg3q-0006Sw-IZ; Thu, 03 May 2007 14:29:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hjg3p-0006Sr-NH for sip-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 14:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjg3p-0006Sj-Dm for sip@ietf.org; Thu, 03 May 2007 14:29:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hjg3o-0001NM-1L for sip@ietf.org; Thu, 03 May 2007 14:29:49 -0400 X-VirusChecked: Checked X-Env-Sender: Uri.Baniel@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1178216986!8692129!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21522 invoked from network); 3 May 2007 18:29:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 3 May 2007 18:29:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l43ITkP0025636 for ; Thu, 3 May 2007 11:29:46 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l43ITjPp021992 for ; Thu, 3 May 2007 13:29:46 -0500 (CDT) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l43ITjna021987 for ; Thu, 3 May 2007 13:29:45 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 May 2007 14:29:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: prevalence and semantic of 300 Thread-Index: AceNsQWv1KRMOMWaTpCsuCkgcM2G5Q== From: "Baniel Uri-CUB001" To: , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [Sip] prevalence and semantic of 300 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1110892551==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1110892551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78DB1.05F5D069" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78DB1.05F5D069 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the prevalence of 300 compare to 302? If I build a UAC, do I need to worry much about handling 300 (or knowing how to deal with 302 should be good enough?)? =20 >From a practical stand - shall 300 and 302 be treated the same? =20 =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Uri Baniel - System Engineering; Tel: +1 (847) 651 0925; Learning that does not daily increase will daily decrease" - EWC =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C78DB1.05F5D069 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What = is the=20 prevalence of 300 compare to 302? If I build a UAC, do I need to worry = much=20 about handling 300 (or knowing how to deal with 302 should be good=20 enough?)?
 
From a = practical=20 stand - shall 300 and 302 be treated the same?
 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Uri Baniel - System Engineering; = Tel: +1=20 (847) 651 0925;

Learning that does not daily increase will daily = decrease" -=20 EWC

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 
------_=_NextPart_001_01C78DB1.05F5D069-- --===============1110892551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1110892551==-- From sip-bounces@ietf.org Thu May 03 14:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjgVA-0006Km-GB; Thu, 03 May 2007 14:58:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HjgV8-0006Kf-S4 for sip-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 14:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjgV8-0006KX-IQ for sip@ietf.org; Thu, 03 May 2007 14:58:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjgV7-0007mh-7L for sip@ietf.org; Thu, 03 May 2007 14:58:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HjgUP-0008BV-2H; Thu, 03 May 2007 13:57:17 -0500 From: "Brian Rosen" To: , References: <0e7701c78c1c$6df76050$640fa8c0@cis.neustar.com> <200705030237.l432b2G2026117@dragon.ariadne.com> Subject: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations Date: Thu, 3 May 2007 14:57:57 -0400 Message-ID: <014e01c78db4$f87efcd0$650fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AceNK/2HSYWWRbQPS/q7nih5No766AAiNB4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200705030237.l432b2G2026117@dragon.ariadne.com> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul made that point already. I'll reword so either two locations in one header or two headers with one location is acceptable. Brian -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Wednesday, May 02, 2007 10:37 PM To: sip@ietf.org Subject: Re: [Sip] Location-conveyance: ISSUE #3 - multiple locations From: "Brian Rosen" Yeah, I wanted to limit options. I wanted two representations of the same location as a single header. I'm not really stuck on that, but cutting down on options is good. Permit me to exercise one of my peeves -- though it appears that limiting the syntax of the header is beneficial, it is in fact harmful. You want as much uniformity in header syntax as possible, so that implementations can use generic parsers to do the low-level conversion of the character stream to a data structure of names/values/whatever. You also want to allow generic "un-parsing" to convert the data structure to the character stream. But if you make ideosyncratic declarations that a particular header does things *slightly differently* than all similar headers, implementations are reduced to using custom code to generate every header. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 04 02:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjqwg-0004kf-7g; Fri, 04 May 2007 02:07:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hjqwd-0004jB-UZ for sip-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 02:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjqwd-0004gp-Hf for sip@ietf.org; Fri, 04 May 2007 02:07:07 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjqwc-00030J-4F for sip@ietf.org; Fri, 04 May 2007 02:07:07 -0400 Received: (qmail 8497 invoked by uid 0); 4 May 2007 06:08:19 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 May 2007 06:08:19 -0000 Message-ID: <000f01c78e12$3d8f5e70$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Fri, 4 May 2007 08:05:39 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] clarification: multiple outbound registrations and temporary GRUUs: scope of invalidation X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936758246==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1936758246== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C78E23.00E621F0" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C78E23.00E621F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, If a UAC performs multiple outbound registrations (reg-id=1 & reg-id=2) and uses GRUU, the outbound examples show it uses different Call-IDs. Does that mean that the second registration invalidates the temporary GRUU returned in the first 200 OK? In other words: should the temporary GRUU returned for the first Contact be the same, or different? Should outbound recommend to use the same Call-ID for multiple registrations? (and different from-tags)? Regards, Jeroen ------=_NextPart_000_000B_01C78E23.00E621F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
If a UAC performs multiple outbound = registrations=20 (reg-id=3D1 & reg-id=3D2) and uses GRUU, the outbound examples show = it uses=20 different Call-IDs. Does that mean that the second registration = invalidates the=20 temporary GRUU returned in the first 200 OK?
 
In other words: should the temporary = GRUU returned=20 for the first Contact be the same, or different?
 
Should outbound recommend to use the = same Call-ID=20 for multiple registrations? (and different from-tags)?
 
Regards,
Jeroen
------=_NextPart_000_000B_01C78E23.00E621F0-- --===============1936758246== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1936758246==-- From sip-bounces@ietf.org Wed May 09 11:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlo9Y-0004wU-61; Wed, 09 May 2007 11:32:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlo9W-0004wP-V2 for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 11:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlo9W-0004wH-LR for sip@ietf.org; Wed, 09 May 2007 11:32:30 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hlo9V-00071P-AK for sip@ietf.org; Wed, 09 May 2007 11:32:30 -0400 X-VirusChecked: Checked X-Env-Sender: Uri.Baniel@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1178724748!17068620!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27487 invoked from network); 9 May 2007 15:32:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 9 May 2007 15:32:28 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l49FWRUK028078 for ; Wed, 9 May 2007 08:32:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l49FWRUv018417 for ; Wed, 9 May 2007 10:32:27 -0500 (CDT) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l49FWPET018385 for ; Wed, 9 May 2007 10:32:26 -0500 (CDT) 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, 9 May 2007 11:28:47 -0400 Message-ID: In-Reply-To: <0B710C80-F46C-4C35-B00A-A24811FCDD7A@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Legality of domain names in DNS records thread-index: Acdr91+3Jn2IvYPmSbek6R0+Z2QOQAmVoTVw From: "Baniel Uri-CUB001" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Legality of domain names in DNS records X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 RFC 1035 limits the Domain name field of DNS records to letters, digits and '-' signs. Some DNS records however (such as SRV records) use additional characters, e.g. '_' (_sip_udp.someschool.edu). What is the legality of using additional characters for domain names in NAPTR records? (e.g. '@', ':'). Is there any RFC or draft, which supports that? -uri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 15:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrdM-0007t0-6h; Wed, 09 May 2007 15:15:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlrdJ-0007sh-Od for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrdJ-0007sZ-FC for sip@ietf.org; Wed, 09 May 2007 15:15:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlrdI-0001Uu-2b for sip@ietf.org; Wed, 09 May 2007 15:15:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 09 May 2007 12:15:27 -0700 X-IronPort-AV: i="4.14,510,1170662400"; d="scan'208"; a="484666524:sNHT45728588" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l49JFR2o030166; Wed, 9 May 2007 12:15:27 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l49JFQZT021025; Wed, 9 May 2007 19:15:26 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 12:15:29 -0700 Message-ID: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2866; t=1178738127; x=1179602127; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=s7IUTPumEF62nsUWql5+MV/P5B9a6Nau+EkJkcTlEPk=; b=yMtdPKj4UQAhTbFJUNFqzkiHEgDUKUiTVomU55q59rxzDNcIbSPglliAkdpBRrqq8NYhaD45 eXV417Y9AdevILzI24FRcnj80EVZel56jYcVQEtmeVRWf1myVBLIKzwl; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The now-expired draft http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored multipart/alternative. One difficulty, however, is what does it mean to say "can understand a part". This is easy if one part is SDP and another part is SDPng. If you understand SDPng, you process it; if you don't, you process the SDP. However, it's really hard if one part is SDP and another part is also SDP -- in some cases we would like the answerer to "pick the better SDP". At the time, we were considering multipart/alternative as a way to offer RTP (RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all. Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior solution to sending an offer containing RTP and SRTP. I suppose we could avoid the difficulty by prohibiting identical Content-Types in the alternatives. -d > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 03, 2007 3:50 AM > To: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi, > > Multipart/alternative is interesting. I guess that, for SDP, > it could be > used to provide different "offer alternatives". I think it > would be good > to compare it against some of the other grouping/alternative > mechanisms > we have defined for that purpose. > > Regards, > > Christer > > > > -----Original Message----- > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > Sent: 30. huhtikuuta 2007 19:13 > > To: sip@ietf.org > > Subject: Re: [Sip] Support for Multipart/MIME > > > > From: Cullen Jennings > > > > I think the WG should consider an update to 3261 (likely > > done through > > the process Keith has proposed) that makes this multipart/MIME > > mandatory to implement. > > > > I assume that the requirement is that if a message has a > > multipart/alternative body, and the UA is capable of > > understanding one part of the body, then it must be able to > > extract that part and use it to process the message. > > > > Dale > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 15:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlryz-0004rn-2E; Wed, 09 May 2007 15:37:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlryw-0004rh-Oo for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlryw-0004rZ-FJ for sip@ietf.org; Wed, 09 May 2007 15:37:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlryv-0004DH-3d for sip@ietf.org; Wed, 09 May 2007 15:37:50 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2007 15:37:51 -0400 X-IronPort-AV: i="4.14,510,1170651600"; d="scan'208"; a="59826309:sNHT47619806" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l49JbmO8008350; Wed, 9 May 2007 15:37:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49Jb71D023400; Wed, 9 May 2007 19:37:48 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.1830); Wed, 9 May 2007 15:37:40 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 15:37:40 -0400 Message-ID: <46422302.7060507@cisco.com> Date: Wed, 09 May 2007 15:37:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> In-Reply-To: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 19:37:40.0130 (UTC) FILETIME=[81483020:01C79271] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3972; t=1178739468; x=1179603468; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dan=20Wing=20; bh=hMKlPMjX/qrxmdRyOFCdn5T7TApP9i1u3EogWyp4mlY=; b=nFmrIAe7DU7rJpd7uNBVzy05whq69O/OBS9ONwk8Spridk91gZNZF6nG8p6DALpqouAELHHl Cz07IUAptdgikaIEVjpKTcdIW0QTXntXdz3vQgKiHf17P3TeMYd0NIJc; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: sip@ietf.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan Wing wrote: > The now-expired draft > http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored > multipart/alternative. One difficulty, however, is what does it mean to say > "can understand a part". > > This is easy if one part is SDP and another part is SDPng. If you > understand SDPng, you process it; if you don't, you process the SDP. > > However, it's really hard if one part is SDP and another part is also SDP -- > in some cases we would like the answerer to "pick the better SDP". The creator of the multipart/alternative has the job of picking which is the better one. By definition they alternatives are ordered with the preferred one last. (There is an assumption the the the preferred one is the least widely implemented, and the least preferred one is the most widely implemented.) You are supposed to process the *last* one that you are *capable* of processing. But your point still remains. If there are two SDP alternatives, how do you decide if you can implement the last one? You are allowed to ignore much of SDP if you don't understand it. But is that supporting it? > At the > time, we were considering multipart/alternative as a way to offer RTP > (RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all. > Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior > solution to sending an offer containing RTP and SRTP. > > I suppose we could avoid the difficulty by prohibiting identical > Content-Types in the alternatives. Or just clearly define what it means to support one in an alternative. Paul > -d > > >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) >> [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, May 03, 2007 3:50 AM >> To: Dale.Worley@comcast.net; sip@ietf.org >> Subject: RE: [Sip] Support for Multipart/MIME >> >> >> Hi, >> >> Multipart/alternative is interesting. I guess that, for SDP, >> it could be >> used to provide different "offer alternatives". I think it >> would be good >> to compare it against some of the other grouping/alternative >> mechanisms >> we have defined for that purpose. >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Sent: 30. huhtikuuta 2007 19:13 >>> To: sip@ietf.org >>> Subject: Re: [Sip] Support for Multipart/MIME >>> >>> From: Cullen Jennings >>> >>> I think the WG should consider an update to 3261 (likely >>> done through >>> the process Keith has proposed) that makes this multipart/MIME >>> mandatory to implement. >>> >>> I assume that the requirement is that if a message has a >>> multipart/alternative body, and the UA is capable of >>> understanding one part of the body, then it must be able to >>> extract that part and use it to process the message. >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 15:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hls1x-0006G1-68; Wed, 09 May 2007 15:40:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hls1v-0006Fu-TC for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 15:40:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hls1v-0006Fd-JN for sip@ietf.org; Wed, 09 May 2007 15:40:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hls1v-0004sJ-8M for sip@ietf.org; Wed, 09 May 2007 15:40:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 May 2007 15:40:55 -0400 X-IronPort-AV: i="4.14,510,1170651600"; d="scan'208"; a="120699093:sNHT50257386" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l49JetJ6005764; Wed, 9 May 2007 15:40:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49Jes0d024630; Wed, 9 May 2007 19:40:55 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.1830); Wed, 9 May 2007 15:40:55 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.138]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 15:40:54 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 09 May 2007 14:40:53 -0500 To: "Dan Wing" , "'Christer Holmberg \(JO/LMF\)'" , From: "James M. Polk" Subject: RE: [Sip] Support for Multipart/MIME In-Reply-To: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 09 May 2007 19:40:54.0603 (UTC) FILETIME=[F53269B0:01C79271] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3750; t=1178739655; x=1179603655; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20=22Dan=20Wing=22=20, =0A=20=20=20=20=20=20=20=20=2 2'Christer=20Holmberg=20\(JO/LMF\)'=22=20, =0A=20=20=20=20=20=20=20=20; bh=NWnWLfD9knh5qV2MXZbMh2CxEr8CgeBbV747ZmwxTCQ=; b=ZWDE6EDyCFD9iAJA363j1n59EIa7OJ05m+7h1pyu5Ef2BIJkDIzxOdHhNxaAGX232Go97PyS NHQqigofBCxpgIdViOyJNjC801tUVePMOAFpDzYNvKFYGogZH4E3dO+q; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It's possible/probable/obvious (depending on who you talk to) that multipart will have to be supported for emergency calling, in which there is an SDP body and a Location message body... This doesn't mean UAs that *don't* establish voice/video dialogs will have to support multipart, just for those UAs that do establish voice/video dialogs with emergency response centers (again, depending on who you talk to). At 02:15 PM 5/9/2007, Dan Wing wrote: >The now-expired draft >http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored >multipart/alternative. One difficulty, however, is what does it mean to say >"can understand a part". > >This is easy if one part is SDP and another part is SDPng. If you >understand SDPng, you process it; if you don't, you process the SDP. > >However, it's really hard if one part is SDP and another part is also SDP -- >in some cases we would like the answerer to "pick the better SDP". At the >time, we were considering multipart/alternative as a way to offer RTP >(RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all. >Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior >solution to sending an offer containing RTP and SRTP. > >I suppose we could avoid the difficulty by prohibiting identical >Content-Types in the alternatives. > >-d > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, May 03, 2007 3:50 AM > > To: Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > Hi, > > > > Multipart/alternative is interesting. I guess that, for SDP, > > it could be > > used to provide different "offer alternatives". I think it > > would be good > > to compare it against some of the other grouping/alternative > > mechanisms > > we have defined for that purpose. > > > > Regards, > > > > Christer > > > > > > > -----Original Message----- > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > Sent: 30. huhtikuuta 2007 19:13 > > > To: sip@ietf.org > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > From: Cullen Jennings > > > > > > I think the WG should consider an update to 3261 (likely > > > done through > > > the process Keith has proposed) that makes this multipart/MIME > > > mandatory to implement. > > > > > > I assume that the requirement is that if a message has a > > > multipart/alternative body, and the UA is capable of > > > understanding one part of the body, then it must be able to > > > extract that part and use it to process the message. > > > > > > Dale > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 16:16:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlsa3-0001jf-UE; Wed, 09 May 2007 16:16:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlsa2-0001jV-Hc for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 16:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlsa2-0001jK-7y for sip@ietf.org; Wed, 09 May 2007 16:16:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlsa0-0002dK-Mz for sip@ietf.org; Wed, 09 May 2007 16:16:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 May 2007 13:16:09 -0700 X-IronPort-AV: i="4.14,510,1170662400"; d="scan'208"; a="373994199:sNHT52202842" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l49KG8uO021588; Wed, 9 May 2007 13:16:08 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49KG70f004982; Wed, 9 May 2007 20:16:07 GMT From: "Dan Wing" To: "'James M. Polk'" , "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 13:16:09 -0700 Message-ID: <0c9701c79276$e254e840$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceScfVuHSSQE/9pTjiAtg7YyRh6DAABJqtQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4460; t=1178741768; x=1179605768; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=4YWLnDMVJJgFiXLrRzrGB9LLZjdC1y/JPpOWzUxkT8I=; b=jNdgDdimb9M8PYyd2Gxb2po7IILx3glSRfXyuz+ZDwprpiHYKqQ/6gqO3eAhmKNfgUlqXP8j TOE1Igmr1Fa0K33Hocseb6JkYjWw44LmrkJ10+uqYyDBAbf/6OabbzHCwibqMhRqZegT6A8aoS C7JhJh8qLQIFAyM10welIzgvA=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > It's possible/probable/obvious (depending on who you talk to) that > multipart will have to be supported for emergency calling, in which > there is an SDP body and a Location message body... > > This doesn't mean UAs that *don't* establish voice/video dialogs will > have to support multipart, just for those UAs that do establish > voice/video dialogs with emergency response centers (again, depending > on who you talk to). By support, you mean such a UA would need to be able to send an Invite with a multipart, right? That is, such a UA wouldn't need to necessarily receive or need to parse multipart for the purposes of emergency calling. (It's quite trivial to send multipart, and obviously more difficult to handle parsing it, especially nested multiparts. Not impossible -- it's been done for years and years by mail user agents, afterall, but it's also not slam-dunk easy.) -d > At 02:15 PM 5/9/2007, Dan Wing wrote: > >The now-expired draft > >http://tools.ietf.org/html/draft-jennings-sipping-multipart-0 > 2 explored > >multipart/alternative. One difficulty, however, is what > does it mean to say > >"can understand a part". > > > >This is easy if one part is SDP and another part is SDPng. If you > >understand SDPng, you process it; if you don't, you process the SDP. > > > >However, it's really hard if one part is SDP and another > part is also SDP -- > >in some cases we would like the answerer to "pick the better > SDP". At the > >time, we were considering multipart/alternative as a way to offer RTP > >(RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work > well at all. > >Since then, draft-ietf-mmusic-sdp-capability-negotiation is > a superior > >solution to sending an offer containing RTP and SRTP. > > > >I suppose we could avoid the difficulty by prohibiting identical > >Content-Types in the alternatives. > > > >-d > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, May 03, 2007 3:50 AM > > > To: Dale.Worley@comcast.net; sip@ietf.org > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > > > > Hi, > > > > > > Multipart/alternative is interesting. I guess that, for SDP, > > > it could be > > > used to provide different "offer alternatives". I think it > > > would be good > > > to compare it against some of the other grouping/alternative > > > mechanisms > > > we have defined for that purpose. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > -----Original Message----- > > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > > Sent: 30. huhtikuuta 2007 19:13 > > > > To: sip@ietf.org > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > > > From: Cullen Jennings > > > > > > > > I think the WG should consider an update to 3261 (likely > > > > done through > > > > the process Keith has proposed) that makes this > multipart/MIME > > > > mandatory to implement. > > > > > > > > I assume that the requirement is that if a message has a > > > > multipart/alternative body, and the UA is capable of > > > > understanding one part of the body, then it must be able to > > > > extract that part and use it to process the message. > > > > > > > > Dale > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 16:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlsgk-0006To-4K; Wed, 09 May 2007 16:23:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlsgh-0006Tj-TC for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 16:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlsgh-0006Tb-Jg for sip@ietf.org; Wed, 09 May 2007 16:23:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlsgg-0003fX-4N for sip@ietf.org; Wed, 09 May 2007 16:23:03 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l49KMvW1001209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 13:22:57 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l49KMtKd013557; Wed, 9 May 2007 13:22:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> Date: Wed, 9 May 2007 13:22:53 -0700 To: "James M. Polk" , "Dan Wing" , "'Christer Holmberg \(JO/LMF\)'" , From: Ted Hardie Subject: RE: [Sip] Support for Multipart/MIME Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 2:40 PM -0500 5/9/07, James M. Polk wrote: >It's possible/probable/obvious (depending on who you talk to) that multipart will have to be supported for emergency calling, in which there is an SDP body and a Location message body... > >This doesn't mean UAs that *don't* establish voice/video dialogs will have to support multipart, just for those UAs that do establish voice/video dialogs with emergency response centers (again, depending on who you talk to). That won't be multipart/alternative, though, as the location body and the SDP body won't be alternatives but independent items. I think they would be multipart/mixed. See this from RFC 2046: 5.1.3. Mixed Subtype The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order. Any "multipart" subtypes that an implementation does not recognize must be treated as being of subtype "mixed". 5.1.4. Alternative Subtype The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information. Ted >At 02:15 PM 5/9/2007, Dan Wing wrote: >>The now-expired draft >>http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored >>multipart/alternative. One difficulty, however, is what does it mean to say >>"can understand a part". >> >>This is easy if one part is SDP and another part is SDPng. If you >>understand SDPng, you process it; if you don't, you process the SDP. >> >>However, it's really hard if one part is SDP and another part is also SDP -- >>in some cases we would like the answerer to "pick the better SDP". At the >>time, we were considering multipart/alternative as a way to offer RTP >>(RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all. >>Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior >>solution to sending an offer containing RTP and SRTP. >> >>I suppose we could avoid the difficulty by prohibiting identical >>Content-Types in the alternatives. >> >>-d >> >> >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: Thursday, May 03, 2007 3:50 AM >>> To: Dale.Worley@comcast.net; sip@ietf.org >>> Subject: RE: [Sip] Support for Multipart/MIME >>> >>> >>> Hi, >>> >>> Multipart/alternative is interesting. I guess that, for SDP, >>> it could be >>> used to provide different "offer alternatives". I think it >>> would be good >>> to compare it against some of the other grouping/alternative >>> mechanisms >>> we have defined for that purpose. >>> >>> Regards, >>> >>> Christer >>> >>> >>> > -----Original Message----- >>> > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> > Sent: 30. huhtikuuta 2007 19:13 >>> > To: sip@ietf.org >>> > Subject: Re: [Sip] Support for Multipart/MIME >>> > >>> > From: Cullen Jennings >>> > >>> > I think the WG should consider an update to 3261 (likely >>> > done through >>> > the process Keith has proposed) that makes this multipart/MIME >>> > mandatory to implement. >>> > >>> > I assume that the requirement is that if a message has a >>> > multipart/alternative body, and the UA is capable of >>> > understanding one part of the body, then it must be able to >>> > extract that part and use it to process the message. >>> > >>> > Dale >>> > >>> > >>> > _______________________________________________ >>> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> > This list is for NEW development of the core SIP Protocol Use >>> > sip-implementors@cs.columbia.edu for questions on current sip >>> > Use sipping@ietf.org for new developments on the application of sip >>> > >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >> > Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 16:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltB6-0000gn-3V; Wed, 09 May 2007 16:54:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HltB4-0000gf-Hn for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 16:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltB4-0000fG-7w for sip@ietf.org; Wed, 09 May 2007 16:54:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HltB1-0000AK-Uc for sip@ietf.org; Wed, 09 May 2007 16:54:26 -0400 Received: from [64.101.172.158] ([64.101.172.158]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l49JxPN6011166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 May 2007 14:59:26 -0500 In-Reply-To: References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 15:52:01 -0500 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, "James M. Polk" , Dan Wing , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 9, 2007, at 3:22 PM, Ted Hardie wrote: > At 2:40 PM -0500 5/9/07, James M. Polk wrote: >> It's possible/probable/obvious (depending on who you talk to) that >> multipart will have to be supported for emergency calling, in >> which there is an SDP body and a Location message body... >> >> This doesn't mean UAs that *don't* establish voice/video dialogs >> will have to support multipart, just for those UAs that do >> establish voice/video dialogs with emergency response centers >> (again, depending on who you talk to). > > That won't be multipart/alternative, though, as the location body > and the SDP body > won't be alternatives but independent items. I think they would be > multipart/mixed. See this from RFC 2046: Right. Mixed is a far cleaner semantic problem than alternative. It means "Use all of these that you understand, to the best of your ability, and complain if there's nothing you understand." -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 17:09:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltPo-0002e2-Hz; Wed, 09 May 2007 17:09:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HltPn-0002dK-4g for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 17:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltPm-0002dC-RM for sip@ietf.org; Wed, 09 May 2007 17:09:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HltPl-00027n-Hp for sip@ietf.org; Wed, 09 May 2007 17:09:38 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 09 May 2007 14:09:37 -0700 X-IronPort-AV: i="4.14,511,1170662400"; d="scan'208"; a="420325381:sNHT43369924" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l49L9bCL010150; Wed, 9 May 2007 14:09:37 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49L9a0f017266; Wed, 9 May 2007 21:09:36 GMT From: "Dan Wing" To: "'Dean Willis'" , "'Ted Hardie'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 14:09:35 -0700 Message-ID: <0cd601c7927e$5971bff0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceSfDZskVeuaiG+SLqSXg3zV+TYpgAAU3og DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1792; t=1178744977; x=1179608977; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=/+oRk2EqZJsBbDJSn5CBc9b9a1WRpFhcdqUzjj6ziBg=; b=mHbmoiuIx5hnszxxOjT8fMZc/j1GwdBZwmSOfDJOLISizUgSbO2ofsDR2dSBZaQyRzaZQcFh GFugusgfKkE74rTRrGUFG5wqhOY7XEtv6NbC7X5WAN9IJGyejEf1k1Rw; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, "'James M. Polk'" , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > At 2:40 PM -0500 5/9/07, James M. Polk wrote: > >> It's possible/probable/obvious (depending on who you talk > >> to) that > >> multipart will have to be supported for emergency calling, in > >> which there is an SDP body and a Location message body... > >> > >> This doesn't mean UAs that *don't* establish voice/video dialogs > >> will have to support multipart, just for those UAs that do > >> establish voice/video dialogs with emergency response centers > >> (again, depending on who you talk to). > > > > That won't be multipart/alternative, though, as the location body > > and the SDP body > > won't be alternatives but independent items. I think they would be > > multipart/mixed. See this from RFC 2046: > > Right. Mixed is a far cleaner semantic problem than alternative. It > means "Use all of these that you understand, to the best of your > ability, and complain if there's nothing you understand." I agree that multipart/mixed makes sense when you're sending different content-types and you want the receiver to process each one that he understands. This is useful if you're doing an Invite that includes your location (application/sdp and application/pidf+xml [draft-ietf-sip-location-conveyance]). However, if you're sending SDP and SDPng, multipart/mixed does not make sense. If you're sending SDP and SDPng, you want the answerer to pick one. For the next decade, anyone that understands SDPng will also need to continue to understand SDP. And we don't want the receiver to creatively use both the SDP offer and the SDPng offer. Email is similar: if you configure Thunderbird or Outlook to send messages with text/plain and text/html they are put inside multipart/related, not multipart/mixed. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 17:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltfS-00036u-3F; Wed, 09 May 2007 17:25:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HltfQ-00036p-4O for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 17:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HltfP-00036h-R6 for sip@ietf.org; Wed, 09 May 2007 17:25:47 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HltfN-0004pE-Ci for sip@ietf.org; Wed, 09 May 2007 17:25:47 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l49LPdtY014605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 14:25:40 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l49LPbDa023655; Wed, 9 May 2007 14:25:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <0cd601c7927e$5971bff0$c4a36b80@amer.cisco.com> References: <0cd601c7927e$5971bff0$c4a36b80@amer.cisco.com> Date: Wed, 9 May 2007 14:25:35 -0700 To: "Dan Wing" , "'Dean Willis'" From: Ted Hardie Subject: RE: [Sip] Support for Multipart/MIME Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sip@ietf.org, "'James M. Polk'" , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 2:09 PM -0700 5/9/07, Dan Wing wrote: > >However, if you're sending SDP and SDPng, multipart/mixed does not >make sense. If you're sending SDP and SDPng, you want the answerer >to pick one. For the next decade, anyone that understands SDPng >will also need to continue to understand SDP. And we don't want the >receiver to creatively use both the SDP offer and the SDPng offer. > >Email is similar: if you configure Thunderbird or Outlook to send >messages with text/plain and text/html they are put inside >multipart/related, not multipart/mixed. I totally agree. It seems like multipart/mixed, multipart/alternative, and possibly multipart/related will be needed for different uses. regards, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 17:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlu8U-0003a9-Nn; Wed, 09 May 2007 17:55:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlu8T-0003Zz-EL for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 17:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlu8T-0003Zm-4a for sip@ietf.org; Wed, 09 May 2007 17:55:49 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlu8R-0000ot-T8 for sip@ietf.org; Wed, 09 May 2007 17:55:49 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2007 17:55:48 -0400 X-IronPort-AV: i="4.14,512,1170651600"; d="scan'208"; a="59841782:sNHT43090678" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l49LtlUW013111; Wed, 9 May 2007 17:55:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l49Lt1lm023761; Wed, 9 May 2007 21:55: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.1830); Wed, 9 May 2007 17:55:34 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 17:55:33 -0400 Message-ID: <46424354.3000905@cisco.com> Date: Wed, 09 May 2007 17:55:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <0cd601c7927e$5971bff0$c4a36b80@amer.cisco.com> In-Reply-To: <0cd601c7927e$5971bff0$c4a36b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 21:55:33.0614 (UTC) FILETIME=[C4A9A8E0:01C79284] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1013; t=1178747747; x=1179611747; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dan=20Wing=20; bh=c0RmvhBn8tp9p5KwQ7f/DruEn19FYuf/Oouu2OnuGQ4=; b=fYJaNm1H7r2GDX9HIyN64MsGHVbmtqkcqGM/Z5ESfAbiNKA3IOyPEp7U3MSOdH3hm9gi2h9/ KxIGoenrLFIXzB7eVTANDibG8jhZweltHETpJ5rXFKw4RSXF3IwFq5qM; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org, "'James M. Polk'" , "'Christer Holmberg \(JO/LMF\)'" , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan Wing wrote: > I agree that multipart/mixed makes sense when you're sending > different content-types and you want the receiver to process each > one that he understands. This is useful if you're doing an Invite > that includes your location (application/sdp and > application/pidf+xml [draft-ietf-sip-location-conveyance]). > > However, if you're sending SDP and SDPng, multipart/mixed does not > make sense. If you're sending SDP and SDPng, you want the answerer > to pick one. For the next decade, anyone that understands SDPng > will also need to continue to understand SDP. And we don't want the > receiver to creatively use both the SDP offer and the SDPng offer. It seems that this issue is moot, since SDPng seems to have been declared dead. > Email is similar: if you configure Thunderbird or Outlook to send > messages with text/plain and text/html they are put inside > multipart/related, not multipart/mixed. Don't you mean multipart/alternative? Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 18:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluPe-0006EP-BZ; Wed, 09 May 2007 18:13:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HluPc-0006EK-OU for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 18:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluPc-0006EC-F1 for sip@ietf.org; Wed, 09 May 2007 18:13:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HluPb-0003wZ-65 for sip@ietf.org; Wed, 09 May 2007 18:13:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 09 May 2007 15:13:30 -0700 X-IronPort-AV: i="4.14,512,1170662400"; d="scan'208"; a="58947116:sNHT43440084" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l49MDUcr030517; Wed, 9 May 2007 15:13:30 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l49MDPEi027077; Wed, 9 May 2007 22:13:25 GMT From: "Dan Wing" To: "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 15:13:25 -0700 Message-ID: <0cf801c79287$467dd380$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46424354.3000905@cisco.com> Thread-Index: AceShMV9wVU1O3czQUWF5EIJMTXZrAAAhl7Q DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1411; t=1178748810; x=1179612810; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=IA08wLcQQme8HPPbQq7va7MyAzdd06sgjDuoTwHBgbw=; b=PimvkgAPzvWXs0fUEdVFSpCToHfyp1RzinuMCB7ZJ/xjMFYGWG45EePMWVKfosjZjtNObOq/ p9w7623KukUtWKVC3ie5SmitAR7Ac98eU6wmpmje+Ytjt5IPp5ta60PQTyQUvSJZ0wjf7jsoIX 8+u8l/tVUFl67DGmWIrg1cmUU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org, "'James M. Polk'" , "'Christer Holmberg \(JO/LMF\)'" , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > > I agree that multipart/mixed makes sense when you're sending > > different content-types and you want the receiver to process each > > one that he understands. This is useful if you're doing an Invite > > that includes your location (application/sdp and > > application/pidf+xml [draft-ietf-sip-location-conveyance]). > > > > However, if you're sending SDP and SDPng, multipart/mixed does not > > make sense. If you're sending SDP and SDPng, you want the answerer > > to pick one. For the next decade, anyone that understands SDPng > > will also need to continue to understand SDP. And we don't want the > > receiver to creatively use both the SDP offer and the SDPng offer. > > It seems that this issue is moot, since SDPng seems to have been > declared dead. Yes, it seems that way. > > Email is similar: if you configure Thunderbird or Outlook to send > > messages with text/plain and text/html they are put inside > > multipart/related, not multipart/mixed. > > Don't you mean multipart/alternative? Argh, yes. Thanks for catching that mistake. Anyway - someone needs to run with this multipart/mixed for sure, and probably also multipart/alternative and multipart/related (per Ted's suggestion, although I don't see a use case for multipart/ related at the moment). I no longer have the bandwidth to coauthor draft-jennings-sipping-multipart. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 18:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlucY-0004Gw-9Q; Wed, 09 May 2007 18:26:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlucW-0004Gr-Vy for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 18:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlucW-0004Gj-MU for sip@ietf.org; Wed, 09 May 2007 18:26:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlucW-0007PT-9n for sip@ietf.org; Wed, 09 May 2007 18:26:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2007 18:26:52 -0400 X-IronPort-AV: i="4.14,512,1170651600"; d="scan'208"; a="59843997:sNHT50620372" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l49MQqi0019177; Wed, 9 May 2007 18:26:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49MQp0Z010907; Wed, 9 May 2007 22:26: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.1830); Wed, 9 May 2007 18:26:51 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 18:26:51 -0400 Message-ID: <46424AAA.5060705@cisco.com> Date: Wed, 09 May 2007 18:26:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2007 22:26:51.0035 (UTC) FILETIME=[23B15EB0:01C79289] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4508; t=1178749612; x=1179613612; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dean=20Willis=20; bh=0kpKvCZtBqF1BOeD3JKhoYz85X5NoM2dhQjGIuZUGhk=; b=S/X97kYzOZEFY9iYs2bX6kkuvYviO6um7uuZ/5QeJrP0xPbzCF9TTj7EkdXwglrZER/rEXaC BHP55hO/LV7PmOsWXiI+pbFSfn5Az1nxjfRr+f5qcvwnuKnyr4FR189K; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: sip@ietf.org, "James M. Polk" , Dan Wing , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On May 9, 2007, at 3:22 PM, Ted Hardie wrote: > >> At 2:40 PM -0500 5/9/07, James M. Polk wrote: >>> It's possible/probable/obvious (depending on who you talk to) that >>> multipart will have to be supported for emergency calling, in which >>> there is an SDP body and a Location message body... >>> >>> This doesn't mean UAs that *don't* establish voice/video dialogs will >>> have to support multipart, just for those UAs that do establish >>> voice/video dialogs with emergency response centers (again, depending >>> on who you talk to). >> >> That won't be multipart/alternative, though, as the location body and >> the SDP body >> won't be alternatives but independent items. I think they would be >> multipart/mixed. See this from RFC 2046: > > Right. Mixed is a far cleaner semantic problem than alternative. It > means "Use all of these that you understand, to the best of your > ability, and complain if there's nothing you understand." IIUC you needn't complain if you don't understand any of the parts. Rather, the handling parameter of the Content-Disposition header of each part needs to be examined. For handling=optional the part can be ignored if you don't understand it. For handling=required you need to complain if you don't understand it. So for example, you could have an INVITE that contains a multipart/mixed where the parts are: - a part with Content-Type:text/plain and Content-Disposition:render;handling=optional. - a part with Content-Type:image/gif and Content-Dispostion:icon;handling=optional This should be treated as an offerless INVITE even if neither subpart is understood. The case of location conveyance does present an interesting issue that I have wondered about for some time and never found an answer to: Suppose you are making a call, and for some reason think that providing location information will be helpful. But it isn't critical that the recipient understand it. So you send a request like: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: ;inserted-by=endpoint Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP here --boundary1 Content-Type: application/pidf+xml Content-ID: alice123@atlanta.example.com Content-Disposition:???;handling=optional 2007-03-20T14:00:00Z ... --boundary1-- You need the Content-Dispostion header so that you can insert the handling=optional parameter. But what is the content-disposition value? None of the currently defined values, such as "session", or "render" seems appropriate. In some sense its content-disposition is irrelevant because the processing of the part is determined by the cid: reference in the Geolocation header. But a UAS that doesn't understand the Geolocation header won't know that. We have some parts whose handling is governed by their type and disposition, without need of explicit reference from another header. And we have other parts that shouldn't be processed at all unless there is an explicit reference to them elsewhere that has itself been understood. IMO there needs to be a Content-Disposition that covers the latter case. But that has never been recognized and specified. This of course is a potential issue even if the body part is there by itself, without an enclosing multipart. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 21:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNr-0007US-Cy; Wed, 09 May 2007 21:23:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlxNn-0007M5-PC for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 21:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNn-0007Jz-Ek for sip@ietf.org; Wed, 09 May 2007 21:23:51 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxNl-0006tC-4r for sip@ietf.org; Wed, 09 May 2007 21:23:51 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4A1NdQQ022228 for ; Wed, 9 May 2007 20:23:48 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:23:23 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:23: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, 10 May 2007 03:23:20 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001159737@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location-conveyance: ISSUE #1 - self signed certificates Thread-Index: AceIYfRNGyMoJnotSpCpYRDXcG8sFQJWZeYA From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 10 May 2007 01:23:20.0518 (UTC) FILETIME=[CB843E60:01C792A1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] RE: Location-conveyance: ISSUE #1 - self signed certificates X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There has been no response on this issue, and therefore I consider this issue closed.=20 The information on self-signed certifications will be removed from draft-ietf-sip-location-conveyance. Regards Keith=20 > -----Original Message----- > From: Drage, Keith (Keith)=20 > Sent: Friday, April 27, 2007 1:26 AM > To: 'IETF SIP List' > Subject: Location-conveyance: ISSUE #1 - self signed certificates >=20 > (As SIP WG chair) >=20 > During the review of the WGLC comments, we have identified=20 > some issues where we need consensus calls on the list. These=20 > are in one call per message. >=20 > There is mention of self-signed certificates in=20 > draft-ietf-sip-location-conveyance. It is proposed to remove=20 > that requirement: >=20 > "Self-signed certificates SHOULD NOT be used for=20 > protecting a PIDF,=20 > as the sender does not have a secure identity of the recipient." >=20 > Essentially we agreed that if this statement was necessary,=20 > it should be made in draft-ietf-sip-certs, rather than in=20 > location-conveyance. >=20 > We will assume that this removal represents WG consensus=20 > unless we hear otherwise from the WG in 7 calendar days from=20 > the posting of this message. >=20 > Regards >=20 > Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 21:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNs-0007Xc-9F; Wed, 09 May 2007 21:23:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlxNp-0007TT-Bh for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 21:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNo-0007OR-Dt for sip@ietf.org; Wed, 09 May 2007 21:23:52 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxNm-0006tF-Bb for sip@ietf.org; Wed, 09 May 2007 21:23:51 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4A1NdQY022228 for ; Wed, 9 May 2007 20:23:49 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:23:39 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:23:36 +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 Subject: Location-conveyance: ISSUE #4 - error indications (was RE: [Sip] SIP location conveyance: error indication) Date: Thu, 10 May 2007 03:23:36 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800115973A@DEEXC1U01.de.lucent.com> In-Reply-To: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Location-conveyance: ISSUE #4 - error indications (was RE: [Sip] SIP location conveyance: error indication) Thread-Index: AceHfwXDVDO2JPDaTouai4ogyGKSHAKQB+FQ References: <06DBA97B-FF03-4E16-8215-1A47DC9C8565@cs.columbia.edu> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 10 May 2007 01:23:36.0784 (UTC) FILETIME=[D5363D00:01C792A1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Henning provided this proposal a few weeks back. Since then, there have been a number of clarifications on the proposal, but apparently no alternatives. I would therefore like to make a consensus call on this issue. The call is EITHER: - To progress location conveyance by documenting the proposal of Henning in the new version. This is obviously agreement on the mechanism, than any of the finer details which could change in the process of documentation and WG discussion. OR - To retain the core of the existing mechanism as documented in -07 of location-conveyance, addressing the remaining comments as fixes to the use of the Warning header, and so on. Unless I header comments otherwise within seven calendar days from this mail, I will assume working group consensus is to go in the direction of Henning's proposal. Note that technical responses and suggestions are welcome on the proposal, but what I am interested in resolving here is the key direction to take the location-conveyance document. Therefore please be clear as to you position on the above question if making any response to this thread. Regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Wednesday, April 25, 2007 10:17 PM > To: IETF SIP List > Subject: [Sip] SIP location conveyance: error indication >=20 > During the call today, we discussed error handling in SIP=20 > location conveyance and identified two problems: >=20 > (1) With multiple locations, it is impossible to tell which error > (warning) refers to which location. Since location elements=20 > may be inserted by proxies and are then invisible to the UAC,=20 > the UAC could get an error indication which makes no sense=20 > since it refers to another location. >=20 > (2) The current return-424 model is inappropriate if=20 > location-related failures should not cause the call to fail,=20 > as will often be the case. (Just because Domino's can't=20 > dereference my location URL, it still wants to talk to me=20 > about ordering pizza, but I also want to fix that URL.) >=20 > Thus, my proposal: >=20 > (1) Define a new Location-Error request (?) and response header, as in >=20 > Geolocation-Error: "Cannot > dereference" ;tag=3D"xkauc" ;code=3D711 ;source=3D"alice.example.com" >=20 > where tag is a new tag added to a location header. This error=20 > can occur in a 424 or any other status code, including a 200.=20 > If included in the request, it's used by the UAS in case=20 > location handling is delegated to some other proxy. (I'm not=20 > sure whether the request header thing is a good idea.) >=20 > (2) Define a new Accept-* header, as in >=20 > Accept-Geolocation: sip, http >=20 > which identifies the dereferencing protocols supported, to=20 > avoid the current ugly overloading of the warning messages. >=20 > Henning >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 21:23:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNo-0007RK-UN; Wed, 09 May 2007 21:23:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlxNm-0007Iv-Uu for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 21:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxNm-0007Ik-L5 for sip@ietf.org; Wed, 09 May 2007 21:23:50 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxNl-0006tE-Ap for sip@ietf.org; Wed, 09 May 2007 21:23:50 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4A1NdQS022228 for ; Wed, 9 May 2007 20:23:48 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:23:32 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:23: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 Subject: RE: [Sip] Location-conveyance: ISSUE #3 - multiple locations Date: Thu, 10 May 2007 03:23:30 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001159739@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location-conveyance: ISSUE #3 - multiple locations Thread-Index: AceJxeRiWYVqzczWSD+GBqRQT3G6egH98tKw From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 10 May 2007 01:23:30.0543 (UTC) FILETIME=[D17DEFF0:01C792A1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A summary of where we are on this one. None of the key points below have been disagreed with, and they are therefore considered agreed. One of the comments made on the list was that draft-ietf-pdif-lo may provide useful information to support this. The editor's and review team discussed whether draft-ietf-sip-location-conveyance should contain a normative reference to this document. It was agreed that this document contained provisions that were application specific rather than protocol specific, and therefore there should not be a normative reference.=20 Brian Rosen then took the action to draft text to agree on the list in regard to this. That action is still in progress on the continuation of this thread (see post of 1st May and subsequent responses). Regards Keith > -----Original Message----- > From: Drage, Keith (Keith)=20 > Sent: Saturday, April 28, 2007 7:49 PM > To: 'IETF SIP List' > Subject: [Sip] Location-conveyance: ISSUE #3 - multiple locations >=20 > (As SIP WG chair) >=20 > During the review of the WGLC comments, we have identified=20 > some issues where we need consensus calls on the list. These=20 > are in one call per message. >=20 > We had a number of comments that it was not clear whether a=20 > message could contain multiple locations, and if they were,=20 > what were the procedures. >=20 > On the call we identified what we believe the way forward in=20 > this area, which is summarised by the following statements: >=20 > - location conveyance should support the delivery of=20 > multiple locations; >=20 > - the document will make no recommendations as to how the=20 > recipient chooses=20 > which location to use. This is regarded as specific to the=20 > using application, and therefore beyond the scope of the=20 > protocol extension; >=20 > - the recipient should attempt to make use of all the=20 > locations given, and=20 > should only respond with a 424 response if it is unable to=20 > use any of those locations. This includes resolving all and=20 > any locations by reference; >=20 > - as a result of the above, any 424 response is a=20 > collective statement about=20 > all the locations given in the request rather than any=20 > specific location in the request. >=20 > We will assume that this represents WG consensus unless we=20 > hear otherwise from the WG in 7 calendar days from the=20 > posting of this message.=20 >=20 > Obviously if the WG has an alternative view, some proposal of=20 > the alternative way forward and the expected impact on the=20 > text would be entirely appropriate. >=20 > Regards >=20 > Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 21:55:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxsR-0001nx-TB; Wed, 09 May 2007 21:55:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlxsP-0001np-MB for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 21:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxsO-0001ng-W0 for sip@ietf.org; Wed, 09 May 2007 21:55:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxsN-0003el-8x for sip@ietf.org; Wed, 09 May 2007 21:55:28 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 25F64213C3; Thu, 10 May 2007 03:55:26 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-c5-46427b8ef9e6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0181320014; Thu, 10 May 2007 03:55:26 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:55:25 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 03:55:23 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> In-Reply-To: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIA== References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 01:55:25.0741 (UTC) FILETIME=[4709F5D0:01C792A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >The now-expired draft http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 >explored multipart/alternative. One difficulty, however, is what does it mean to say "can understand a part". >=20 >This is easy if one part is SDP and another part is SDPng. =20 >If you understand SDPng, you process it; if you don't, you=20 >process the SDP. >=20 >However, it's really hard if one part is SDP and another part=20 >is also SDP -- in some cases we would like the answerer to=20 >"pick the better SDP". It doesn't always have to be about picking what is best. For example: Assume a terminal supports audio and video. If both audio and video are used, it supports codecs audio_X and video_X. However, if only audio OR video are used, the terminal has more resources available, to it could use the more-resource-using codecs audio_Y and video_Y. In this case I don't think it's about picking based on what is "better", it's about picking based on what will be used for the session.=20 Now, I am sure there are other ways of doing this, but this solution would not require support of any SDP extensions (multipart/alternative would of course have to be supported), and the same port number could be used for the audio and/or media m=3D lines in all alternatives. Regards, Christer >At the time, we were considering multipart/alternative as a way to offer RTP (RTP/AVP) and SRTP (RTP/SAVP), but we found >it doesn't work well at all. >Since then, draft-ietf-mmusic-sdp-capability-negotiation is a=20 >superior solution to sending an offer containing RTP and SRTP. =20 >=20 > I suppose we could avoid the difficulty by prohibiting=20 > identical Content-Types in the alternatives. >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, May 03, 2007 3:50 AM > > To: Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > >=20 > > Hi, > >=20 > > Multipart/alternative is interesting. I guess that, for=20 > SDP, it could=20 > > be used to provide different "offer alternatives". I think=20 > it would be=20 > > good to compare it against some of the other grouping/alternative=20 > > mechanisms we have defined for that purpose. > >=20 > > Regards, > >=20 > > Christer > > =20 > >=20 > > > -----Original Message----- > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > Sent: 30. huhtikuuta 2007 19:13 > > > To: sip@ietf.org > > > Subject: Re: [Sip] Support for Multipart/MIME > > >=20 > > > From: Cullen Jennings > > >=20 > > > I think the WG should consider an update to 3261 (likely done=20 > > > through > > > the process Keith has proposed) that makes this=20 > multipart/MIME =20 > > > mandatory to implement. > > >=20 > > > I assume that the requirement is that if a message has a=20 > > > multipart/alternative body, and the UA is capable of=20 > understanding=20 > > > one part of the body, then it must be able to extract=20 > that part and=20 > > > use it to process the message. > > >=20 > > > Dale > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 22:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlxzs-0006QI-Dn; Wed, 09 May 2007 22:03:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hlxzq-0006NW-MP for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 22:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlxzq-0006NK-3k for sip@ietf.org; Wed, 09 May 2007 22:03:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlxzo-0004fz-HN for sip@ietf.org; Wed, 09 May 2007 22:03:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 09 May 2007 19:03:08 -0700 X-IronPort-AV: i="4.14,513,1170662400"; d="scan'208"; a="771818424:sNHT49189146" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4A237gE004895; Wed, 9 May 2007 19:03:07 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4A236ZT011648; Thu, 10 May 2007 02:03:07 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 19:03:06 -0700 Message-ID: <0db201c792a7$5a1d6ca0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5107; t=1178762587; x=1179626587; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=HQfPn3xSBgqhzKZMyBflxsskFiY0q8dWWZVmU0nyFFo=; b=oVQjj4nsLdE4/NJgQEIyA83yu13l9/fRHJQ+aINZbrLns0s4urJxabhVTbQ5P6RDVffTOQLu nS1SbNHcxnjxTLW/Y8Ed34AWbJBKGoJU4TNGyGhF6zpFz+jdrRDNf/3xlNzf0xmiimJ3mwZou4 ftDogY/aAskaSecDbvch1mBkM=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, May 09, 2007 6:55 PM > To: Dan Wing; Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi, > > >The now-expired draft > http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 > >explored multipart/alternative. One difficulty, however, is > what does > it mean to say "can understand a part". > > > >This is easy if one part is SDP and another part is SDPng. > >If you understand SDPng, you process it; if you don't, you > >process the SDP. > > > >However, it's really hard if one part is SDP and another part > >is also SDP -- in some cases we would like the answerer to > >"pick the better SDP". > > It doesn't always have to be about picking what is best. > > For example: > > Assume a terminal supports audio and video. If both audio and > video are > used, it supports codecs audio_X and video_X. > > However, if only audio OR video are used, the terminal has more > resources available, to it could use the more-resource-using codecs > audio_Y and video_Y. > > In this case I don't think it's about picking based on what > is "better", > it's about picking based on what will be used for the session. > > Now, I am sure there are other ways of doing this, but this solution > would not require support of any SDP extensions (multipart/alternative > would of course have to be supported), and the same port > number could be > used for the audio and/or media m= lines in all alternatives. Using the same port number on multiple m= lines has been, and continues to be, a direct violation of several SDP specifications. Even the SDP grouping specification explicitly calls this out as illegal. Draft-ietf-mmusic-sdp-capability-negotiation is 100% backwards compatible with endpoints that don't understand it. Multipart/ alternative will never share that characteristic; the last SIPIT showed how poorly multipart is supported today and there is no way, when you build an offer, to know if all of the answerers will understand multipart/alternative. HERFP rears its head, too. I had thought there was consensus around the need for draft-ietf-mmusic-sdp-capability-negotiation -- I am mistaken? -d > Regards, > > Christer > > > > > > > >At the time, we were considering multipart/alternative as a way to > offer RTP (RTP/AVP) and SRTP (RTP/SAVP), but we found >it doesn't work > well at all. > >Since then, draft-ietf-mmusic-sdp-capability-negotiation is a > >superior solution to sending an offer containing RTP and SRTP. > > > > I suppose we could avoid the difficulty by prohibiting > > identical Content-Types in the alternatives. > > > > -d > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, May 03, 2007 3:50 AM > > > To: Dale.Worley@comcast.net; sip@ietf.org > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > > > > Hi, > > > > > > Multipart/alternative is interesting. I guess that, for > > SDP, it could > > > be used to provide different "offer alternatives". I think > > it would be > > > good to compare it against some of the other grouping/alternative > > > mechanisms we have defined for that purpose. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > -----Original Message----- > > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > > Sent: 30. huhtikuuta 2007 19:13 > > > > To: sip@ietf.org > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > > > From: Cullen Jennings > > > > > > > > I think the WG should consider an update to 3261 > (likely done > > > > through > > > > the process Keith has proposed) that makes this > > multipart/MIME > > > > mandatory to implement. > > > > > > > > I assume that the requirement is that if a message has a > > > > multipart/alternative body, and the UA is capable of > > understanding > > > > one part of the body, then it must be able to extract > > that part and > > > > use it to process the message. > > > > > > > > Dale > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 09 22:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyAY-0005OP-F3; Wed, 09 May 2007 22:14:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HlyAX-0005OG-68 for sip-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 22:14:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlyAW-0005O6-SS for sip@ietf.org; Wed, 09 May 2007 22:14:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlyAW-0006aL-8G for sip@ietf.org; Wed, 09 May 2007 22:14:12 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B3F68205AF; Thu, 10 May 2007 04:14:11 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-1e-46427ff3d3dc Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 92306200C8; Thu, 10 May 2007 04:14:11 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 04:14:11 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 04:14:02 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F22476@esealmw113.eemea.ericsson.se> In-Reply-To: <0db201c792a7$5a1d6ca0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoA= References: <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> <0db201c792a7$5a1d6ca0$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 02:14:11.0314 (UTC) FILETIME=[E5EEC520:01C792A8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>It doesn't always have to be about picking what is best. >>=20 >>For example: >>=20 >>Assume a terminal supports audio and video. If both audio and video=20 >>are used, it supports codecs audio_X and video_X. >>=20 >>However, if only audio OR video are used, the terminal has more=20 >>resources available, to it could use the more-resource-using codecs=20 >>audio_Y and video_Y. >>=20 >>In this case I don't think it's about picking based on what is=20 >>"better", it's about picking based on what will be used for the=20 >>session. >>=20 >>Now, I am sure there are other ways of doing this, but this=20 >>solution would not require support of any SDP extensions=20 >>(multipart/alternative would of course have to be supported), and the same port=20 >>number could be used for the audio and/or media m=3D lines in all alternatives. >=20 >Using the same port number on multiple m=3D lines has been, and=20 >continues to be, a direct violation of several SDP=20 >specifications. Even the SDP grouping specification=20 >explicitly calls this out as illegal. Yes. But in the multipart/alternative example I gave you (and which is ilustrated in a simple form below) would have 3 individual SDP bodies, and the same port number would not be used within a single SDP bodies.=20 But, the same port number would be used in each indivudual SDP body, and as far as I know there is no specification which forbids that. -----boundary m=3Daudio 9999 audio_x m=3Dvideo 7777 video_x -----boundary m=3Dvideo 7777 video_y -----boundary m=3Daudio 9999 audio_y -----boundary-- =20 Regards, Christer >Draft-ietf-mmusic-sdp-capability-negotiation is 100% backwards compatible with endpoints that don't understand it.=20 >Multipart/ alternative will never share that characteristic; the last SIPIT showed how poorly multipart is supported=20 >today and there is no way, when you build an offer, to know if all of the answerers will understand=20 >multipart/alternative. HERFP rears its head, too. >=20 >I had thought there was consensus around the need for draft-ietf-mmusic-sdp-capability-negotiation -- I am mistaken? >=20 > -d >=20 >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > >At the time, we were considering multipart/alternative as a way to > > offer RTP (RTP/AVP) and SRTP (RTP/SAVP), but we found >it=20 > doesn't work=20 > > well at all. > > >Since then, draft-ietf-mmusic-sdp-capability-negotiation is a=20 > > >superior solution to sending an offer containing RTP and SRTP. > > >=20 > > > I suppose we could avoid the difficulty by prohibiting identical=20 > > > Content-Types in the alternatives. > > >=20 > > > -d > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: Thursday, May 03, 2007 3:50 AM > > > > To: Dale.Worley@comcast.net; sip@ietf.org > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > Multipart/alternative is interesting. I guess that, for > > > SDP, it could > > > > be used to provide different "offer alternatives". I think > > > it would be > > > > good to compare it against some of the other=20 > grouping/alternative=20 > > > > mechanisms we have defined for that purpose. > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > > > Sent: 30. huhtikuuta 2007 19:13 > > > > > To: sip@ietf.org > > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > >=20 > > > > > From: Cullen Jennings > > > > >=20 > > > > > I think the WG should consider an update to 3261 > > (likely done > > > > > through > > > > > the process Keith has proposed) that makes this > > > multipart/MIME > > > > > mandatory to implement. > > > > >=20 > > > > > I assume that the requirement is that if a message has a=20 > > > > > multipart/alternative body, and the UA is capable of > > > understanding > > > > > one part of the body, then it must be able to extract > > > that part and > > > > > use it to process the message. > > > > >=20 > > > > > Dale > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 00:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm06k-0005DG-DM; Thu, 10 May 2007 00:18:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm06i-0005D9-Ob for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm06i-0005D1-Eu for sip@ietf.org; Thu, 10 May 2007 00:18:24 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm06h-0000sD-5C for sip@ietf.org; Thu, 10 May 2007 00:18:24 -0400 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4A3PUq9012592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 May 2007 22:25:30 -0500 Message-ID: <46429D84.8020202@softarmor.com> Date: Wed, 09 May 2007 23:20:20 -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 (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > In this case I don't think it's about picking based on what is "better", > it's about picking based on what will be used for the session. better is relative and one man's lutefisk is another's cat food. Perhaps what we need to say here is "preferred by the receiver". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 00:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0F7-0001vi-HG; Thu, 10 May 2007 00:27:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm0F5-0001vS-Q8 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0F5-0001vK-GT for sip@ietf.org; Thu, 10 May 2007 00:27:03 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0F4-0001v1-6w for sip@ietf.org; Thu, 10 May 2007 00:27:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 May 2007 21:27:01 -0700 X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="146902483:sNHT216350316" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4A4R1lS004143; Wed, 9 May 2007 21:27:01 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4A4R00f012290; Thu, 10 May 2007 04:27:01 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 21:27:02 -0700 Message-ID: <0db901c792bb$753389c0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F22476@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1365; t=1178771221; x=1179635221; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=n36JDjE3WWq9KxTIne3m8yE5+TH7yXsLSBteG7frBC4=; b=bPAGWxYCmDY5ONidzo89W2y/o05Ms/2cVanlcF2npv9EBJoA3jpR8oFVT3hcxHU6DVO8NIPA 4N7zXTAk4Kx2jsX0Dmhr3ocI7EvXQ/imcSaF6d4u4HkBXprAdlUcJjbh; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >Using the same port number on multiple m= lines has been, and > >continues to be, a direct violation of several SDP > >specifications. Even the SDP grouping specification > >explicitly calls this out as illegal. > > Yes. But in the multipart/alternative example I gave you (and which is > ilustrated in a simple form below) would have 3 individual SDP bodies, > and the same port number would not be used within a single > SDP bodies. > > But, the same port number would be used in each indivudual > SDP body, and as far as I know there is no specification which > forbids that. > > -----boundary > > m=audio 9999 audio_x > m=video 7777 video_x > > -----boundary > > m=video 7777 video_y > > -----boundary > > m=audio 9999 audio_y > > -----boundary-- This can be expressed with MMUSIC's capabilities negotiation, though -- and can be expressed better than with multipart/alternative because MMUSIC's capability negotiation defines preferences of each m= and each a= line, whereas multipart/alternative can only ever allow simple "take all of this SDP" or "take none of this SDP". (With the specific example you show, of course, you don't even need MMUSIC's capabilities negotiation -- an answerer that doesn't support video (or doesn't support audio) can already indicate that in its SDP answer.) -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 00:28:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0GT-0003Dp-QH; Thu, 10 May 2007 00:28:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm0GS-0003Di-Hb for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0GS-0003DT-7N for sip@ietf.org; Thu, 10 May 2007 00:28:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0GQ-00023m-TI for sip@ietf.org; Thu, 10 May 2007 00:28:28 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l4A4SM97016798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 21:28:22 -0700 Received: from [76.102.225.135] (vpn-10-50-0-138.qualcomm.com [10.50.0.138]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l4A4SKph019291; Wed, 9 May 2007 21:28:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <46429D84.8020202@softarmor.com> References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> <46429D84.8020202@softarmor.com> Date: Wed, 9 May 2007 21:28:18 -0700 To: Dean Willis , "Christer Holmberg (JO/LMF)" From: Ted Hardie Subject: Re: [Sip] Support for Multipart/MIME Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 11:20 PM -0500 5/9/07, Dean Willis wrote: >Christer Holmberg (JO/LMF) wrote: > >>In this case I don't think it's about picking based on what is "better", >>it's about picking based on what will be used for the session. > >better is relative and one man's lutefisk is another's cat food. > >Perhaps what we need to say here is "preferred by the receiver". > >-- >Dean We've lost a bit of context here, but presuming that we're still talking about multipart/alternative, that's not quite the model. The preference order is set by the sender, it is explicit that the receiver should take the first body it can handle. If you want some other semantic (where all of them presented and the receiver selected among them), I believe you'd have to use a different MIME type. regards, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 00:54:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0fK-0001l9-8a; Thu, 10 May 2007 00:54:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm0fI-0001l4-SC for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 00:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0fI-0001kw-Ii for sip@ietf.org; Thu, 10 May 2007 00:54:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0fH-0005bS-Tx for sip@ietf.org; Thu, 10 May 2007 00:54:08 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3CD3B2092A; Thu, 10 May 2007 06:54:07 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-a6-4642a56fdace Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 325BF208AB; Thu, 10 May 2007 06:54:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 06:54:07 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 06:54:01 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F224D6@esealmw113.eemea.ericsson.se> In-Reply-To: <0db901c792bb$753389c0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWw References: <7374777208BDC7449D5620EF9423256703F22476@esealmw113.eemea.ericsson.se> <0db901c792bb$753389c0$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 04:54:07.0113 (UTC) FILETIME=[3D797F90:01C792BF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 Comment at the end. > > >Using the same port number on multiple m=3D lines has been, and=20 > > >continues to be, a direct violation of several SDP=20 > specifications. =20 > > >Even the SDP grouping specification explicitly calls this out as=20 > > >illegal. > >=20 > > Yes. But in the multipart/alternative example I gave you=20 > (and which is=20 > > ilustrated in a simple form below) would have 3 individual=20 > SDP bodies,=20 > > and the same port number would not be used within a single=20 > SDP bodies. > >=20 > > But, the same port number would be used in each indivudual=20 > SDP body,=20 > > and as far as I know there is no specification which forbids that. > >=20 > > -----boundary > >=20 > > m=3Daudio 9999 audio_x > > m=3Dvideo 7777 video_x > >=20 > > -----boundary > >=20 > > m=3Dvideo 7777 video_y > >=20 > > -----boundary > >=20 > > m=3Daudio 9999 audio_y > >=20 > > -----boundary-- >=20 > This can be expressed with MMUSIC's capabilities negotiation,=20 > though -- and can be expressed better than with=20 > multipart/alternative because MMUSIC's capability negotiation=20 > defines preferences of each m=3D and each a=3D line, whereas=20 > multipart/alternative can only ever allow simple "take all of=20 > this SDP" or "take none of this SDP". >=20 > (With the specific example you show, of course, you don't=20 > even need MMUSIC's capabilities negotiation -- an answerer=20 > that doesn't support video (or doesn't support audio) can=20 > already indicate that in its SDP answer.) The point is that, depending on what media the answerer chooses, different codecs can be used for chosen media streams. Yes, "vanilla" SDP allows me to offer audio and video, and the answerer can incdicate what it does/doesn't support. But, vanilla SDP does not allow the offer to say: "Here is audio and video. If you accept both then let's use these codecs, but if you only choose audio then let's use theis other codec".=20 Regards, Christer >=20 > -d >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 01:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm12C-0007Rz-MA; Thu, 10 May 2007 01:17:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm12A-0007Ri-HQ for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 01:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm129-0007RW-Qp for sip@ietf.org; Thu, 10 May 2007 01:17:45 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm127-000052-Qh for sip@ietf.org; Thu, 10 May 2007 01:17:45 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 May 2007 22:17:42 -0700 X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="59002077:sNHT43093737" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4A5HgrJ021821; Wed, 9 May 2007 22:17:42 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4A5HbEi019351; Thu, 10 May 2007 05:17:37 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 22:17:39 -0700 Message-ID: <0dc501c792c2$87cf9ef0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F224D6@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=558; t=1178774262; x=1179638262; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=oTL1Hn8RFfeAVxlDrAkXnDBrJ+N4PlKNDbZ79SSXmP4=; b=bT6GsVgQp/k9+UiJDsUQzCrcW4tmAfSSKH25L7DH90FmV6Tnd6PmgGpl49BicHR0lcRwxNjp bBrw2JG5M0N5ChZ7gn6vrvdHfZQNdya2MidewCeIEurMOqUvLex+AVI5; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > The point is that, depending on what media the answerer chooses, > different codecs can be used for chosen media streams. > > Yes, "vanilla" SDP allows me to offer audio and video, and > the answerer > can incdicate what it does/doesn't support. But, vanilla SDP does not > allow the offer to say: "Here is audio and video. If you accept both > then let's use these codecs, but if you only choose audio > then let's use > theis other codec". SDP Capabilities Negotiation does that, too -- and far better than multipart/alternative. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 02:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1gg-0007fv-Qn; Thu, 10 May 2007 01:59:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm1gf-0007fX-7A for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 01:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1ge-0007fG-EC for sip@ietf.org; Thu, 10 May 2007 01:59:36 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1gc-0007Pz-SZ for sip@ietf.org; Thu, 10 May 2007 01:59:36 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 468C62152E; Thu, 10 May 2007 07:59:34 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-f1-4642b4c663d5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3669B214A1; Thu, 10 May 2007 07:59:34 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 07:59:33 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 07:59:30 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F225D1@esealmw113.eemea.ericsson.se> In-Reply-To: <0dc501c792c2$87cf9ef0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gA== References: <7374777208BDC7449D5620EF9423256703F224D6@esealmw113.eemea.ericsson.se> <0dc501c792c2$87cf9ef0$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 05:59:33.0884 (UTC) FILETIME=[620333C0:01C792C8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>The point is that, depending on what media the answerer chooses,=20 >>different codecs can be used for chosen media streams. >>=20 >>Yes, "vanilla" SDP allows me to offer audio and video, and the=20 >>answerer can incdicate what it does/doesn't support. But, vanilla SDP=20 >>does not allow the offer to say: "Here is audio and video. If you=20 >>accept both then let's use these codecs, but if you only choose audio=20 >>then let's use theis other codec". >=20 >SDP Capabilities Negotiation does that, too -- and far better=20 >than multipart/alternative. I haven't seen any comparision between the mechanisms, so I can't comment on the "far better" statement at this point. But, in order to do the same thing with SDP CapNeg, I assume it does require the remote terminal to actually support SDP CapNeg? I agree that many terminals don't support multipart today, but wasn't the initial issue of this thread that we want to mandate the support of multipart (at least multipart/mixed)? Also, my initial intention was not to compare multipart/alternative with SDP CapNeg, but to give an example what multipart/alternative could be used for. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 02:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1jY-0000iV-TU; Thu, 10 May 2007 02:02:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm1jX-0000iQ-6l for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 02:02:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1jW-0000iI-Mp for sip@ietf.org; Thu, 10 May 2007 02:02:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1jV-0007xQ-DZ for sip@ietf.org; Thu, 10 May 2007 02:02:34 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CA573208B5; Thu, 10 May 2007 08:02:32 +0200 (CEST) X-AuditID: c1b4fb3c-a7ce9bb0000073d5-36-4642b578a442 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AFCE720642; Thu, 10 May 2007 08:02:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 08:02:32 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 08:02:30 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F225D8@esealmw113.eemea.ericsson.se> In-Reply-To: <46429D84.8020202@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceSuj+3lFeSjA17SsOrSH/S5ktI0AABA9og References: <7374777208BDC7449D5620EF9423256703CB4EDA@esealmw113.eemea.ericsson.se> <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F22473@esealmw113.eemea.ericsson.se> <46429D84.8020202@softarmor.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dean Willis" X-OriginalArrivalTime: 10 May 2007 06:02:32.0633 (UTC) FILETIME=[CC8E2290:01C792C8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >>In this case I don't think it's about picking based on what is "better", it's about picking based on what will be used=20 >>for the session. >=20 >better is relative and one man's lutefisk is another's cat food. >=20 >Perhaps what we need to say here is "preferred by the receiver". Correct. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 02:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1vN-0000lM-1M; Thu, 10 May 2007 02:14:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm1vJ-0000lF-ON for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 02:14:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1vI-0000l5-SU for sip@ietf.org; Thu, 10 May 2007 02:14:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1vH-0000op-JG for sip@ietf.org; Thu, 10 May 2007 02:14:44 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 09 May 2007 23:14:44 -0700 X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="374046403:sNHT41504740" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4A6Egcq022421; Wed, 9 May 2007 23:14:42 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4A6EgEi011672; Thu, 10 May 2007 06:14:42 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 9 May 2007 23:14:38 -0700 Message-ID: <0dd301c792ca$7dd21ec0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F225D1@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gAAAqj2A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1393; t=1178777683; x=1179641683; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=yFcbxqWlhwy+frzSzYw+Mn2jb0jLtKXACwBA40mA8AE=; b=P9CfdvQPCrFK0BLGehcjwhXKKwRLegkTHjQYb7MazDha6jbkYC/1apN/QFxuP4HwlEDPZT8b Fx5cgOkiJwsNhqIrWvNRBbzaXP20obwgHbifHPRqM1lPO6L75RN/PED4; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >SDP Capabilities Negotiation does that, too -- and far better > >than multipart/alternative. > > I haven't seen any comparision between the mechanisms, so I can't > comment on the "far better" statement at this point. Ok. I'll let Flemming or one of the other people deep into the SDP capability negotiation comment on the virtues of it versus multipart/alternative with several different SDP parts. > But, in order to do the same thing with SDP CapNeg, I assume it does > require the remote terminal to actually support SDP CapNeg? > > I agree that many terminals don't support multipart today, but wasn't > the initial issue of this thread that we want to mandate the > support of multipart (at least multipart/mixed)? Yes. But multipart/mixed isn't useful selecting the 'best' SDP; it's useful for throwing a bunch of different content types into one SIP body (SDP and location, for example). > Also, my initial intention was not to compare > multipart/alternative with > SDP CapNeg, but to give an example what multipart/alternative could be > used for. I have become convinced, through my efforts with RTPSEC, that multipart/alternative is harmful if it contains multiple SDP parts. So if there is something other than SDP that multipart/alternative might help with -- and there very well could be -- throw it out for discussion. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 03:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm30D-0000yC-AG; Thu, 10 May 2007 03:23:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm30B-0000y1-7b for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 03:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm307-0000xh-Sw for sip@ietf.org; Thu, 10 May 2007 03:23:47 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm307-0001pk-Gt for sip@ietf.org; Thu, 10 May 2007 03:23:47 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4A7NVFg021698 for ; Thu, 10 May 2007 02:23:47 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 02:23:43 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 09:23:42 +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 Subject: RE: [Sip] Location-conveyance: ISSUE #2 - emergency calls Date: Thu, 10 May 2007 09:23:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180011597B3@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Location-conveyance: ISSUE #2 - emergency calls Thread-Index: AceIYq75WH5JqfBUQ7Cbas8qTNixHgJWdMtA References: <5D1A7985295922448D5550C94DE29180010BF7F6@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 10 May 2007 07:23:42.0222 (UTC) FILETIME=[230E72E0:01C792D4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org To summarise where we are on this one. Looking at the thread, it appears that no one objected to the removal of the material. There were some questions on what should be removed. This has been discussed futher by the editors and review team and can be summarised as (section numbers as in -07 version of location-conveyance): - section 1: keep the paragraph, but to remove the word "frequently" and strike the last sentence.=20 - section 4.3: already gone as a result of other decisions.=20 - section 6 would go in total as a result of this action. There were concerns that the material would be directly copied into the ECRIT documents. Let me state that any material so moved will be rewritten by the editor's of the ECRIT documents to correspond to the scope of those documents. Naturally the editor's of the ECRIT documents concerned will be bound by the normal consensus building activities of the ECRIT working group, and it is appropriate for any member of the ECRIT WG to comment on (or disagree with) that text when it appears.=20 Regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Friday, April 27, 2007 1:33 AM > To: IETF SIP List > Subject: [Sip] Location-conveyance: ISSUE #2 - emergency calls >=20 > (As SIP WG chair) >=20 > During the review of the WGLC comments, we have identified=20 > some issues where we need consensus calls on the list. These=20 > are in one call per message. >=20 > There is an amount of text (primarily section 6) within=20 > draft-ietf-sip-location-conveyance related to emergency=20 > calls. It is proposed to remove this text on the basis that=20 > there are charter items within the IETF ECRIT working group=20 > that fully specify this application of location conveyance to=20 > this particular purpose. The editor's will make sure that all=20 > the removed text is reflected in appropriately in the=20 > concerned ECRIT documents. >=20 > We will assume that this removal represents WG consensus=20 > unless we hear otherwise from the WG in 7 calendar days from=20 > the posting of this message. >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 10:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9ql-0008Q4-MK; Thu, 10 May 2007 10:42:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm9qk-0008Hs-2e for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 10:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9qj-0008Fi-NO for sip@ietf.org; Thu, 10 May 2007 10:42:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9qg-0003rN-1L for sip@ietf.org; Thu, 10 May 2007 10:42:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8BFA020AD3; Thu, 10 May 2007 16:42:29 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-65-46432f55bfb7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 71A6B20AFE; Thu, 10 May 2007 16:42:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 16:42: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 Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 16:42:27 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> In-Reply-To: <0dd301c792ca$7dd21ec0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gAAAqj2AABG8TnA= References: <7374777208BDC7449D5620EF9423256703F225D1@esealmw113.eemea.ericsson.se> <0dd301c792ca$7dd21ec0$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 14:42:29.0313 (UTC) FILETIME=[6F39BB10:01C79311] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>But, in order to do the same thing with SDP CapNeg, I=20 >>assume it does require the remote terminal to actually support SDP CapNeg? >> >>I agree that many terminals don't support multipart today, but wasn't=20 >>the initial issue of this thread that we want to mandate=20 >>the support of multipart (at least multipart/mixed)? >=20 >Yes. But multipart/mixed isn't useful selecting the 'best'=20 >SDP; it's useful for throwing a bunch of different content=20 >types into one SIP body (SDP and location, for example). Correct, but with multipart I meant both mixed and alternative. >>Also, my initial intention was not to compare multipart/alternative=20 >>with SDP CapNeg, but to give an example what multipart/alternative=20 >>could be used for. >I have become convinced, through my efforts with RTPSEC, that=20 >multipart/alternative is harmful if it contains multiple SDP parts. Again, I am not in a position to disagree with you ,but is that harmfulness documented somewhere? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 12:18:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmBLm-0004ph-I0; Thu, 10 May 2007 12:18:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmBLk-0004oO-58 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 12:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmBLj-0004oF-Rs for sip@ietf.org; Thu, 10 May 2007 12:18:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmBLi-0004Mk-IQ for sip@ietf.org; Thu, 10 May 2007 12:18:39 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 09:18:38 -0700 X-IronPort-AV: i="4.14,518,1170662400"; d="scan'208"; a="420658739:sNHT50241912" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4AGIbYA011069; Thu, 10 May 2007 09:18:37 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4AGIaZT009926; Thu, 10 May 2007 16:18:37 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 09:18:36 -0700 Message-ID: <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gAAAqj2AABG8TnAAA32TAA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=360; t=1178813917; x=1179677917; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=fLKbW7BVh/ng6mQYxxzXOIjL+pWSVMVy7dYgX2MU73I=; b=BVlOFcacjkROeteSPBaCJ92DpyN2pT4KXIFrW08tG2pUTl5mE37bfCh+hwL6woMKYSzsArpt a9oPZoS/1R4gLl45pWZ7544WOIrDK7M02I6BSOB0yCHddBhc74Bi9gUuB6SHMjkmX4BABCtwIk NAEUa56HZ4GBCIjrNo5Nuiy+k=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >I have become convinced, through my efforts with RTPSEC, that > >multipart/alternative is harmful if it contains multiple SDP parts. > > Again, I am not in a position to disagree with you ,but is that > harmfulness documented somewhere? Nope. If we're going to move multipart/* forward in SIP, though, I'll be happy to write that section. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 13:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCLK-0004if-L7; Thu, 10 May 2007 13:22:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmCLI-0004iS-HB for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 13:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCLI-0004iK-7f for sip@ietf.org; Thu, 10 May 2007 13:22:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmCLG-0004Ny-Ua for sip@ietf.org; Thu, 10 May 2007 13:22:16 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 May 2007 13:22:14 -0400 X-IronPort-AV: i="4.14,518,1170651600"; d="scan'208"; a="120778657:sNHT46816452" 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 l4AHMEFo000531; Thu, 10 May 2007 13:22:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4AHLule014657; Thu, 10 May 2007 17:22:14 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.1830); Thu, 10 May 2007 13:22:11 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 13:22:10 -0400 Message-ID: <464354C1.6030003@cisco.com> Date: Thu, 10 May 2007 13:22:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> In-Reply-To: <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2007 17:22:10.0827 (UTC) FILETIME=[BE40BDB0:01C79327] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=983; t=1178817734; x=1179681734; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dan=20Wing=20; bh=c1FAgyxlcmaFfnrfl2Pipnj14WMWRIPZSb893qFMX8g=; b=yUITOFR5SiDEFphSl10FUkMtOdK678ZHRuki/Y6GXKXXifEYXRQhn9gRQbbteTqtZ+t1UE/v 6u5V90BnXecqFhexyUK7pk3gw0IIVyZ5LXOqHNglsjqTxftbOtgf7on4; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sip@ietf.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think it will be easier to make progress on multipart/mixed than multipart/alternative. It appears that making progress on alternative will be difficult without some use cases to help in defining what it means to "support" one of the alternatives. Paul Dan Wing wrote: >>> I have become convinced, through my efforts with RTPSEC, that >>> multipart/alternative is harmful if it contains multiple SDP parts. >> Again, I am not in a position to disagree with you ,but is that >> harmfulness documented somewhere? > > Nope. If we're going to move multipart/* forward in SIP, though, > I'll be happy to write that section. > > -d > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 14:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCx4-00049h-HF; Thu, 10 May 2007 14:01:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmCx2-00049A-Sd for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 14:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmCx2-00048E-Ih for sip@ietf.org; Thu, 10 May 2007 14:01:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmCx1-0000xF-6e for sip@ietf.org; Thu, 10 May 2007 14:01:16 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4AI19A06066; Thu, 10 May 2007 18:01:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 13:01:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> In-reply-to: <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gAAAqj2AABG8TnAAA32TAAACot8w References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Christer Holmberg \(JO/LMF\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think we are on to something here. I believe that Paul Kyzivat and Dan Wing have it right. What I'd like to see is something describing the following: - How to use Multipart/mixed I think Paul Kyzivat and Dan had some good explanation in this thread about it.=20 We should really make proper treatment of multipart/mixed as mandatory as we can.=20 This means, being able to understand parse the nested MIME bodies that you DO support. At a miminum, an implementation should be able to find in a Multipart/mixed the SDP for example. We probably need also to write some recommnedation on what happens if there is multiple SDPs in that multipart mixed. It's not pretty out there. I've seen implementations that don't even send 415 when receiving multipart/mixed: they just ignore the payload, and believe it's an SDP-less INVITE. They then put an offer in the response, which the real offerer believes is an answer. Then all hell breaks loose. Some of them do send 415, but without the supported payload type in an Accept=20 header in 415. - Multipart/alternative I agree with Dan that using Multipart/alternative in the way that was described in draft-jennings-sipping-multipart section 5 is in fact harmful. Especially now that we are defining capability negotiation. Section 6 would be OK, but now that SDPng is gone, it's irrelevant. What we really need to say is that multipart/alternative may be used only when we are using alternative payload types for the same information. For example, text/html and=20 text/xml or whatever. It would be applicable if one day we re-created another SDPng=20 for example. Section 3.1 explains this relatively well, but is restricted to Offers (for which we have no use cases anymore). I think it should instead talk about other examples (e.g., text/html, text/xml, or maybe some example with pictures). I really believe section 5 goes against the spririt of section 3.1 (specifically, of the quote of RFC 2046). What it really has it two application/sdp (one of them is=20 encrypted inside a application/pkcs7mime), but really it's still two application/sdp But we should make it clear that it is NOT for negotiating multiple alternatives of=20 the same payload type, in particular, not for application/sdp & application/sdp. =20 If we decide to go forward, I'd be happy to help too. =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Thursday, May 10, 2007 09:19 > To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net > Cc: sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME >=20 > > >I have become convinced, through my efforts with RTPSEC, that=20 > > >multipart/alternative is harmful if it contains multiple SDP parts. > >=20 > > Again, I am not in a position to disagree with you ,but is that=20 > > harmfulness documented somewhere? >=20 > Nope. If we're going to move multipart/* forward in SIP,=20 > though, I'll be happy to write that section. >=20 > -d >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 15:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEeS-0004Xk-DK; Thu, 10 May 2007 15:50:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmEeJ-0004Tw-Cj for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEeI-0004Tg-Ox; Thu, 10 May 2007 15:50:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmEeI-00075H-8B; Thu, 10 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 196B526E78; Thu, 10 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HmEeH-0002uU-VL; Thu, 10 May 2007 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 May 2007 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-subnot-etags-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sip-subnot-etags-00.txt Pages : 22 Date : 2007-5-10 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they do not allow state to persist over a subscription refresh, or between two consecutive polls. This inability to suppress notifications of state already known to the subscriber results in superfluous traffic in the network. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of an event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-subnot-etags-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-subnot-etags-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-subnot-etags-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-10101327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-subnot-etags-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-subnot-etags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10101327.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu May 10 18:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmHZE-0006EU-02; Thu, 10 May 2007 18:57:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmHZC-0006EC-Mc for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 18:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmHZC-0006Dz-Cz for sip@ietf.org; Thu, 10 May 2007 18:56:58 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmHZB-0005yI-3a for sip@ietf.org; Thu, 10 May 2007 18:56:58 -0400 Received: from [64.101.172.158] ([64.101.172.158]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4AM4CU2017281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 10 May 2007 17:04:13 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <81283714-A3B2-4BDD-BA9E-DD3473ECC8D6@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Thu, 10 May 2007 17:56:45 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Sip] Discussion: draft-ietf-sip-subnot-etags-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Y'all may have noticed we have this new working group draft: draft-ietf-sip-subnot-etags-00.txt Please give it a read and see what you think -- I don't want this one to take all year. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 19:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmIRM-0000ct-Bb; Thu, 10 May 2007 19:52:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmIRK-0000cl-S8 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 19:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmIRK-0000cd-IY for sip@ietf.org; Thu, 10 May 2007 19:52:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmIRJ-00038h-Sy for sip@ietf.org; Thu, 10 May 2007 19:52:54 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 37D27203FB; Fri, 11 May 2007 01:52:53 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-96-4643b05504df Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 174D320011; Fri, 11 May 2007 01:52:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 01:52: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 Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 01:52:50 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F85F34@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceLQnkGjbn27+D9RPmgzW7CtVAiTwCLfMUAAT8wFTAADhBjIAAATZvgAABUtoAABLgJwAAA6cWwAAD+cyAAAS32gAAAqj2AABG8TnAAA32TAAACot8wAA0OglA= References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Dan Wing" , X-OriginalArrivalTime: 10 May 2007 23:52:52.0947 (UTC) FILETIME=[52D86230:01C7935E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 =20 > - Multipart/alternative >=20 > I agree with Dan that using Multipart/alternative in the=20 > way that was > described > in draft-jennings-sipping-multipart section 5 is in fact harmful. > Especially now that we > are defining capability negotiation. Section 6 would be OK, but now > that SDPng is gone, > it's irrelevant. >=20 > What we really need to say is that multipart/alternative may be used > only when we > are using alternative payload types for the same information. For > example, text/html and=20 > text/xml or whatever. It would be applicable if one day we=20 > re-created > another SDPng=20 > for example. >=20 > Section 3.1 explains this relatively well, but is=20 > restricted to Offers > (for which we have > no use cases anymore). I think it should instead talk about other > examples (e.g., > text/html, text/xml, or maybe some example with pictures). >=20 > I really believe section 5 goes against the spririt of section 3.1 > (specifically, of > the quote of RFC 2046). What it really has it two=20 > application/sdp (one > of them is=20 > encrypted inside a application/pkcs7mime), but really it's still two > application/sdp >=20 > But we should make it clear that it is NOT for negotiating multiple > alternatives of=20 > the same payload type, in particular, not for application/sdp & > application/sdp. In my example earlier it was not about negotiting multiple alternatives of the same payload type. But, anyway, if we want to forbid app/sdp & app/sdp we need good technical justification for that, but my understanding is that Dan indicated he would be able to provide that. Regards, Christer =20 > If we decide to go forward, I'd be happy to help too. > =20 >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com]=20 > > Sent: Thursday, May 10, 2007 09:19 > > To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net > > Cc: sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > > > >I have become convinced, through my efforts with RTPSEC, that=20 > > > >multipart/alternative is harmful if it contains multiple=20 > SDP parts. > > >=20 > > > Again, I am not in a position to disagree with you ,but is that=20 > > > harmfulness documented somewhere? > >=20 > > Nope. If we're going to move multipart/* forward in SIP,=20 > > though, I'll be happy to write that section. > >=20 > > -d > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 20:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmIn0-0006CZ-B5; Thu, 10 May 2007 20:15:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmImy-0006CU-M8 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 20:15:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmImy-0006CM-Ca for sip@ietf.org; Thu, 10 May 2007 20:15:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmImx-00056J-Up for sip@ietf.org; Thu, 10 May 2007 20:15:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 May 2007 20:15:14 -0400 X-IronPort-AV: i="4.14,520,1170651600"; d="scan'208"; a="59943666:sNHT52609872" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4B0FDKY016356; Thu, 10 May 2007 20:15:13 -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.12.10/8.12.6) with ESMTP id l4B0F95f002973; Fri, 11 May 2007 00:15:09 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.1830); Thu, 10 May 2007 20:15:09 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 20:15:08 -0400 Message-ID: <4643B58A.3060407@cisco.com> Date: Thu, 10 May 2007 20:15:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 00:15:08.0825 (UTC) FILETIME=[6F173090:01C79361] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5276; t=1178842513; x=1179706513; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Francois=20Audet=20; bh=nq9p+zT+tdQAph+IVK/576ZDS+oPLT+CGH+Yq2NOOrM=; b=JJ0c3MLRiie2DtH6c8jlmyZV7zUPNGL8UQ6sFTpQ/AG1ZZ4iA1YrGwbBi7QwOP29V/ItJmXi XpHWzFxmhJsTpoi/y//U6K0T3G+Vq+JCCviCNiZm1OX43EA9bdDqIwVn; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: sip@ietf.org, Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I think we are on to something here. I believe that Paul Kyzivat and Dan > Wing have it > right. > > What I'd like to see is something describing the following: > > - How to use Multipart/mixed > > I think Paul Kyzivat and Dan had some good explanation in this thread > about it. > We should really make proper treatment of multipart/mixed as mandatory > as we can. > This means, being able to understand parse the nested MIME bodies that > you DO support. > At a miminum, an implementation should be able to find in a > Multipart/mixed the SDP > for example. We probably need also to write some recommnedation on > what happens if > there is multiple SDPs in that multipart mixed. I would like to bring up something that isn't discussed much: Content-Disposition. I brought it up earlier in this thread for a slightly different reason. One *should not* look for a particular body part of interest solely based on the Content-Type. Both the content type and the content disposition need to be correct. For instance, a body part with content type of application/sdp should not be considered an offer or answer unless the content-disposition is "session". (This is confused because there are are also defaulting rules for content-disposition.) *In principle* you could have a multipart/mixed that had to parts, both with content-type of application/sdp. This could be quite legal if only one of them had content-disposition of "session" and the other had some other content-disposition. It would be sufficient for the other to have "Content-Disposition:foo;handling=optional". I realize this is obscure, and it isn't likely that anyone will be including an sdp body part that isn't intended to be an offer or answer. But we are writing the specs here, and we ought to be complete and precise about it. > It's not pretty out there. I've seen implementations that don't even > send 415 > when receiving multipart/mixed: they just ignore the payload, and > believe > it's an SDP-less INVITE. They then put an offer in the response, which > the > real offerer believes is an answer. Then all hell breaks loose. > > Some of them do send 415, but without the supported payload type in an > Accept > header in 415. > > > - Multipart/alternative > > I agree with Dan that using Multipart/alternative in the way that was > described > in draft-jennings-sipping-multipart section 5 is in fact harmful. > Especially now that we > are defining capability negotiation. Section 6 would be OK, but now > that SDPng is gone, > it's irrelevant. > > What we really need to say is that multipart/alternative may be used > only when we > are using alternative payload types for the same information. For > example, text/html and > text/xml or whatever. It would be applicable if one day we re-created > another SDPng > for example. The perfect example for that is MESSAGE with text/plain and text/html, quite analogous to an email message. > Section 3.1 explains this relatively well, but is restricted to Offers > (for which we have > no use cases anymore). I think it should instead talk about other > examples (e.g., > text/html, text/xml, or maybe some example with pictures). > > I really believe section 5 goes against the spririt of section 3.1 > (specifically, of > the quote of RFC 2046). What it really has it two application/sdp (one > of them is > encrypted inside a application/pkcs7mime), but really it's still two > application/sdp > > But we should make it clear that it is NOT for negotiating multiple > alternatives of > the same payload type, in particular, not for application/sdp & > application/sdp. > > If we decide to go forward, I'd be happy to help too. I don't have time to take authorship of the document, but I too can contribute some text. Paul >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Thursday, May 10, 2007 09:19 >> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net >> Cc: sip@ietf.org >> Subject: RE: [Sip] Support for Multipart/MIME >> >>>> I have become convinced, through my efforts with RTPSEC, that >>>> multipart/alternative is harmful if it contains multiple SDP parts. >>> Again, I am not in a position to disagree with you ,but is that >>> harmfulness documented somewhere? >> Nope. If we're going to move multipart/* forward in SIP, >> though, I'll be happy to write that section. >> >> -d >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 20:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJ88-0002pp-5N; Thu, 10 May 2007 20:37:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmJ86-0002pk-VG for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 20:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJ86-0002pc-Ln for sip@ietf.org; Thu, 10 May 2007 20:37:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmJ86-0007Ka-7I for sip@ietf.org; Thu, 10 May 2007 20:37:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 17:37:05 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="147402040:sNHT58734081" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4B0b5vK011100; Thu, 10 May 2007 17:37:05 -0700 Received: from dwingwxp (dhcp-128-107-163-206.cisco.com [128.107.163.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B0ax20023951; Fri, 11 May 2007 00:37:03 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'Francois Audet'" Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 17:36:58 -0700 Message-ID: <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4643B58A.3060407@cisco.com> Thread-Index: AceTYW/Klv+XpbSFQYiKAzUiPWIulwAAeWJQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4434; t=1178843825; x=1179707825; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=CE2e6eMmkCTxRHpiPkEhBKWL7PhmcZ94aavDSaOybf0=; b=Bj6Lb2e8R8qiMHmzsMDxzjt/bL2KoCU2XY/euNxKIP5NZwrr62016usBLjVM7h3UmVpt/eA0 /dliff4MlMFQrovCrTH91nLsRZYfj0zrqsOnWJsv+IWYM8G6BZ769NzV; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ... > I would like to bring up something that isn't discussed much: > Content-Disposition. I brought it up earlier in this thread for a > slightly different reason. > > One *should not* look for a particular body part of interest solely > based on the Content-Type. > Both the content type and the content > disposition need to be correct. For instance, a body part > with content > type of application/sdp should not be considered an offer or answer > unless the content-disposition is "session". (This is > confused because there are are also defaulting rules for > content-disposition.) > > *In principle* you could have a multipart/mixed that had to > parts, both > with content-type of application/sdp. This could be quite > legal if only > one of them had content-disposition of "session" and the > other had some > other content-disposition. It would be sufficient for the > other to have > "Content-Disposition:foo;handling=optional". > > I realize this is obscure, and it isn't likely that anyone will be > including an sdp body part that isn't intended to be an offer > or answer. > But we are writing the specs here, and we ought to be complete and > precise about it. Yes, it's obscure, but that's alright. There is the annoying backward compatibility issue with lack of Content-Disposition, too -- RFC3261 section 13.2.1, "Creating the Initial INVITE": > If the Content-Disposition header field is missing, bodies of > Content-Type application/sdp imply the disposition "session", while > other content types imply "render". ... > > > > What we really need to say is that multipart/alternative > > may be used only when we > > are using alternative payload types for the same information. For > > example, text/html and > > text/xml or whatever. It would be applicable if one day > > we re-created another SDPng for example. > > The perfect example for that is MESSAGE with text/plain and > text/html, quite analogous to an email message. That is sufficient justification to include multipart/alternative. -d > > Section 3.1 explains this relatively well, but is > restricted to Offers > > (for which we have > > no use cases anymore). I think it should instead talk about other > > examples (e.g., > > text/html, text/xml, or maybe some example with pictures). > > > > I really believe section 5 goes against the spririt of section 3.1 > > (specifically, of > > the quote of RFC 2046). What it really has it two > application/sdp (one > > of them is > > encrypted inside a application/pkcs7mime), but really > it's still two > > application/sdp > > > > But we should make it clear that it is NOT for > negotiating multiple > > alternatives of > > the same payload type, in particular, not for application/sdp & > > application/sdp. > > > > If we decide to go forward, I'd be happy to help too. > > I don't have time to take authorship of the document, but I too can > contribute some text. > > Paul > > >> -----Original Message----- > >> From: Dan Wing [mailto:dwing@cisco.com] > >> Sent: Thursday, May 10, 2007 09:19 > >> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net > >> Cc: sip@ietf.org > >> Subject: RE: [Sip] Support for Multipart/MIME > >> > >>>> I have become convinced, through my efforts with RTPSEC, that > >>>> multipart/alternative is harmful if it contains multiple > SDP parts. > >>> Again, I am not in a position to disagree with you ,but is that > >>> harmfulness documented somewhere? > >> Nope. If we're going to move multipart/* forward in SIP, > >> though, I'll be happy to write that section. > >> > >> -d > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use > >> sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 21:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKC0-0003yc-NW; Thu, 10 May 2007 21:45:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmKBy-0003yX-W0 for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 21:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKBx-0003yL-Ur for sip@ietf.org; Thu, 10 May 2007 21:45:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmKBw-0005Nn-Ed for sip@ietf.org; Thu, 10 May 2007 21:45:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC722204B5; Fri, 11 May 2007 03:44:33 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-56-4643ca81389f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B08D42047F; Fri, 11 May 2007 03:44:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 03:44:33 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 03:44:22 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> In-Reply-To: <464354C1.6030003@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTJ8VnmL4cp4XTR5CdVn9CqRODrgARURsg References: <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <464354C1.6030003@cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" , "Dan Wing" X-OriginalArrivalTime: 11 May 2007 01:44:33.0513 (UTC) FILETIME=[ECB19D90:01C7936D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The following is not a proposal, but more "brain storming". Would it be helpful to have a SIP header, e.g. Content-Type-List, which would list the different Content-Types in a multipart/* body.=20 A node could then first check that header in order to see whether the multipart/* contains something a specific node is interested in - without having to parse the full multipart/* body first. It could speed up the processing in nodes which may have interest only in a small set of Content-Types. Comments? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 10 22:14:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKel-0007O5-O4; Thu, 10 May 2007 22:14:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmKek-0007Nu-7O for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 22:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmKej-0007Nm-Ta for sip@ietf.org; Thu, 10 May 2007 22:14:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmKej-00012m-KR for sip@ietf.org; Thu, 10 May 2007 22:14:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 19:14:53 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="147435399:sNHT49317156" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4B2ErVG014117; Thu, 10 May 2007 19:14:53 -0700 Received: from dwingwxp (dhcp-128-107-163-206.cisco.com [128.107.163.206]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4B2EqtV006314; Fri, 11 May 2007 02:14:52 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 19:14:54 -0700 Message-ID: <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> Thread-Index: AceTJ8VnmL4cp4XTR5CdVn9CqRODrgARURsgAAELzZA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1776; t=1178849693; x=1179713693; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=adxKsMl4E+cKHBhTwf2zeLPxuWQ6ASl12EbATPOyAcc=; b=PF/+1iexEGZa+ZQVbCCIYua/g/TBlLeAm8MPOPu3NGL04hTqlk9MY3Lq/WE8q4ccf5RJdS0e /rrU2fb9j4IG0jwLDldFJ3a1ykPQ2BIAlhtsEYXzmebzwRK/1CPv7EyIaRHJVEmL/gzlG4h2b4 Mmq2joJFdytuku120O/NtwUII=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org An interesting optimization, but it doesn't appeal to me: * if they're out of sync, which one takes precedence (that is, do I process a Content-Type that isn't listed in the Content-Type-List?) * if a UA knew an intermediate box used Content-Type-List, the UA could use Content-Type-List to make the intermediate box think some sort of Content-Type is not present. That additional content-type might contain the secret of the universe, which the intermediate box really needed to know. * looking for "^Content-Type *:" isn't too hard; you don't really need to bother parsing MIME and looking for nested parts unless there is, in fact, a content-type you care about. Per Paul's message, if you only want ones with Content-Disposition: session, you could look for that string within 4-5 lines of Content-Type; if you found it, then you could parse the MIME in the body. -d > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 10, 2007 6:44 PM > To: Paul Kyzivat; Dan Wing > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi, > > The following is not a proposal, but more "brain storming". > > Would it be helpful to have a SIP header, e.g. > Content-Type-List, which > would list the different Content-Types in a multipart/* body. > > A node could then first check that header in order to see whether the > multipart/* contains something a specific node is interested in - > without having to parse the full multipart/* body first. It > could speed > up the processing in nodes which may have interest only in a small set > of Content-Types. > > Comments? > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 00:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMVN-0006lU-81; Fri, 11 May 2007 00:13:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmMVL-0006lL-Og for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 00:13:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMVL-0006lD-CU for sip@ietf.org; Fri, 11 May 2007 00:13:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMVK-0000F1-N1 for sip@ietf.org; Fri, 11 May 2007 00:13:19 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0A6B4203B3; Fri, 11 May 2007 06:13:18 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-d5-4643ed5d5bb6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DC80A20078; Fri, 11 May 2007 06:13:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 06:13: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 Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 06:13:17 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> In-Reply-To: <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTJ8VnmL4cp4XTR5CdVn9CqRODrgARURsgAAELzZAAA3H+IA== References: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Paul Kyzivat" X-OriginalArrivalTime: 11 May 2007 04:13:17.0769 (UTC) FILETIME=[B3F70390:01C79382] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >* if they're out of sync, which one takes precedence (that=20 >is, do I process a Content-Type that isn't listed in the=20 >Content-Type-List?) The Content-Type contains "multipart/*", while the Content-Type-List contains the types (app/sdp, app/isup, app/whatever etc) within that multipart. Please note that I am talking about SIP headers, not in the MIME bodies (of course, if a MIME body contains another multipart/*, the header could perhaps also be used there). >* if a UA knew an intermediate box used Content-Type-List,=20 >the UA could use Content-Type-List to make the intermediate=20 >box think some sort of Content-Type is not present. That=20 >additional content-type might contain the secret of the=20 >universe, which the intermediate box really needed to know. Well, this depends on the functionality of the middle-box. If the middle-box is going to do some kind of policing, or otherwise verify that the multipart actually contains what is claimed in the Content-Type-List, it will have to parse the multipart anyway. >* looking for "^Content-Type *:" isn't too hard; you don't=20 >really need to bother parsing MIME and looking for nested=20 >parts unless there is, in fact, a content-type you care=20 >about. Per Paul's message, if you only want ones with >Content-Disposition: session, you could look for that string=20 >within 4-5 lines of Content-Type; if you found it, then you=20 >could parse the MIME in the body. I don't think it's that easy. Assume one MIME body contains a SIP message (or part of a SIP message), or any other protocol which uses the Content-Type header, which is not the Content-Type header of the MIME body itself. The same goes for Content-Disposition. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, May 10, 2007 6:44 PM > > To: Paul Kyzivat; Dan Wing > > Cc: Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > >=20 > > Hi, > >=20 > > The following is not a proposal, but more "brain storming". > >=20 > > Would it be helpful to have a SIP header, e.g.=20 > > Content-Type-List, which > > would list the different Content-Types in a multipart/* body.=20 > >=20 > > A node could then first check that header in order to see=20 > whether the > > multipart/* contains something a specific node is interested in -=20 > > without having to parse the full multipart/* body first. It could=20 > > speed up the processing in nodes which may have interest only in a=20 > > small set of Content-Types. > >=20 > > Comments? > >=20 > > Regards, > >=20 > > Christer >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 00:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMjy-0008Q5-35; Fri, 11 May 2007 00:28:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmMjw-0008Ld-TL for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 00:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMjw-0008LV-JW for sip@ietf.org; Fri, 11 May 2007 00:28:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMjw-0001Wd-8n for sip@ietf.org; Fri, 11 May 2007 00:28:24 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2007 00:28:24 -0400 X-IronPort-AV: i="4.14,520,1170651600"; d="scan'208"; a="59959231:sNHT48218270" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4B4SNDi029280; Fri, 11 May 2007 00:28:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4B4SLBg000340; Fri, 11 May 2007 04:28:23 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.1830); Fri, 11 May 2007 00:28:21 -0400 Received: from [10.86.243.60] ([10.86.243.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 00:28:21 -0400 Message-ID: <4643F0E3.5040802@cisco.com> Date: Fri, 11 May 2007 00:28:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 04:28:21.0386 (UTC) FILETIME=[CE9006A0:01C79384] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3320; t=1178857704; x=1179721704; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=j+iMh1VJL0EvqtV8d3uA2Ufd+q5ARNxZmlcyyO6l8IY=; b=eUVk8jbbpOrBqmmijkxXkDK+UwjDjlsd/r4+gF9JixrtW/c0zrzx5D7MiIMd2W03tQiHm/Lq o4PuiyWZXXikOQ7feV3Bx3bI5Y3rXEUBTs+Q0xpf0iCHnqEUCYd27Cwd; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >> * if they're out of sync, which one takes precedence (that >> is, do I process a Content-Type that isn't listed in the >> Content-Type-List?) I'm with Dan on this. Also, this is well trodden ground in email, and they haven't found a need for this. > The Content-Type contains "multipart/*", while the Content-Type-List > contains the types (app/sdp, app/isup, app/whatever etc) within that > multipart. > > Please note that I am talking about SIP headers, not in the MIME bodies > (of course, if a MIME body contains another multipart/*, the header > could perhaps also be used there). There really isn't any difference between sip headers and mime headers. From a mime perspective the entire sip message is just a bunch of mime headers including some that are extension headers. >> * if a UA knew an intermediate box used Content-Type-List, >> the UA could use Content-Type-List to make the intermediate >> box think some sort of Content-Type is not present. That >> additional content-type might contain the secret of the >> universe, which the intermediate box really needed to know. > > Well, this depends on the functionality of the middle-box. > > If the middle-box is going to do some kind of policing, or otherwise > verify that the multipart actually contains what is claimed in the > Content-Type-List, it will have to parse the multipart anyway. > >> * looking for "^Content-Type *:" isn't too hard; you don't >> really need to bother parsing MIME and looking for nested >> parts unless there is, in fact, a content-type you care >> about. Per Paul's message, if you only want ones with >> Content-Disposition: session, you could look for that string >> within 4-5 lines of Content-Type; if you found it, then you >> could parse the MIME in the body. > > I don't think it's that easy. Assume one MIME body contains a SIP > message (or part of a SIP message), or any other protocol which uses the > Content-Type header, which is not the Content-Type header of the MIME > body itself. The same goes for Content-Disposition. IMO the servers that care about what is in the bodies should just bite the bullet and do the necessary parsing. Frankly, middle boxes shouldn't be looking at bodies anyway. Paul > Regards, > > Christer > > > > >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: Thursday, May 10, 2007 6:44 PM >>> To: Paul Kyzivat; Dan Wing >>> Cc: Dale.Worley@comcast.net; sip@ietf.org >>> Subject: RE: [Sip] Support for Multipart/MIME >>> >>> >>> Hi, >>> >>> The following is not a proposal, but more "brain storming". >>> >>> Would it be helpful to have a SIP header, e.g. >>> Content-Type-List, which >>> would list the different Content-Types in a multipart/* body. >>> >>> A node could then first check that header in order to see >> whether the >>> multipart/* contains something a specific node is interested in - >>> without having to parse the full multipart/* body first. It could >>> speed up the processing in nodes which may have interest only in a >>> small set of Content-Types. >>> >>> Comments? >>> >>> Regards, >>> >>> Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 01:34:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNlz-00013h-9p; Fri, 11 May 2007 01:34:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmNly-00011X-0E for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 01:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNlx-00011P-Ij for sip@ietf.org; Fri, 11 May 2007 01:34:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNlw-0008Su-VF for sip@ietf.org; Fri, 11 May 2007 01:34:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 22:34:32 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="420911321:sNHT48241314" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4B5YWVg007477; Thu, 10 May 2007 22:34:32 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4B5YVV1000380; Fri, 11 May 2007 05:34:31 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 22:34:32 -0700 Message-ID: <006701c7938e$0dd2b3e0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTJ8VnmL4cp4XTR5CdVn9CqRODrgARURsgAAELzZAAA3H+IAABkM+A In-Reply-To: <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4331; t=1178861672; x=1179725672; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=rxQFn2a9qBsR/ozEjjX17RkQh50wwmTYQ6YktmI08cw=; b=FvQLPzvc/MB+pCCxg15H6M/xGVT2kKitnXMHYplUZLqbZUha27jSA15OFiwdv+epsCtkzuHI f7A2g7V04KcLSc8vmGiAFqRCGPokZwihgKU+n4aKTUBKk9Pm0mGRGzwa; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 10, 2007 9:13 PM > To: Dan Wing; Paul Kyzivat > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi, > > >* if they're out of sync, which one takes precedence (that > >is, do I process a Content-Type that isn't listed in the > >Content-Type-List?) > > The Content-Type contains "multipart/*", while the Content-Type-List > contains the types (app/sdp, app/isup, app/whatever etc) within that > multipart. > > Please note that I am talking about SIP headers, not in the > MIME bodies > (of course, if a MIME body contains another multipart/*, the header > could perhaps also be used there). Let me clarify my point about that new Content-Type-List header being out of sync with the body. Here is an example -- a SIP header containing, among other things: From: ... To: ... Content-Type-List: application/sdp Content-Type: multipart/mixed; boundary=B and the body contains: --B Content-Type: application/sdp Content-Disposition: session v=0 ... --B Content-Type: application/pidf+xml >* if a UA knew an intermediate box used Content-Type-List, > >the UA could use Content-Type-List to make the intermediate > >box think some sort of Content-Type is not present. That > >additional content-type might contain the secret of the > >universe, which the intermediate box really needed to know. > > Well, this depends on the functionality of the middle-box. > > If the middle-box is going to do some kind of policing, or otherwise > verify that the multipart actually contains what is claimed in the > Content-Type-List, it will have to parse the multipart anyway. Right. Proxies are supposed to ignore the body, so what sort of devices which aren't enforcing policy might benefit from the Content-Type-List optimization? > >* looking for "^Content-Type *:" isn't too hard; you don't > >really need to bother parsing MIME and looking for nested > >parts unless there is, in fact, a content-type you care > >about. Per Paul's message, if you only want ones with > >Content-Disposition: session, you could look for that string > >within 4-5 lines of Content-Type; if you found it, then you > >could parse the MIME in the body. > > I don't think it's that easy. Assume one MIME body contains a SIP > message (or part of a SIP message), or any other protocol > which uses the > Content-Type header, which is not the Content-Type header of the MIME > body itself. The same goes for Content-Disposition. Yes, there can of course be false-positives; the same sort of false positives would occur with Content-Type-List: it could list a content-type which is inside of a MIME part you wouldn't otherwise process (due to the wrong Content-Disposition, for example). -d > Regards, > > Christer > > > > > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, May 10, 2007 6:44 PM > > > To: Paul Kyzivat; Dan Wing > > > Cc: Dale.Worley@comcast.net; sip@ietf.org > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > > > > Hi, > > > > > > The following is not a proposal, but more "brain storming". > > > > > > Would it be helpful to have a SIP header, e.g. > > > Content-Type-List, which > > > would list the different Content-Types in a multipart/* body. > > > > > > A node could then first check that header in order to see > > whether the > > > multipart/* contains something a specific node is interested in - > > > without having to parse the full multipart/* body first. It could > > > speed up the processing in nodes which may have interest > only in a > > > small set of Content-Types. > > > > > > Comments? > > > > > > Regards, > > > > > > Christer > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 01:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNws-00005q-EL; Fri, 11 May 2007 01:45:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmNwr-00005K-1Z for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 01:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmNwq-00005C-Mi for sip@ietf.org; Fri, 11 May 2007 01:45:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmNwp-0001Sd-PK for sip@ietf.org; Fri, 11 May 2007 01:45:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1329D208C8; Fri, 11 May 2007 07:45:47 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-74-4644030a68bf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EA7672041B; Fri, 11 May 2007 07:45:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 07:45: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 Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 07:45:43 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F8606D@esealmw113.eemea.ericsson.se> In-Reply-To: <006701c7938e$0dd2b3e0$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTJ8VnmL4cp4XTR5CdVn9CqRODrgARURsgAAELzZAAA3H+IAABkM+AAAKLfiA= References: <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> <006701c7938e$0dd2b3e0$c5f0200a@amer.cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Dan Wing" , "Paul Kyzivat" X-OriginalArrivalTime: 11 May 2007 05:45:46.0704 (UTC) FILETIME=[9F634D00:01C7938F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan, Couldn't you get this out of sync already today? You get a SIP message with application/sdp, and then the message body contains something else... Regards, Christer =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 11. toukokuuta 2007 8:35 > To: Christer Holmberg (JO/LMF); 'Paul Kyzivat' > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME >=20 > =20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, May 10, 2007 9:13 PM > > To: Dan Wing; Paul Kyzivat > > Cc: Dale.Worley@comcast.net; sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > >=20 > > Hi, > >=20 > > >* if they're out of sync, which one takes precedence (that=20 > is, do I=20 > > >process a Content-Type that isn't listed in the > > >Content-Type-List?) > >=20 > > The Content-Type contains "multipart/*", while the=20 > Content-Type-List=20 > > contains the types (app/sdp, app/isup, app/whatever etc)=20 > within that=20 > > multipart. > >=20 > > Please note that I am talking about SIP headers, not in the MIME=20 > > bodies (of course, if a MIME body contains another multipart/*, the=20 > > header could perhaps also be used there). >=20 > Let me clarify my point about that new Content-Type-List=20 > header being out of sync with the body. Here is an example=20 > -- a SIP header containing, among other things: >=20 > From: ... > To: ... > Content-Type-List: application/sdp > Content-Type: multipart/mixed; boundary=3DB >=20 > and the body contains: >=20 > --B > Content-Type: application/sdp > Content-Disposition: session >=20 > v=3D0 > ... >=20 > --B > Content-Type: application/pidf+xml > =20 > > ... > --B-- >=20 > In such a situation, a device which supports=20 > Content-Type-List in an effort to optimize its MIME parsing,=20 > wouldn't know there is a "Content-Type: > application/pidf+xml" in the body. >=20 >=20 > > >* if a UA knew an intermediate box used Content-Type-List, the UA=20 > > >could use Content-Type-List to make the intermediate box=20 > think some=20 > > >sort of Content-Type is not present. That additional content-type=20 > > >might contain the secret of the universe, which the=20 > intermediate box=20 > > >really needed to know. > >=20 > > Well, this depends on the functionality of the middle-box. > >=20 > > If the middle-box is going to do some kind of policing, or=20 > otherwise=20 > > verify that the multipart actually contains what is claimed in the=20 > > Content-Type-List, it will have to parse the multipart anyway. >=20 > Right. >=20 > Proxies are supposed to ignore the body, so what sort of=20 > devices which aren't enforcing policy might benefit from the=20 > Content-Type-List optimization? >=20 > > >* looking for "^Content-Type *:" isn't too hard; you don't really=20 > > >need to bother parsing MIME and looking for nested parts=20 > unless there=20 > > >is, in fact, a content-type you care about. Per Paul's=20 > message, if=20 > > >you only want ones with > > >Content-Disposition: session, you could look for that=20 > string within=20 > > >4-5 lines of Content-Type; if you found it, then you could=20 > parse the=20 > > >MIME in the body. > >=20 > > I don't think it's that easy. Assume one MIME body contains a SIP=20 > > message (or part of a SIP message), or any other protocol=20 > which uses=20 > > the Content-Type header, which is not the Content-Type=20 > header of the=20 > > MIME body itself. The same goes for Content-Disposition. >=20 > Yes, there can of course be false-positives; the same sort of=20 > false positives would occur with Content-Type-List: it could=20 > list a content-type which is inside of a MIME part you=20 > wouldn't otherwise process (due to the wrong=20 > Content-Disposition, for example). >=20 > -d >=20 >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: Thursday, May 10, 2007 6:44 PM > > > > To: Paul Kyzivat; Dan Wing > > > > Cc: Dale.Worley@comcast.net; sip@ietf.org > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > The following is not a proposal, but more "brain storming". > > > >=20 > > > > Would it be helpful to have a SIP header, e.g.=20 > > > > Content-Type-List, which > > > > would list the different Content-Types in a multipart/* body.=20 > > > >=20 > > > > A node could then first check that header in order to see > > > whether the > > > > multipart/* contains something a specific node is=20 > interested in -=20 > > > > without having to parse the full multipart/* body=20 > first. It could=20 > > > > speed up the processing in nodes which may have interest > > only in a > > > > small set of Content-Types. > > > >=20 > > > > Comments? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 01:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3N-0003Gf-8U; Fri, 11 May 2007 01:52:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmO3L-0003Ed-45 for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 01:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmO3K-0003D6-Nq for sip@ietf.org; Fri, 11 May 2007 01:52:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmO3J-0002XH-8l for sip@ietf.org; Fri, 11 May 2007 01:52:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BEA0920BD1; Fri, 11 May 2007 07:52:28 +0200 (CEST) X-AuditID: c1b4fb3c-a7ce9bb0000073d5-bf-4644049c303d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A81202041B; Fri, 11 May 2007 07:52:28 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 07:52:28 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 07:52:26 +0200 Message-ID: <7374777208BDC7449D5620EF9423256703F8608C@esealmw113.eemea.ericsson.se> In-Reply-To: <4643F0E3.5040802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceThNFS46GzuMWkQ/mZJ2NE3Nc2BQACtDSw References: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> <4643F0E3.5040802@cisco.com> From: "Christer Holmberg \(JO/LMF\)" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 May 2007 05:52:28.0431 (UTC) FILETIME=[8ED5F9F0:01C79390] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>* if they're out of sync, which one takes precedence (that is, do I=20 >>>process a Content-Type that isn't listed in the >>>Content-Type-List?) >=20 >I'm with Dan on this. Also, this is well trodden ground in=20 >email, and they haven't found a need for this. Email does not have the same real-time requirements which SIP has. >>The Content-Type contains "multipart/*", while the Content-Type-List=20 >>contains the types (app/sdp, app/isup, app/whatever etc)=20 >>within that multipart. >>=20 >>Please note that I am talking about SIP headers, not in the MIME=20 >>bodies (of course, if a MIME body contains another multipart/*, the=20 >>header could perhaps also be used there). >=20 >There really isn't any difference between sip headers and=20 >mime headers.=20 >From a mime perspective the entire sip message is just a=20 >bunch of mime headers including some that are extension headers. My point was that you can't determine what types of MIME bodies you have simply by taking the whole SIP message and performing a string search on "Content-Type". Because, some of the Content-Types you will find may not describe what is in a MIME body - it may be part of the MIME body data. -----boundary Content-Type: protocol/sip To: blahblah@telecom.com From: dododo@telecom.com Content-Type: application/pidf+xml =20 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOST-0003mi-E5; Fri, 11 May 2007 02:18:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmOSR-0003hZ-6N for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 02:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOSQ-0003fq-Fn for sip@ietf.org; Fri, 11 May 2007 02:18:26 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOSO-00062s-6T for sip@ietf.org; Fri, 11 May 2007 02:18:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 23:18:23 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="420920056:sNHT41108850" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4B6INue003494; Thu, 10 May 2007 23:18:23 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4B6IMV1010798; Fri, 11 May 2007 06:18:22 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Thu, 10 May 2007 23:18:22 -0700 Message-ID: <006d01c79394$2d8b5f60$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceThNFS46GzuMWkQ/mZJ2NE3Nc2BQACtDSwAAERPKA= In-Reply-To: <7374777208BDC7449D5620EF9423256703F8608C@esealmw113.eemea.ericsson.se> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=604; t=1178864303; x=1179728303; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=uvErg63VkNBTzbnhCYiR9QXkeRgoxcU7enP+zILbjWc=; b=qOBFA6iQKoIyUNY4tqM7C+mOhzweg+lABePkGLvR9mJ/dJspb5feLDX8uktkyVDLLRwTNoe8 O3EAYc0L6ioMsizk9Sm749q6FA4qq4IG8lnTX0EN1OKFmQYJc89PT9X0; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > My point was that you can't determine what types of MIME > bodies you have simply by taking the whole SIP message and > performing a string search on "Content-Type". Because, some > of the Content-Types you will find may not describe what > is in a MIME body - it may be part of the MIME body data. Fully agreed that you could get false positives from such a test! But you'll never get a false negative from such a test. My point was that if you're trying to optimize, and also needing to avoid a UA that is lying, doing a search of the Content-Type strings is what you want. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 08:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmU75-0000RH-QQ; Fri, 11 May 2007 08:20:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmU73-0000Qt-Oh for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 08:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmU73-0000Ql-F7 for sip@ietf.org; Fri, 11 May 2007 08:20:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmU71-0001Nf-Sc for sip@ietf.org; Fri, 11 May 2007 08:20:45 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 11 May 2007 05:20:44 -0700 X-IronPort-AV: i="4.14,522,1170662400"; d="scan'208"; a="485162702:sNHT51390076" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4BCKhLK027085; Fri, 11 May 2007 05:20:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4BCKM0Q001772; Fri, 11 May 2007 12:20:43 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.1830); Fri, 11 May 2007 08:20:33 -0400 Received: from [10.86.243.60] ([10.86.243.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 08:20:33 -0400 Message-ID: <46445F90.3010804@cisco.com> Date: Fri, 11 May 2007 08:20:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> <006701c7938e$0dd2b3e0$c5f0200a@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F8606D@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256703F8606D@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 12:20:33.0340 (UTC) FILETIME=[C5B91FC0:01C793C6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5415; t=1178886043; x=1179750043; c=relaxed/simple; s=sjdkim7002; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=mWXqoszg313fJKyo5JV7YsDgLqXoCuO0sUjdWAQD/qk=; b=WYFi6O30PlTmt+IsW8L4HESQ0x6FG97Kl3mv64foaXPpQTBRarkiB5uDvQMq75hyGfxgQePj uHBjbCLxa2pklcpTz4Ecupp3+shuDDwDWZld2Qwiyzj5snx6E1fnBovM; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi Dan, > > Couldn't you get this out of sync already today? > > You get a SIP message with application/sdp, and then the message body > contains something else... No you can't. If the sip message has Content-Type:application/sdp then *by definition* the body contains sdp. If it doesn't look like sdp then it is just syntactically incorrect sdp. The Content-Type in the message is not redundant with one in the body - it is the one for the body. Paul > Regards, > > Christer > > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: 11. toukokuuta 2007 8:35 >> To: Christer Holmberg (JO/LMF); 'Paul Kyzivat' >> Cc: Dale.Worley@comcast.net; sip@ietf.org >> Subject: RE: [Sip] Support for Multipart/MIME >> >> >> >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: Thursday, May 10, 2007 9:13 PM >>> To: Dan Wing; Paul Kyzivat >>> Cc: Dale.Worley@comcast.net; sip@ietf.org >>> Subject: RE: [Sip] Support for Multipart/MIME >>> >>> >>> Hi, >>> >>>> * if they're out of sync, which one takes precedence (that >> is, do I >>>> process a Content-Type that isn't listed in the >>>> Content-Type-List?) >>> The Content-Type contains "multipart/*", while the >> Content-Type-List >>> contains the types (app/sdp, app/isup, app/whatever etc) >> within that >>> multipart. >>> >>> Please note that I am talking about SIP headers, not in the MIME >>> bodies (of course, if a MIME body contains another multipart/*, the >>> header could perhaps also be used there). >> Let me clarify my point about that new Content-Type-List >> header being out of sync with the body. Here is an example >> -- a SIP header containing, among other things: >> >> From: ... >> To: ... >> Content-Type-List: application/sdp >> Content-Type: multipart/mixed; boundary=B >> >> and the body contains: >> >> --B >> Content-Type: application/sdp >> Content-Disposition: session >> >> v=0 >> ... >> >> --B >> Content-Type: application/pidf+xml >> >> >> > ... >> --B-- >> >> In such a situation, a device which supports >> Content-Type-List in an effort to optimize its MIME parsing, >> wouldn't know there is a "Content-Type: >> application/pidf+xml" in the body. >> >> >>>> * if a UA knew an intermediate box used Content-Type-List, the UA >>>> could use Content-Type-List to make the intermediate box >> think some >>>> sort of Content-Type is not present. That additional content-type >>>> might contain the secret of the universe, which the >> intermediate box >>>> really needed to know. >>> Well, this depends on the functionality of the middle-box. >>> >>> If the middle-box is going to do some kind of policing, or >> otherwise >>> verify that the multipart actually contains what is claimed in the >>> Content-Type-List, it will have to parse the multipart anyway. >> Right. >> >> Proxies are supposed to ignore the body, so what sort of >> devices which aren't enforcing policy might benefit from the >> Content-Type-List optimization? >> >>>> * looking for "^Content-Type *:" isn't too hard; you don't really >>>> need to bother parsing MIME and looking for nested parts >> unless there >>>> is, in fact, a content-type you care about. Per Paul's >> message, if >>>> you only want ones with >>>> Content-Disposition: session, you could look for that >> string within >>>> 4-5 lines of Content-Type; if you found it, then you could >> parse the >>>> MIME in the body. >>> I don't think it's that easy. Assume one MIME body contains a SIP >>> message (or part of a SIP message), or any other protocol >> which uses >>> the Content-Type header, which is not the Content-Type >> header of the >>> MIME body itself. The same goes for Content-Disposition. >> Yes, there can of course be false-positives; the same sort of >> false positives would occur with Content-Type-List: it could >> list a content-type which is inside of a MIME part you >> wouldn't otherwise process (due to the wrong >> Content-Disposition, for example). >> >> -d >> >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg (JO/LMF) >>>>> [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Thursday, May 10, 2007 6:44 PM >>>>> To: Paul Kyzivat; Dan Wing >>>>> Cc: Dale.Worley@comcast.net; sip@ietf.org >>>>> Subject: RE: [Sip] Support for Multipart/MIME >>>>> >>>>> >>>>> Hi, >>>>> >>>>> The following is not a proposal, but more "brain storming". >>>>> >>>>> Would it be helpful to have a SIP header, e.g. >>>>> Content-Type-List, which >>>>> would list the different Content-Types in a multipart/* body. >>>>> >>>>> A node could then first check that header in order to see >>>> whether the >>>>> multipart/* contains something a specific node is >> interested in - >>>>> without having to parse the full multipart/* body >> first. It could >>>>> speed up the processing in nodes which may have interest >>> only in a >>>>> small set of Content-Types. >>>>> >>>>> Comments? >>>>> >>>>> Regards, >>>>> >>>>> Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 08:25:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUBP-00061k-00; Fri, 11 May 2007 08:25:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmUBN-00061f-VN for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 08:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUBN-00061X-Ll for sip@ietf.org; Fri, 11 May 2007 08:25:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUBM-0001pF-EZ for sip@ietf.org; Fri, 11 May 2007 08:25:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2007 08:25:12 -0400 X-IronPort-AV: i="4.14,522,1170651600"; d="scan'208"; a="59984305:sNHT44141524" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4BCPCoD001522; Fri, 11 May 2007 08:25:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4BCPC5f022965; Fri, 11 May 2007 12:25:12 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.1830); Fri, 11 May 2007 08:25:12 -0400 Received: from [10.86.243.60] ([10.86.243.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 08:25:11 -0400 Message-ID: <464460A6.3060408@cisco.com> Date: Fri, 11 May 2007 08:25:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85F39@esealmw113.eemea.ericsson.se> <118a01c79372$29fc3da0$c4a36b80@amer.cisco.com> <7374777208BDC7449D5620EF9423256703F85F6E@esealmw113.eemea.ericsson.se> <4643F0E3.5040802@cisco.com> <7374777208BDC7449D5620EF9423256703F8608C@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256703F8608C@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 12:25:11.0537 (UTC) FILETIME=[6B8A9E10:01C793C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1026; t=1178886312; x=1179750312; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=+ndUwLmHkfCcGvW0j1TNI9VFUwhgqeonV8KLBdPwa9k=; b=TPwa+zhmJnWXWS0wkuafeJMkWcnA8TIzpI6ZvvvOkTIQqVx6RyVuF/YRIAvOXdwEYzgt9Hu2 xqkiDnXUNmsDXaP0GpgXvXi1hxxbmCfP6TV3BZekOtDRKJTG/usFBn6b; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sip@ietf.org, Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > My point was that you can't determine what types of MIME bodies you have > simply by taking the whole SIP message and performing a string search on > "Content-Type". Because, some of the Content-Types you will find may not > describe what is in a MIME body - it may be part of the MIME body data. All that you need to do is reduce unnecessary parsing to an acceptable degree. If all you care about is sdp, then it is probably sufficient to search the body for the string "application/sdp", and only parse the body looking for sdp if you find that. Now and then you may encounter a body that contains "application/sdp" without actually containing an offer or answer. But as long as that is rare there will probably be no problem. This puts the optimization entirely on the parser without requiring any changes by those that add bodies. That is a good thing. It also keeps the size of the message from increasing further, which is also a good thing. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 12:12:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXjV-0000z9-SC; Fri, 11 May 2007 12:12:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmXjU-0000vD-Rh for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXjU-0000uu-H3 for sip@ietf.org; Fri, 11 May 2007 12:12:40 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmXjU-0001QP-8v for sip@ietf.org; Fri, 11 May 2007 12:12:40 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BGCUh18999; Fri, 11 May 2007 16:12:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 11:12:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF106B9EF4@zrc2hxm0.corp.nortel.com> In-reply-to: <4643B58A.3060407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTYXX0j4xcwlbwRRqzfesm3NPP+QAhWFOQ References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org, Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I think what we need to do is describe what you are explaining here, but we need to make sure that we don't introduce backward compatibility problems. (e.g., maybe if Content-disposition: session is not present, it is assumed to mean session?) > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, May 10, 2007 17:15 > To: Audet, Francois (SC100:3055) > Cc: Dan Wing; Christer Holmberg (JO/LMF);=20 > Dale.Worley@comcast.net; sip@ietf.org > > Subject: Re: [Sip] Support for Multipart/MIME > I would like to bring up something that isn't discussed much:=20 > Content-Disposition. I brought it up earlier in this thread=20 > for a slightly different reason. >=20 > One *should not* look for a particular body part of interest=20 > solely based on the Content-Type. Both the content type and=20 > the content disposition need to be correct. For instance, a=20 > body part with content type of application/sdp should not be=20 > considered an offer or answer unless the content-disposition=20 > is "session". (This is confused because there are are also=20 > defaulting rules for content-disposition.) >=20 > *In principle* you could have a multipart/mixed that had to=20 > parts, both with content-type of application/sdp. This could=20 > be quite legal if only one of them had content-disposition of=20 > "session" and the other had some other content-disposition.=20 > It would be sufficient for the other to have=20 > "Content-Disposition:foo;handling=3Doptional". >=20 > I realize this is obscure, and it isn't likely that anyone=20 > will be including an sdp body part that isn't intended to be=20 > an offer or answer.=20 > But we are writing the specs here, and we ought to be=20 > complete and precise about it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 12:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXkP-0002Dj-Pu; Fri, 11 May 2007 12:13:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmXkO-0002Db-13 for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXkN-0002DR-NU for sip@ietf.org; Fri, 11 May 2007 12:13:35 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmXkM-0001Ud-Gw for sip@ietf.org; Fri, 11 May 2007 12:13:35 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BGDUh19170; Fri, 11 May 2007 16:13:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 11:13:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF106B9EFA@zrc2hxm0.corp.nortel.com> In-reply-to: <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTYW/Klv+XpbSFQYiKAzUiPWIulwAAeWJQACD4liA= References: <4643B58A.3060407@cisco.com> <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > > > What we really need to say is that multipart/alternative may be=20 > > > used only when we > > > are using alternative payload types for the same=20 > information. For=20 > > > example, text/html and > > > text/xml or whatever. It would be applicable if one day we=20 > > > re-created another SDPng for example. > >=20 > > The perfect example for that is MESSAGE with text/plain and=20 > text/html,=20 > > quite analogous to an email message. >=20 > That is sufficient justification to include multipart/alternative. Exactly what I had in mind. I was suggesting we replace the SRTP example in=20 the document with this example. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 12:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYBK-0002bQ-GN; Fri, 11 May 2007 12:41:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmYBJ-0002bK-Ck for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:41:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYBJ-0002bC-21 for sip@ietf.org; Fri, 11 May 2007 12:41:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmYBH-0000Ou-LK for sip@ietf.org; Fri, 11 May 2007 12:41:24 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 11 May 2007 09:41:18 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="169567:sNHT20816826" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4BGfIKi010358; Fri, 11 May 2007 09:41:18 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4BGfHV1010431; Fri, 11 May 2007 16:41:18 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 09:41:17 -0700 Message-ID: <00ee01c793eb$32e7acf0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF106B9EF4@zrc2hxm0.corp.nortel.com> Thread-index: AceTYXX0j4xcwlbwRRqzfesm3NPP+QAhWFOQAAENo1A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2349; t=1178901678; x=1179765678; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=n+ekWS58HmbY45y5JCTZSBTh0f4hX/Gvy1KPYRN4m1s=; b=lD5ZEjDgspWAJ8+iUhLSiao26oXXFDb/sfN+0ubQRpTeTWmMmp3bBkzxjXP5JVC0z6/B9sl4 wa9FcBUmfXBU9xCzp9ULqbg2kSXUqctjz5OP46Ux/dWnkHzSXqU00a/r; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Friday, May 11, 2007 9:12 AM > To: Paul Kyzivat > Cc: Dan Wing; Christer Holmberg (JO/LMF); > Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > I think what we need to do is describe what you are > explaining here, but > we need to make sure that we don't introduce backward compatibility > problems. > > (e.g., maybe if Content-disposition: session is not present, it is > assumed to mean session?) RFC3261 says that already, on page 80: If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition "session", while other content types imply "render". -d > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, May 10, 2007 17:15 > > To: Audet, Francois (SC100:3055) > > Cc: Dan Wing; Christer Holmberg (JO/LMF); > > Dale.Worley@comcast.net; sip@ietf.org > > > > Subject: Re: [Sip] Support for Multipart/MIME > > I would like to bring up something that isn't discussed much: > > Content-Disposition. I brought it up earlier in this thread > > for a slightly different reason. > > > > One *should not* look for a particular body part of interest > > solely based on the Content-Type. Both the content type and > > the content disposition need to be correct. For instance, a > > body part with content type of application/sdp should not be > > considered an offer or answer unless the content-disposition > > is "session". (This is confused because there are are also > > defaulting rules for content-disposition.) > > > > *In principle* you could have a multipart/mixed that had to > > parts, both with content-type of application/sdp. This could > > be quite legal if only one of them had content-disposition of > > "session" and the other had some other content-disposition. > > It would be sufficient for the other to have > > "Content-Disposition:foo;handling=optional". > > > > I realize this is obscure, and it isn't likely that anyone > > will be including an sdp body part that isn't intended to be > > an offer or answer. > > But we are writing the specs here, and we ought to be > > complete and precise about it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 12:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYFn-0005pU-1f; Fri, 11 May 2007 12:46:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmYFl-0005pK-0O for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:46:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYFk-0005pC-N3 for sip@ietf.org; Fri, 11 May 2007 12:46:00 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmYFj-0004nt-Eh for sip@ietf.org; Fri, 11 May 2007 12:46:00 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4BGjqh25123; Fri, 11 May 2007 16:45:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 11:45:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF106B9F93@zrc2hxm0.corp.nortel.com> In-reply-to: <00ee01c793eb$32e7acf0$c5f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTYXX0j4xcwlbwRRqzfesm3NPP+QAhWFOQAAENo1AAAC+aQA== References: <1ECE0EB50388174790F9694F77522CCF106B9EF4@zrc2hxm0.corp.nortel.com> <00ee01c793eb$32e7acf0$c5f0200a@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here you go. Thanks.=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Friday, May 11, 2007 09:41 > To: Audet, Francois (SC100:3055); 'Paul Kyzivat' > Cc: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net;=20 > sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Friday, May 11, 2007 9:12 AM > > To: Paul Kyzivat > > Cc: Dan Wing; Christer Holmberg (JO/LMF); Dale.Worley@comcast.net;=20 > > sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > > I think what we need to do is describe what you are=20 > explaining here,=20 > > but we need to make sure that we don't introduce backward=20 > > compatibility problems. > >=20 > > (e.g., maybe if Content-disposition: session is not present, it is=20 > > assumed to mean session?) >=20 > RFC3261 says that already, on page 80: >=20 > If the Content-Disposition header field is missing, bodies of > Content-Type application/sdp imply the disposition "session", while > other content types imply "render". >=20 > -d >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Thursday, May 10, 2007 17:15 > > > To: Audet, Francois (SC100:3055) > > > Cc: Dan Wing; Christer Holmberg (JO/LMF);=20 > Dale.Worley@comcast.net;=20 > > > sip@ietf.org > > > > > > Subject: Re: [Sip] Support for Multipart/MIME I would=20 > like to bring=20 > > > up something that isn't discussed much: > > > Content-Disposition. I brought it up earlier in this thread for a=20 > > > slightly different reason. > > >=20 > > > One *should not* look for a particular body part of=20 > interest solely=20 > > > based on the Content-Type. Both the content type and the content=20 > > > disposition need to be correct. For instance, a body part with=20 > > > content type of application/sdp should not be considered=20 > an offer or=20 > > > answer unless the content-disposition is "session". (This is=20 > > > confused because there are are also defaulting rules for=20 > > > content-disposition.) > > >=20 > > > *In principle* you could have a multipart/mixed that had=20 > to parts,=20 > > > both with content-type of application/sdp. This could be=20 > quite legal=20 > > > if only one of them had content-disposition of "session" and the=20 > > > other had some other content-disposition. > > > It would be sufficient for the other to have=20 > > > "Content-Disposition:foo;handling=3Doptional". > > >=20 > > > I realize this is obscure, and it isn't likely that=20 > anyone will be=20 > > > including an sdp body part that isn't intended to be an offer or=20 > > > answer. > > > But we are writing the specs here, and we ought to be=20 > complete and=20 > > > precise about it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 15:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb91-0003du-Nu; Fri, 11 May 2007 15:51:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hmb8M-0001m1-5J for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmb8L-0001k9-7z; Fri, 11 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hmb8K-0005RX-GE; Fri, 11 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6D79417600; Fri, 11 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hmb7q-0000EQ-62; Fri, 11 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 11 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-answermode-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : Requesting Answering Modes for the Session Initiation Protocol (SIP) Author(s) : D. Willis, A. Allen Filename : draft-ietf-sip-answermode-03.txt Pages : 25 Date : 2007-5-11 This document defines two SIP extension header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-answermode-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-answermode-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-11140805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-answermode-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-answermode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-11140805.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri May 11 17:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcSe-0007Ae-KX; Fri, 11 May 2007 17:15:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmcSc-0007AQ-Md for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 17:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmcSc-0007AD-BS for sip@ietf.org; Fri, 11 May 2007 17:15:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmcSa-0004fY-Rk for sip@ietf.org; Fri, 11 May 2007 17:15:34 -0400 Received: from [64.101.172.158] ([64.101.172.158]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4BKMnwh022630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 11 May 2007 15:22:50 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40E7C551-BB0E-498D-98C3-AB982A81E5CA@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 11 May 2007 16:15:20 -0500 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-answermode-03.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 11, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol > Working Group of the IETF. > > Title : Requesting Answering Modes for the Session Initiation > Protocol (SIP) > Author(s) : D. Willis, A. Allen > Filename : draft-ietf-sip-answermode-03.txt > Pages : 25 > Date : 2007-5-11 > This is identical to version-02 that cleared WGLC, except that the "requirements" section was removed, since a good many people thought it added no value and the PROTO Shepherd objected to using RFC 2119 requirements language in the requirements section. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 21:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgih-0005bn-64; Fri, 11 May 2007 21:48:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hmgif-0005be-Jz for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 21:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgif-0005bW-02 for sip@ietf.org; Fri, 11 May 2007 21:48:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmgie-0003gj-H7 for sip@ietf.org; Fri, 11 May 2007 21:48:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 11 May 2007 18:48:24 -0700 X-IronPort-AV: i="4.14,525,1170662400"; d="scan'208"; a="485345446:sNHT47714906" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4C1mNID024574; Fri, 11 May 2007 18:48:23 -0700 Received: from [192.168.1.2] (sjc-vpn3-1029.cisco.com [10.21.68.5]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4C1mNaI002830; Sat, 12 May 2007 01:48:23 GMT In-Reply-To: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> References: <0c1401c7926e$6872f290$c4a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Support for Multipart/MIME Date: Fri, 11 May 2007 18:47:43 -0700 To: Dan Wing , SIP X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4276; t=1178934503; x=1179798503; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=AMqNW69t4JpySTt1PsyH7VIRj7HziuoNC+c8PcfaeAs=; b=BdqDkPeBmg5QOl7yAc6bqD2pUcWcySbstkfMXf33srR/x9CvL+GEg1hM7oL+XAPMjPur0G6r A+tIxCQ1uyzRiVtHw0W2t88MW2dt/aoTJLMIUxsZr2y83jeWRTmTo1pS; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Dan Wing , "Christer Holmberg \(\(JO/LMF\)\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I want to make it clear that I view draft-ietf-mmusic-sdp-capability- negotiation as a better solution to the selecting RTP / SRTP problem that the draft-jennings-sipping-multipart. (draft-jennings-sipping- multipart was premised on the idea that the SRTP keys would be transported with S/MIME which is not as good a solution as the DTLS solutions). More importantly, the RTP/SEC bofs and MMUSIC WG selected draft-ietf-mmusic-sdp-capability-negotiation as the way forward the problem of saying you can do RTP and SRTP but would prefer SRTP. I don't want to be opening that debate or anything about transitions to the SDPng. However, even thought we don't need multipart for the above problems - I still think we need it so that we have some extensibility model for SIP body parts. Cullen PS ... The picking which body to use is not hard - for mutlipart/ alternative you use the last one that you understand. On May 9, 2007, at 12:15 PM, Dan Wing wrote: > The now-expired draft > http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 > explored > multipart/alternative. One difficulty, however, is what does it > mean to say > "can understand a part". > > This is easy if one part is SDP and another part is SDPng. If you > understand SDPng, you process it; if you don't, you process the SDP. > > However, it's really hard if one part is SDP and another part is > also SDP -- > in some cases we would like the answerer to "pick the better SDP". > At the > time, we were considering multipart/alternative as a way to offer RTP > (RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at > all. > Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior > solution to sending an offer containing RTP and SRTP. > > I suppose we could avoid the difficulty by prohibiting identical > Content-Types in the alternatives. > > -d > > >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) >> [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, May 03, 2007 3:50 AM >> To: Dale.Worley@comcast.net; sip@ietf.org >> Subject: RE: [Sip] Support for Multipart/MIME >> >> >> Hi, >> >> Multipart/alternative is interesting. I guess that, for SDP, >> it could be >> used to provide different "offer alternatives". I think it >> would be good >> to compare it against some of the other grouping/alternative >> mechanisms >> we have defined for that purpose. >> >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >>> Sent: 30. huhtikuuta 2007 19:13 >>> To: sip@ietf.org >>> Subject: Re: [Sip] Support for Multipart/MIME >>> >>> From: Cullen Jennings >>> >>> I think the WG should consider an update to 3261 (likely >>> done through >>> the process Keith has proposed) that makes this multipart/MIME >>> mandatory to implement. >>> >>> I assume that the requirement is that if a message has a >>> multipart/alternative body, and the UA is capable of >>> understanding one part of the body, then it must be able to >>> extract that part and use it to process the message. >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 21:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgmf-0008T4-JG; Fri, 11 May 2007 21:52:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hmgmd-0008Sw-ET for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 21:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmgmd-0008So-4u for sip@ietf.org; Fri, 11 May 2007 21:52:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmgma-00069Y-S9 for sip@ietf.org; Fri, 11 May 2007 21:52:31 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 May 2007 18:52:28 -0700 X-IronPort-AV: i="4.14,525,1170662400"; d="scan'208"; a="147962558:sNHT39906810" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4C1qSRf007125; Fri, 11 May 2007 18:52:28 -0700 Received: from [192.168.1.2] (sjc-vpn3-1029.cisco.com [10.21.68.5]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4C1qB20026649; Sat, 12 May 2007 01:52:19 GMT In-Reply-To: <00af01c78763$9dc98410$800101df@acmepacket.com> References: <20070418183921.E4B2A1058039@spi01.csee.onr.siteprotect.com> <77CDA802-2142-4D1A-993A-CC189538858C@softarmor.com> <00af01c78763$9dc98410$800101df@acmepacket.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B8384B5-1A66-4912-BF47-39731FB63349@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] sip tcp connection Date: Fri, 11 May 2007 18:51:31 -0700 To: Hadriel Kaplan X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=484; t=1178934748; x=1179798748; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20sip=20tcp=20connection |Sender:=20; bh=Missbx/vW996av6mfCYBzQkzvK19hlZdJK6VheAe+ug=; b=rFogTIBhWq/EKYClovIg10gbvpXRA2fg3XQTZKhtul5aMd3my1N6H0WquJBAMZFMLW2L0Hzq KHZW2zUmOFYckhRbCfT+MlaLlMOh+8E0RZ5YTvJN9Qp2yX4nN3fevlB85OKm/VsE+YCCB5XKoa C1IFmDVNnmqpeFwmp+SeIhW8Q=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sip@ietf.org, "'Frank W. Miller'" , 'jiang mingda' , 'Dean Willis' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Apr 25, 2007, at 11:00 AM, Hadriel Kaplan wrote: > I was also surprised and confused as to why TCP-reuse had been > pulled out of > connect-reuse. > > I am not clear why any argument which includes "a middle-man can > hijack it" > should mean a mechanism cannot be allowed in a draft. (unless the > mechanism's purpose is to be a security mechanism, which this one > isn't) The problem was that an "off path attacker with no credentials" could hijack it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 11 21:54:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgoS-0002PB-62; Fri, 11 May 2007 21:54:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HmgoR-0002P6-Bn for sip-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 21:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmgoR-0002Oy-1h for sip@ietf.org; Fri, 11 May 2007 21:54:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmgoP-0007LB-K1 for sip@ietf.org; Fri, 11 May 2007 21:54:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 May 2007 18:54:21 -0700 X-IronPort-AV: i="4.14,525,1170662400"; d="scan'208"; a="147962881:sNHT41493933" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4C1sKTc024053 for ; Fri, 11 May 2007 18:54:21 -0700 Received: from [192.168.1.2] (sjc-vpn3-1029.cisco.com [10.21.68.5]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4C1sK20027184 for ; Sat, 12 May 2007 01:54:20 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87050603-BA85-4976-B85F-9F399EED9D8A@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Fwd: ID Tracker State Update Notice: draft-ietf-sip-mib Date: Fri, 11 May 2007 18:53:40 -0700 To: SIP X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=224; t=1178934861; x=1179798861; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Fwd=3A=20ID=20Tracker=20State=20Update=20Noti ce=3A=20draft-ietf-sip-mib |Sender:=20; bh=E8vyM60y05qWcjHg+0SCYYStvBDtQd1Wt9/zeMoKXcM=; b=FWDht8tVCEkyRCkdUFr7reEewMqEZugvHPH4ibzgnvi+AWLdSU806hikhRCaoRBL0d4J5Jtj /2ndd65FY/FNl+S/hVzQKtHiDa3N3WclCYXjGxXJuvUXWjEmLcoyW/34; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 2, 2007, at 10:55 AM, Dean Willis wrote: > > I'd like to say "Congratulations" to the whole working group, and > especially to Kevin and Jean-Francois. Yes a special thanks to them and Dan Romascanu too. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 01:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTJh-00030b-6W; Mon, 14 May 2007 01:41:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnTJg-00030W-9T for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 01:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTJf-00030O-P6 for sip@ietf.org; Mon, 14 May 2007 01:41:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnTJe-00009k-5R for sip@ietf.org; Mon, 14 May 2007 01:41:51 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CBA8D211AB; Mon, 14 May 2007 07:41:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-d6-4647f69645cf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B108B211A8; Mon, 14 May 2007 07:41:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 07:41:42 +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 Subject: RE: [Sip] Support for Multipart/MIME Date: Mon, 14 May 2007 07:41:38 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704076AA4@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF106B9EFA@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AceTYW/Klv+XpbSFQYiKAzUiPWIulwAAeWJQACD4liAAJRcQwA== References: <4643B58A.3060407@cisco.com> <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106B9EFA@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg \(JO/LMF\)" To: "Francois Audet" , "Dan Wing" , "Paul Kyzivat" X-OriginalArrivalTime: 14 May 2007 05:41:42.0443 (UTC) FILETIME=[8D0947B0:01C795EA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 > > > > What we really need to say is that=20 > multipart/alternative may be=20 > > > > used only when we > > > > are using alternative payload types for the same > > information. For > > > > example, text/html and > > > > text/xml or whatever. It would be applicable if one day we=20 > > > > re-created another SDPng for example. > > >=20 > > > The perfect example for that is MESSAGE with text/plain and > > text/html, > > > quite analogous to an email message. > >=20 > > That is sufficient justification to include multipart/alternative. >=20 > Exactly what I had in mind. I was suggesting we replace the=20 > SRTP example in the document with this example. I think the document should also describe SDP, and if someone thinks alternative doesn't work (or that some other mechanism is far better) with SDP it should be described. Also, we now have a number SDP extensions, related to grouping, alternatives and capabilities, so it would probably somehow be a good idea to collect a description/comparition of them in some document. Regards, Chriser =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 02:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTeC-0007E9-8f; Mon, 14 May 2007 02:03:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnTeA-0007E1-N3 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 02:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTeA-0007Dt-8z for sip@ietf.org; Mon, 14 May 2007 02:03:02 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnTe7-0006p9-Tq for sip@ietf.org; Mon, 14 May 2007 02:03:02 -0400 Received: by an-out-0708.google.com with SMTP id c34so461592anc for ; Sun, 13 May 2007 23:02:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=SIJwFAQLLzhV1aGa1mAQu039Z9khmN7ai9i8qFD/seENy2nMuzIJsy8yYNZRdK2jP6jicodb9uwlbqSD38E7Hfz4qPo3TtoJY5mcI51nZnOH8RGy4bn6p2z4IzFcHpWC6zv5fjxtlbwJDXv2+ulLA/5LpCAanpmIc6S/H1wCCfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZYdF+kkG0lY4sv398bfBHEYzF+LqsU3ZbxmTqBlHHu/xWCP4LXxbRZPmdS0EX34QK6p7HGuQkAgHkmLuXac1ZxnWTpV+W+0nbbmFsLj+Ap5bZGHQyvknk4ukuL1XE0HY4SemxOUsZeeAMzprxwxAsi2v9ZxB5bxEukF8fCwOXOE= Received: by 10.100.32.1 with SMTP id f1mr4205335anf.1179122579589; Sun, 13 May 2007 23:02:59 -0700 (PDT) Received: by 10.100.154.2 with HTTP; Sun, 13 May 2007 23:02:59 -0700 (PDT) Message-ID: <3fe6b8640705132302y256357deg6e4d5d55a91bf309@mail.gmail.com> Date: Mon, 14 May 2007 11:32:59 +0530 From: "Malleswara Rao Ankem" To: "Aki Niemi" Subject: Re: [Sip] query on sip-outbound and sip-connect-reuse In-Reply-To: <45FFAE54.1040904@nokia.com> MIME-Version: 1.0 References: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com> <45FFAE54.1040904@nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1768980684==" Errors-To: sip-bounces@ietf.org --===============1768980684== Content-Type: multipart/alternative; boundary="----=_Part_114996_33301693.1179122579543" ------=_Part_114996_33301693.1179122579543 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The outbound draft does not talk of what happens when there is a UDP to TCP switchover due to MTU overshoot. Since the edge proxy cannot initiate a TCP connection towards the UA, its the UA which should take care of maintaining the TCP connection with the network and the flows are created only through registration. So if I have a UA which primarily performs SIP signaling on UDP but would like to support TCP only for huge messages (that cross MTU), then as per the current outbound draft it will have to create a flow for TCP based transport during the registration itself and create another flow for UDP based transport by registering from the 5060 port. On 3/20/07, Aki Niemi wrote: > > > ext Malleswara Rao Ankem wrote: > > Hello, > > I've a query on sip-outbound draft (-08) which indicates that a TCP > > connection (flow) established by the client be re-used by the edge > proxy. > > While the sip-connect-reuse draft (-07) indicates that only a TCP > > connection > > established for TLS (by the client) should be re-used by the edge proxy > as > > there is a security threat incase the TCP connection is re-used. > > Was this not considered or it was mentioned in outbound draft somewhere > but > > I overlooked it. > > The reason is that for the server-to-server case, for which > connect-reuse is meant, you can't trust a connection unless both parties > are authenticated, and currently the only way to do this in SIP is to do > mutual auth in TLS. > > This is not the case with outbound, where Digest authentication > effectively does mutual auth. Of course a better option is to do one way > authenticated TLS and then on top of that have Digest authenticate the > client. > > > Also, in sip-outbound if the client needs to be reachable on UDP and on > TCP > > does the client need to establish, register and maintain (keepalive) two > > different "flows" to the registrar? which would basically means two > > different REGISTER cycles with same instance id but different reg-id? > > I guess. I have no idea why you would want to do that though. > > Cheers, > Aki > ------=_Part_114996_33301693.1179122579543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The outbound draft does not talk of what happens when there is a UDP to TCP switchover due to MTU overshoot. Since the edge proxy cannot initiate a TCP connection towards the UA, its the UA which should take care of maintaining the TCP connection with the network and the flows are created only through registration.
So if I have a UA which primarily performs SIP signaling on UDP but would like to support TCP only for huge messages (that cross MTU), then as per the current outbound draft it will have to create a flow for TCP based transport during the registration itself and create another flow for UDP based transport by registering from the 5060 port.
 
On 3/20/07, Aki Niemi <aki.niemi@nokia.com > wrote:


ext Malleswara Rao Ankem wrote:
> Hello,
> I've a query on sip-outbound draft (-08) which indicates that a TCP
> connection (flow) established by the client be re-used by the edge proxy.
> While the sip-connect-reuse draft (-07) indicates that only a TCP
> connection
> established for TLS (by the client) should be re-used by the edge proxy as
> there is a security threat incase the TCP connection is re-used.
> Was this not considered or it was mentioned in outbound draft somewhere but
> I overlooked it.

The reason is that for the server-to-server case, for which
connect-reuse is meant, you can't trust a connection unless both parties
are authenticated, and currently the only way to do this in SIP is to do
mutual auth in TLS.

This is not the case with outbound, where Digest authentication
effectively does mutual auth. Of course a better option is to do one way
authenticated TLS and then on top of that have Digest authenticate the
client.

> Also, in sip-outbound if the client needs to be reachable on UDP and on TCP
> does the client need to establish, register and maintain (keepalive) two
> different "flows" to the registrar? which would basically means two
> different REGISTER cycles with same instance id but different reg-id?

I guess. I have no idea why you would want to do that though.

Cheers,
Aki

------=_Part_114996_33301693.1179122579543-- --===============1768980684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1768980684==-- From sip-bounces@ietf.org Mon May 14 03:08:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUfc-0003pK-Ty; Mon, 14 May 2007 03:08:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnUfb-0003pF-49 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 03:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUfa-0003p7-P8 for sip@ietf.org; Mon, 14 May 2007 03:08:34 -0400 Received: from mail.strom.cz ([212.67.84.228]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnUfa-0005U2-10 for sip@ietf.org; Mon, 14 May 2007 03:08:34 -0400 Received: from exalfa.stromtelecom.cz ([172.16.16.10]) by mail.strom.cz with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:08:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 May 2007 09:08:31 +0200 Message-ID: <2DD3CA89774593478BC28081C7392595B7FC3D@exalfa.stromtelecom.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-fork-loop-fix-05 Thread-Index: AceV88xSZfCNXHB/ShOD3Dh6htfGwgAAs8fA From: "Kolomaznik Jan" To: X-OriginalArrivalTime: 14 May 2007 07:08:32.0179 (UTC) FILETIME=[AE47E830:01C795F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: dae47ebd0d959deee2d6f67621ddb2e3 Subject: [Sip] draft-ietf-sip-fork-loop-fix-05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0293139566==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0293139566== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C795F6.AE42622B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C795F6.AE42622B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have two notes to the draft-ietf-sip-fork-loop-fix-05.=20 =20 1st note: This draft states the number of stimulated request is equal 2^70 when the involved endpoint and proxies follow RFC 3261 recommendations. It is mentioned in sections 2 and 3. =20 My opinion is, that the number of stimulated requests is another and it is 2^71 for the given example and 2^(Max-Forwards + 1) in a little generally way (but still valid only for the given example). =20 Let follow next calculation example, where an endpoint sends request with Max-Forwards reduced to 4. =20 | Max-Forwards: 4 a@P1 / \ / \ Max-Forwards: 3 / \ / \ a@P2 b@P2 / \ / \ / \ / \ Max-Forwards: 2 / \ / \ a@P1 b@P1 a@P1 b@P1 / \ / \ / \ / \ Max-Forwards: 1 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 /\ /\ /\ /\ /\ /\ /\ /\ Max-Forwards: 0 =20 There are two messages with Max-Forwards header set to 3, four messages with Max-Forwards header set to 2, eight messages with Max-Forwards header set to 1 and sixteen messages with Max-Forwards header set to 0. Altogether there are 32 stimulated messages. Request with Max-Forwards set to 4 is not possible to include because it is stimulating message. =20 So, the calculation mentioned by sections 2 and 3 is valid only for the last forking round but it is not number of all produced requests. =20 2nd note: Each proxy must handle number of UAS transactions and number of UAC transaction. Sum of UAS and UAC transactions per proxy is close to 2^(Max-Forwards + 1). When UAS transaction of the stimulating request will not be counted, the number of transactions handled by each proxy is the same.=20 =20 Please note that these calculations are valid only for the given example. In another attack configuration it will be different. =20 Jan =20 ------_=_NextPart_001_01C795F6.AE42622B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have two notes to = the draft-ietf-sip-fork-loop-fix-05.

 

1st = note:

This draft states = the number of stimulated request is equal 2^70 when the involved endpoint and = proxies follow RFC 3261 recommendations. It is mentioned in sections 2 and = 3.

 

My opinion is, that = the number of stimulated requests is another and it is 2^71 for the given = example and 2^(Max-Forwards + 1) in a little generally way (but still valid only = for the given example).

 

Let follow next = calculation example, where an endpoint sends request with Max-Forwards reduced to = 4.

 

           &= nbsp;      |            =           Max-Forwards: 4
            &= nbsp;    a@P1
            &= nbsp;  /      \
             = /          \   =              Max-Forwards: 3
           /             &= nbsp;\
         /             &= nbsp;    \
       a@P2             &= nbsp;   b@P2
        / \             &= nbsp;   / \
      /     \             /=     \        Max-Forwards: 2
     /       \           /       \
   a@P1      b@P1      a@P1 =      b@P1
   / \       / \       / \ =       / \     Max-Forwards: 1
a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2
 /\   /\   /\   /\   /\   /\   /\   /\   Max-Forwards: = 0

 

There are two = messages with Max-Forwards header set to 3, four messages with Max-Forwards header set = to 2, eight messages with Max-Forwards header set to 1 and sixteen messages = with Max-Forwards header set to 0. Altogether there are 32 stimulated = messages. Request with Max-Forwards set to 4 is not possible to include because it = is stimulating message.

 

So, the calculation = mentioned by sections 2 and 3 is valid only for the last forking round but it is = not number of all produced requests.

 

2nd = note:

Each proxy must = handle number of UAS transactions and number of UAC transaction. Sum of UAS and = UAC transactions per proxy is close to 2^(Max-Forwards + 1). When UAS = transaction of the stimulating request will not be counted, the number of = transactions handled by each proxy is the same.

 

Please note that = these calculations are valid only for the given example. In another attack = configuration it will be different.

 

Jan

 

------_=_NextPart_001_01C795F6.AE42622B-- --===============0293139566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0293139566==-- From sip-bounces@ietf.org Mon May 14 03:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUtA-0004pc-4L; Mon, 14 May 2007 03:22:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnUt8-0004pX-Jq for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 03:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnUt8-0004pP-8I for sip@ietf.org; Mon, 14 May 2007 03:22:34 -0400 Received: from ds3000.pernau.at ([88.198.53.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnUt6-0008T3-W6 for sip@ietf.org; Mon, 14 May 2007 03:22:34 -0400 Received: from [10.10.0.50] (nat.labs.nic.at [83.136.33.3]) by ds3000.pernau.at (Postfix) with ESMTP id ABAA61080005; Mon, 14 May 2007 09:22:31 +0200 (CEST) Message-ID: <46480E39.1010805@pernau.at> Date: Mon, 14 May 2007 09:22:33 +0200 From: Klaus Darilion User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Mark R. Lindsey" Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com> <001401c78976$5f8dc020$0601a8c0@BEMBUSTER> <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com> In-Reply-To: <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: discussion@sipforum.org, IETF SIP List , Robert Sparks , Juha Heinanen , sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Mark R. Lindsey wrote: > It is much more reasonable to expect the service-provider/enterprise to > implement the location conveyance. They'd add the location in their > proxies/B2BUAs/ALGs. For example, an enterprise building ALG could add > its location before sending the call to an SP. What if there is no service provider at all? SIP phones may perform emergency calls on there own - without the need of a service provider. Otherwise - if your service provider is down - you can't make emergency calls. regards klaus _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 03:34:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnV4M-0002CO-WB; Mon, 14 May 2007 03:34:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnV4L-0002CI-Vw for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 03:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnV4L-0002CA-5R for sip@ietf.org; Mon, 14 May 2007 03:34:09 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnV4K-0001OU-KU for sip@ietf.org; Mon, 14 May 2007 03:34:09 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1179128047!2406488!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16459 invoked from network); 14 May 2007 07:34:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 14 May 2007 07:34:07 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4E7Y6wd016653 for ; Mon, 14 May 2007 00:34:06 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l4E7Y6Wa004484 for ; Mon, 14 May 2007 02:34:06 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l4E7Y4Hp004447 for ; Mon, 14 May 2007 02:34:05 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] query on sip-outbound and sip-connect-reuse Date: Mon, 14 May 2007 15:34:03 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B041D1D7A@ZMY16EXM66.ds.mot.com> In-Reply-To: <3fe6b8640705132302y256357deg6e4d5d55a91bf309@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] query on sip-outbound and sip-connect-reuse Thread-Index: AceV7ZuwxdqW3/kqQ8KMjTJDBO23KQADDL3w X-Priority: 1 Priority: Urgent Importance: high References: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com><45FFAE54.1040904@nokia.com> <3fe6b8640705132302y256357deg6e4d5d55a91bf309@mail.gmail.com> From: "Avasarala Ranjit-A20990" To: "Malleswara Rao Ankem" , "Aki Niemi" X-Vontu: Pass X-Spam-Score: 0.4 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573861089==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0573861089== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C795FA.3F41520A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C795FA.3F41520A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable sec 14 of sip oubound draft address the situation when the UA could switchover from UDP to TCP when the MTU size is large. But yes there are no current deployments that really support the switchover. =20 Regards=20 Ranjit=20 =20 ________________________________ From: Malleswara Rao Ankem [mailto:malleshavn@gmail.com]=20 Sent: Monday, May 14, 2007 11:33 AM To: Aki Niemi Cc: sip@ietf.org Subject: Re: [Sip] query on sip-outbound and sip-connect-reuse The outbound draft does not talk of what happens when there is a UDP to TCP switchover due to MTU overshoot. Since the edge proxy cannot initiate a TCP connection towards the UA, its the UA which should take care of maintaining the TCP connection with the network and the flows are created only through registration.=20 So if I have a UA which primarily performs SIP signaling on UDP but would like to support TCP only for huge messages (that cross MTU), then as per the current outbound draft it will have to create a flow for TCP based transport during the registration itself and create another flow for UDP based transport by registering from the 5060 port.=20 =20 On 3/20/07, Aki Niemi wrote:=20 ext Malleswara Rao Ankem wrote: > Hello, > I've a query on sip-outbound draft (-08) which indicates that a TCP=20 > connection (flow) established by the client be re-used by the edge proxy. > While the sip-connect-reuse draft (-07) indicates that only a TCP > connection > established for TLS (by the client) should be re-used by the edge proxy as=20 > there is a security threat incase the TCP connection is re-used. > Was this not considered or it was mentioned in outbound draft somewhere but > I overlooked it. =09 The reason is that for the server-to-server case, for which=20 connect-reuse is meant, you can't trust a connection unless both parties are authenticated, and currently the only way to do this in SIP is to do mutual auth in TLS. =09 This is not the case with outbound, where Digest authentication=20 effectively does mutual auth. Of course a better option is to do one way authenticated TLS and then on top of that have Digest authenticate the client. =09 > Also, in sip-outbound if the client needs to be reachable on UDP and on TCP=20 > does the client need to establish, register and maintain (keepalive) two > different "flows" to the registrar? which would basically means two > different REGISTER cycles with same instance id but different reg-id?=20 =09 I guess. I have no idea why you would want to do that though. =09 Cheers, Aki =09 ------_=_NextPart_001_01C795FA.3F41520A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
sec=20 14 of sip oubound draft address the situation when the UA could = switchover from=20 UDP to TCP when the MTU size is large. But yes there are no current = deployments=20 that really support the switchover.
 

Regards
Ranjit

 

From: Malleswara Rao Ankem=20 [mailto:malleshavn@gmail.com]
Sent: Monday, May 14, 2007 = 11:33=20 AM
To: Aki Niemi
Cc: sip@ietf.org
Subject: = Re:=20 [Sip] query on sip-outbound and sip-connect-reuse

The outbound draft does not talk of what happens when there is a = UDP=20 to TCP switchover due to MTU overshoot. Since the edge proxy cannot = initiate a TCP connection towards the UA, its the UA which should take = care of=20 maintaining the TCP connection with the network and the flows are = created only=20 through registration.
So if I have a UA which primarily performs SIP signaling on = UDP but=20 would like to support TCP only for huge messages (that cross MTU), then = as per=20 the current outbound draft it will have to create a flow for TCP based = transport=20 during the registration itself and create another flow for UDP based = transport=20 by registering from the 5060 port.
 
On 3/20/07, Aki Niemi=20 <aki.niemi@nokia.com >=20 wrote:


ext=20 Malleswara Rao Ankem wrote:
> Hello,
> I've a query on=20 sip-outbound draft (-08) which indicates that a TCP
> = connection (flow)=20 established by the client be re-used by the edge proxy.
> While = the=20 sip-connect-reuse draft (-07) indicates that only a TCP
>=20 connection
> established for TLS (by the client) should be = re-used by=20 the edge proxy as
> there is a security threat incase the TCP=20 connection is re-used.
> Was this not considered or it was = mentioned in=20 outbound draft somewhere but
> I overlooked it.

The = reason is=20 that for the server-to-server case, for which
connect-reuse is = meant, you=20 can't trust a connection unless both parties
are authenticated, and = currently the only way to do this in SIP is to do
mutual auth in=20 TLS.

This is not the case with outbound, where Digest = authentication=20
effectively does mutual auth. Of course a better option is to do = one=20 way
authenticated TLS and then on top of that have Digest = authenticate=20 the
client.

> Also, in sip-outbound if the client needs = to be=20 reachable on UDP and on TCP
> does the client need to = establish,=20 register and maintain (keepalive) two
> different "flows" to the = registrar? which would basically means two
> different REGISTER = cycles=20 with same instance id but different reg-id?

I guess. I have no = idea=20 why you would want to do that=20 though.

Cheers,
Aki

------_=_NextPart_001_01C795FA.3F41520A-- --===============0573861089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0573861089==-- From sip-bounces@ietf.org Mon May 14 06:33:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXry-0007PW-BV; Mon, 14 May 2007 06:33:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnXrv-0007PR-T5 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 06:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXrv-0007PJ-JQ for sip@ietf.org; Mon, 14 May 2007 06:33:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnXru-0002Ng-66 for sip@ietf.org; Mon, 14 May 2007 06:33:31 -0400 Received: (qmail invoked by alias); 14 May 2007 10:33:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp002) with SMTP; 14 May 2007 12:33:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197lo8oN/l7LulH44uRqCD+RC0CjV6ouNqo8BItrJ r5GxvEN39Cq90e Message-ID: <46483AF6.9070702@gmx.net> Date: Mon, 14 May 2007 12:33:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Klaus Darilion Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com> <001401c78976$5f8dc020$0601a8c0@BEMBUSTER> <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com> <46480E39.1010805@pernau.at> In-Reply-To: <46480E39.1010805@pernau.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: discussion@sipforum.org, IETF SIP List , Robert Sparks , Juha Heinanen , sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Klaus, no matter how you call it but there will always be a (VoIP) application service provider involved in the emergency services case. I guess you refer to the SIM-less emergency services case (or unauthenticated emergency network access scenario) where the access network provider (ASP and/or ISP) also needs to be the (VoIP) application service provider. Ciao Hannes Klaus Darilion wrote: > > > Mark R. Lindsey wrote: >> It is much more reasonable to expect the service-provider/enterprise >> to implement the location conveyance. They'd add the location in >> their proxies/B2BUAs/ALGs. For example, an enterprise building ALG >> could add its location before sending the call to an SP. > > What if there is no service provider at all? SIP phones may perform > emergency calls on there own - without the need of a service provider. > Otherwise - if your service provider is down - you can't make > emergency calls. > > regards > klaus > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 06:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYGY-00058M-3r; Mon, 14 May 2007 06:58:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm8S2-0004cD-Lf for sip-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 09:12:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hm8S2-0004c5-CS for sip@ietf.org; Thu, 10 May 2007 09:12:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm8RL-0004Vd-6K for sip@ietf.org; Thu, 10 May 2007 09:12:15 -0400 Received: from mail44.messagelabs.com ([216.82.249.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hm8RH-0005HU-Or for sip@ietf.org; Thu, 10 May 2007 09:12:15 -0400 X-VirusChecked: Checked X-Env-Sender: Francesco_Paradiso@alliedtelesis.com X-Msg-Ref: server-14.tower-44.messagelabs.com!1178802728!26832437!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [212.177.57.74] Received: (qmail 6399 invoked from network); 10 May 2007 13:12:10 -0000 Received: from unknown (HELO alliedtelesis.com) (212.177.57.74) by server-14.tower-44.messagelabs.com with SMTP; 10 May 2007 13:12:10 -0000 Received: from svr-mila-e2k1.atg.lc ([10.17.39.14] RDNS failed) by alliedtelesis.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 15:15:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 May 2007 15:12:08 +0200 Message-ID: <563047DA3F61634180B39CD3E27D38441A74E5@svr-mila-e2k1.atg.lc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Via branch value in retransission procedure Thread-Index: AceTBM+13dJbEmLiS8OP5KIw0iWZag== From: "Paradiso, Francesco" To: X-OriginalArrivalTime: 10 May 2007 13:15:40.0847 (UTC) FILETIME=[4EBCE3F0:01C79305] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-TMDA-Confirmed: Thu, 10 May 2007 09:12:58 -0400 X-Mailman-Approved-At: Mon, 14 May 2007 06:58:57 -0400 Subject: [Sip] Via branch value in retransission procedure X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1674345869==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1674345869== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79304.D02B38A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79304.D02B38A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi all, is correct that on every retransmit, the CSeq is incremented and the Via branch parameter is changed? =20 Thanks in Advance Best Regards Francesco=20 =20 =20 ------_=_NextPart_001_01C79304.D02B38A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi all,
is=20 correct that on every retransmit, the CSeq is incremented and the = Via=20 branch parameter is changed?
 
Thanks = in=20 Advance
Best=20 Regards


Francesco

  =

 
------_=_NextPart_001_01C79304.D02B38A5-- --===============1674345869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1674345869==-- From sip-bounces@ietf.org Mon May 14 07:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYgk-0004Qt-0R; Mon, 14 May 2007 07:26:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnYgi-0004Qo-04 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 07:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYgh-0004Qg-MX for sip@ietf.org; Mon, 14 May 2007 07:25:59 -0400 Received: from mail59.messagelabs.com ([195.245.230.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HnYgg-0003rS-12 for sip@ietf.org; Mon, 14 May 2007 07:25:59 -0400 X-VirusChecked: Checked X-Env-Sender: rayees.khan@digitalk.com X-Msg-Ref: server-4.tower-59.messagelabs.com!1179141955!11400250!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [213.249.130.39] Received: (qmail 10674 invoked from network); 14 May 2007 11:25:56 -0000 Received: from mail.digitalk.com (HELO svr-zoe.digitalk.com) (213.249.130.39) by server-4.tower-59.messagelabs.com with SMTP; 14 May 2007 11:25:56 -0000 Received: from svr-elmo.digitalk.com (unverified) by svr-zoe.digitalk.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Mon, 14 May 2007 12:25:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Via branch value in retransission procedure Date: Mon, 14 May 2007 12:25:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Via branch value in retransission procedure thread-index: AceTBM+13dJbEmLiS8OP5KIw0iWZagDFWpaw From: "Rayees Khan" To: "Paradiso, Francesco" , X-Spam-Score: 0.1 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1904844581==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1904844581== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7961A.A2AED4FD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7961A.A2AED4FD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Francesco, =20 Increment in CSeq and new branch parameter would mean it is a new request and *NOT* a retransmitted request =20 =20 regards Rayees =20 ________________________________ From: Paradiso, Francesco [mailto:Francesco_Paradiso@alliedtelesis.com]=20 Sent: Thursday, May 10, 2007 2:12 PM To: sip@ietf.org Subject: [Sip] Via branch value in retransission procedure =20 Hi all, is correct that on every retransmit, the CSeq is incremented and the Via branch parameter is changed? =20 Thanks in Advance Best Regards Francesco=20 =20 =20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ---------------------------------------------------------------------------= ------- IMPORTANT The information contained in this e-mail any attachments is intended only for the named recipient and may be privileged or confidential. If you are not the intended recipient, please notify us immediately=20 on +44 (0)1908 425000 and do not disclose, copy, distribute=20 or take any action based on the contents of this e-mail.=20 You should understand and accept that, when communicating with us by e-mail, it is not a totally secure communication medium. We accept no liability for any direct, indirect or consequential loss arising from any action taken in reliance on the information contained in this e-mail and give no warranty or representation as to its accuracy or reliability. DIGITALK has the facility to monitor and read both incoming and outgoing communications by e-mail. In line with industry efforts to reduce the proliferation of Un-Solicited SPAM messages,=20 DIGITALK uses various methods including Reverse-DNS=20 lookups and ban-lists to prevent malicious content reaching our users. This message and any attachments has been scanned for known viruses. However, we would advise you to ensure the content is indeed virus free. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or breach of confidentiality in relation to transmissions sent by e-mail. VAT No: GB 876 3287 81. Reg No: 3080801 Place of Registration: England Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes ---------------------------------------------------------------------------= -------" ------_=_NextPart_001_01C7961A.A2AED4FD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Francesco,
 
Increment in CSeq and new branch parameter would m= ean it is=20 a new request and *NOT* a retransmitted request
 
 
regards
Rayees
 <= /DIV>
From: Paradiso, Francesco=20 [mailto:Francesco_Paradiso@alliedtelesis.com]
Sent: Thursday, Ma= y 10,=20 2007 2:12 PM
To: sip@ietf.org
Subject: [Sip] Via branch= =20 value in retransission procedure

 
Hi all,
is=20 correct that on every retransmit, the CSeq is incremented and the Vi= a=20 branch parameter is changed?
 
Thanks in= =20 Advance
Best=20 Regards


Francesco=20

  <= SPAN=20 style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Arial">

 

___________________________________________= ___________________________
This=20 email has been scanned by the MessageLabs Email Security System.
For mor= e=20 information please visit http://www.messagelabs.com/email=20
______________________________________________________________________<= BR>

---------------------------------------------------------------------------= -------
IMPORTANT The information contained in this e-mail any
attachments is intended only for the named recipient and may be
privileged or confidential.

If you are not the intended recipient, please notify us immediately
on +44 (0)1908 425000 and do not disclose, copy, distribute
or take any action based on the contents of this e-mail.

You should understand and accept that, when communicating with us
by e-mail, it is not a totally secure communication medium.

We accept no liability for any direct, indirect or consequential loss
arising from any action taken in reliance on the information contained
in this e-mail and give no warranty or representation as to its accuracy
or reliability.

DIGITALK has the facility to monitor and read both incoming
and outgoing communications by e-mail. In line with industry efforts
to reduce the proliferation of Un-Solicited SPAM messages,
DIGITALK uses various methods including Reverse-DNS
lookups and ban-lists to prevent malicious content reaching our users.

This message and any attachments has been scanned for known
viruses. However, we would advise you to ensure the content is
indeed virus free. We do not, to the extent permitted by law, accept
any liability (whether in contract, negligence or otherwise) for any virus<= BR> infection and/or external compromise of security and/or breach of
confidentiality in relation to transmissions sent by e-mail.

VAT No: GB 876 3287 81. Reg No: 3080801
Place of Registration: England
Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes
---------------------------------------------------------------------------= -------"
 ------_=_NextPart_001_01C7961A.A2AED4FD-- --===============1904844581== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1904844581==-- From sip-bounces@ietf.org Mon May 14 07:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ39-0002s6-8S; Mon, 14 May 2007 07:49:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnZ37-0002s1-U5 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 07:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ37-0002rt-KP for sip@ietf.org; Mon, 14 May 2007 07:49:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZ37-0000f8-83 for sip@ietf.org; Mon, 14 May 2007 07:49:09 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 14 May 2007 04:48:09 -0700 X-IronPort-AV: i="4.14,531,1170662400"; d="scan'208"; a="421654409:sNHT2734577402" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4EBm8OK031968; Mon, 14 May 2007 04:48:08 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4EBm806029454; Mon, 14 May 2007 11:48:08 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.1830); Mon, 14 May 2007 07:48:07 -0400 Received: from [10.86.242.112] ([10.86.242.112]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 07:48:07 -0400 Message-ID: <46484C76.2060305@cisco.com> Date: Mon, 14 May 2007 07:48:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Malleswara Rao Ankem Subject: Re: [Sip] query on sip-outbound and sip-connect-reuse References: <3fe6b8640703200003i5d796f8es78a6e043062e9ede@mail.gmail.com> <45FFAE54.1040904@nokia.com> <3fe6b8640705132302y256357deg6e4d5d55a91bf309@mail.gmail.com> In-Reply-To: <3fe6b8640705132302y256357deg6e4d5d55a91bf309@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 11:48:07.0527 (UTC) FILETIME=[BD2ADF70:01C7961D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2938; t=1179143288; x=1180007288; c=relaxed/simple; s=sjdkim6002; 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[Sip]=20query=20on=20sip-outbound=20and=20sip-connect -reuse |Sender:=20; bh=fAQv5bwB2ngTpEN812FqJoWcOqdwZE3NpzSoibbfkFw=; b=TTHthMQZLLLkyfZQ16Mqk6D/yt9FNBavQAbKmfaAhe4Y8+pR9JJ+hUQPObja6iEEUEjbT53N bXXyHdVy18ZXNCJODGOqOzEnY+PZNM4V5d1JjoB9hZEegIMDJCb3k2s6; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you are going to maintain a TCP connection for handling large messages, then why not use it for all messages? Paul Malleswara Rao Ankem wrote: > The outbound draft does not talk of what happens when there is a UDP > to TCP switchover due to MTU overshoot. Since the edge proxy cannot > initiate a TCP connection towards the UA, its the UA which should take > care of maintaining the TCP connection with the network and the flows > are created only through registration. > So if I have a UA which primarily performs SIP signaling on UDP but > would like to support TCP only for huge messages (that cross MTU), then > as per the current outbound draft it will have to create a flow for TCP > based transport during the registration itself and create another flow > for UDP based transport by registering from the 5060 port. > > On 3/20/07, *Aki Niemi* > wrote: > > > > ext Malleswara Rao Ankem wrote: > > Hello, > > I've a query on sip-outbound draft (-08) which indicates that a TCP > > connection (flow) established by the client be re-used by the > edge proxy. > > While the sip-connect-reuse draft (-07) indicates that only a TCP > > connection > > established for TLS (by the client) should be re-used by the edge > proxy as > > there is a security threat incase the TCP connection is re-used. > > Was this not considered or it was mentioned in outbound draft > somewhere but > > I overlooked it. > > The reason is that for the server-to-server case, for which > connect-reuse is meant, you can't trust a connection unless both parties > are authenticated, and currently the only way to do this in SIP is to do > mutual auth in TLS. > > This is not the case with outbound, where Digest authentication > effectively does mutual auth. Of course a better option is to do one way > authenticated TLS and then on top of that have Digest authenticate the > client. > > > Also, in sip-outbound if the client needs to be reachable on UDP > and on TCP > > does the client need to establish, register and maintain > (keepalive) two > > different "flows" to the registrar? which would basically means two > > different REGISTER cycles with same instance id but different > reg-id? > > I guess. I have no idea why you would want to do that though. > > Cheers, > Aki > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 11:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnckv-0001gw-FW; Mon, 14 May 2007 11:46:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hnckt-0001gk-72 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 11:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hncks-0001gc-Ta for sip@ietf.org; Mon, 14 May 2007 11:46:34 -0400 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnckr-0003rj-KS for sip@ietf.org; Mon, 14 May 2007 11:46:34 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc12) with ESMTP id <20070514154632b1200f828he>; Mon, 14 May 2007 15:46:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4EFkVZZ025125; Mon, 14 May 2007 11:46:31 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4EFkVdT025121; Mon, 14 May 2007 11:46:31 -0400 Date: Mon, 14 May 2007 11:46:31 -0400 Message-Id: <200705141546.l4EFkVdT025121@dragon.ariadne.com> To: discussion@sipforum.org, sip@ietf.org, sip-implementors@cs.columbia.edu From: Dale.Worley@comcast.net In-reply-to: <46483AF6.9070702@gmx.net> (Hannes.Tschofenig@gmx.net) Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary References: <075001c788fc$9f6a2be0$640fa8c0@cis.neustar.com> <001401c78976$5f8dc020$0601a8c0@BEMBUSTER> <2296E180-5F91-40B0-876A-7806949C7689@e-c-group.com> <46480E39.1010805@pernau.at> <46483AF6.9070702@gmx.net> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Hannes Tschofenig no matter how you call it but there will always be a (VoIP) application service provider involved in the emergency services case. I don't see that this is guaranteed. E.g., a VoIP mobile phone could connect to an open WiFi hub at a coffee shop and route a request directly to the local PSAP through its public Internet interface. In that case, the only SIP-aware elements are the mobile phone and the PSAP. But haven't all these issues been discussed and settled in the geoloc WG? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 14 13:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HneAN-0003rO-3k; Mon, 14 May 2007 13:16:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HneAL-0003r9-R8 for sip-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 13:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HneAL-0003r0-HK for sip@ietf.org; Mon, 14 May 2007 13:16:57 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HneAK-0001FE-7L for sip@ietf.org; Mon, 14 May 2007 13:16:57 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4EHGqZ11174; Mon, 14 May 2007 17:16:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Mon, 14 May 2007 12:16:34 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1073395D@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256704076AA4@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME thread-index: AceTYW/Klv+XpbSFQYiKAzUiPWIulwAAeWJQACD4liAAJRcQwABzdZ1w References: <4643B58A.3060407@cisco.com> <115b01c79364$7f4d8d30$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106B9EFA@zrc2hxm0.corp.nortel.com> <7374777208BDC7449D5620EF9423256704076AA4@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg \(JO/LMF\)" , "Dan Wing" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, Flemming Andreasen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Sunday, May 13, 2007 22:42 > To: Audet, Francois (SC100:3055); Dan Wing; Paul Kyzivat > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME > > I think the document should also describe SDP, and if someone=20 > thinks alternative doesn't work (or that some other mechanism=20 > is far better) with SDP it should be described. This document should say that multiple SDPs with multipart/alternative are NOT allowed. It should probably refer to RFC 2046 that explains pretty clearly what Alternative means, i.e., Multiple version of the SAME information using different MIME bodies. See 5.1.4/RFC 2046. E.g., SDP vs SDPv2/NG/whatever-comes-up-next text/plain, text/html > Also, we now have a number SDP extensions, related to=20 > grouping, alternatives and capabilities, so it would probably=20 > somehow be a good idea to collect a description/comparition=20 > of them in some document. Agreed. That's probably the job of Flemming's capability negotiation draft in MMUSIC. I think he's got some wording on it already. > Regards, >=20 > Chriser >=20 > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 15 04:18:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnsDx-0000PU-VJ; Tue, 15 May 2007 04:17:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnsDw-0000Kk-Cq for sip-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 04:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnsDv-0000K3-Vz for sip@ietf.org; Tue, 15 May 2007 04:17:35 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnsDu-0001Qh-ME for sip@ietf.org; Tue, 15 May 2007 04:17:35 -0400 Received: from lion.cs.columbia.edu (IDENT:PzGGrxeVj5plZYK0wk9LMf7AtTjCUnvV@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l4F8HYTY008083 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 15 May 2007 04:17:34 -0400 (EDT) Received: from [192.168.0.100] (pool-71-183-32-102.nycmny.fios.verizon.net [71.183.32.102]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id l4F8HYsA027249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 15 May 2007 04:17:34 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org From: Jae Woo Lee Date: Tue, 15 May 2007 04:17:32 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Sip] Draft revision on SIP UA discovery using Zeroconf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, We have revised the draft on distributing SIP URIs within a LAN using DNS-SD (aka Zeroconf or "Apple Bonjour"). It incorporates the feedback on the previous version we received through the mailing lists and in the IETF 68. The list of changes from the previous version and the link to the IETF slides are included below. Feedback is most welcome. Title : SIP URI Service Discovery using DNS-SD Author(s) : J. Lee, H. Schulzrinne, W. Kellerer, Z. Despotovic Filename : draft-lee-sip-dns-sd-uri-01.txt Pages : 22 Date : 2007-5-14 This document describes the Session Initiation Protocol Uniform Resource Identifier (SIP URI) advertisement for DNS-based Service Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-sip-dns-sd-uri-01.txt The slides from the IETF 68 can be found at: http://www3.ietf.org/proceedings/07mar/slides/sip-11.pdf CHANGES from version 00 ------------------------ * Expanded "Security Considerations" (section 9) * New "Other Related Mechanisms" (section 7) - Comparison to SIP multicast - "sip" service type used by Asterisk and Ekiga - P2PSIP * Changes in the "User Agent Client Behavior" - Request-URI set from the contact attribute (section 5.1) - RFC3263 not followed in resolving host names (section 5.2) * New "DNS-SD/mDNS Overview" (section 3) * References to the Contact header parsing rules (section 4.2.3) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 15 09:02:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwfq-0008Kz-2o; Tue, 15 May 2007 09:02:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hnwfn-0008Eu-Pp for sip-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 09:02:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwfn-0008Em-Fp for sip@ietf.org; Tue, 15 May 2007 09:02:39 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnwfl-000090-E9 for sip@ietf.org; Tue, 15 May 2007 09:02:39 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 527C4205F5; Tue, 15 May 2007 15:02:36 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-2f-4649af6c9092 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 370B32080D; Tue, 15 May 2007 15:02:36 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 15:02:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 May 2007 15:02:34 +0200 Message-ID: <6D34F0B7D5BCB246A42380744457CA36E508B4@esealmw107.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your draft xcap-diff-event:Sending etag information in the Subscribe. Thread-Index: AceW8U42/h5ftlh/Rr2RbYUtw/0elQ== From: "Anders Lindgren C \(TN/EAB\)" To: "Jari Urpalainen" , X-OriginalArrivalTime: 15 May 2007 13:02:36.0077 (UTC) FILETIME=[4F0B3DD0:01C796F1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Subject: [Sip] Your draft xcap-diff-event:Sending etag information in the Subscribe. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1973600889==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1973600889== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C796F1.4EE08C51" This is a multi-part message in MIME format. ------_=_NextPart_001_01C796F1.4EE08C51 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jari, I have a comments/question related to how your draft http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01.txt can be applied in a environment limited bandwidth e.g. where the subscription is done over an air interface. As I see it an XCAP document can be quite large. It may also happen that the changes can be quite rare and not that big. A user can also have quite many documents that he/she wants to subscribe for. My view is that the memory in a client is not a bottleneck today and therefore it is quite likely that it is possible that clients will keep a copy of needed XCAP documents. The method in the draft ( see 4.7) to limit air traffic is to use the "niemi-sip-subnot-etags" draft. That makes it possible to supress some Notifies. This method has one disadvantage and that is that it is based on one etag per subscription and therefore not that useful when we are subscribing for lots of documents in one Sunsbribe dialogue. The method is useful when nothing has changed, but not that useful for small changes to large documents as the client needs to do a XCAP GET in order to fetch the version that the server has. My proposal is to use a different method to limit the information sent over the air. The proposal is that if the client includes a body with all documents and etags it has, the Notifier shall respond with a Nofify that contains all XML patches needed to be able to patch the client's version of the documents to the same version as the server has.=20 If it is possible to send version information for all documents that the client has stored already in the first Subscribe, the Notifier can use this information to start to send the XML patches to patch the client versions to the latest server versions (instead of sending only the link to the documents ) if the server has such patches stored.=20 If it can not provide the patches, it needs to send the link as today.=20 If the server has the same version as the client, the server can send the link with the etag just to confirm that it has the same version. =20 Taking an example from OMA; the existing OMA-TS-XDM-Core (see http://www.openmobilealliance.org/release_program/docs/CopyrightClick.as p?pck=3DXDM&file=3DV1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.pd= f has an xml schema that it is possible to reuse for the version information from the client, (see http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_0_1 .xsd) as it contains per AUID the URIs for a document plus the etag.=20 This proposal will introduce a requirement that the XCAP server needs to have a optional patch history function to support this function, if not supported the server can do as in the existing draft. Comments? Regards Anders ------_=_NextPart_001_01C796F1.4EE08C51 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your draft xcap-diff-event:Sending etag information in the = Subscribe.

Hello Jari,
I have a comments/question related to = how your draft http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-dif= f-event-01.txt can be = applied in a environment limited bandwidth e.g. where the subscription = is done over an air interface.

As I see it an XCAP document can be = quite large. It may also happen that = the changes can be quite rare and not that big.

A user can also have quite many = documents that he/she wants to subscribe for.
My view is that the = memory in a client is not  a bottleneck today and therefore it is = quite likely that it is possible that clients will keep a copy of needed = XCAP documents.

The method in the = draft ( see 4.7) to limit air traffic is to use the = "niemi-sip-subnot-etags" draft. That makes it possible to = supress some Notifies.

This method has one = disadvantage and that is that it is based on one etag per subscription = and therefore not that useful when we are subscribing for lots of = documents in one Sunsbribe dialogue. The method is useful when nothing = has changed, but not that useful for small changes to large documents as = the client needs to do a XCAP GET in order to fetch the version that the = server has.

My proposal is to use = a different method to limit the information sent over the air.
The proposal is that if the client = includes a body with all documents and etags it has, the Notifier shall = respond with a Nofify that contains all XML patches needed to be able to = patch the client's version of the documents to the same version as the = server has.

If it is possible to send version = information for all documents that the client has stored already in the = first Subscribe, the Notifier can use this information to start to send = the XML patches to patch the client versions to the latest server = versions (instead of sending = only the link to the documents ) if the server has such patches stored.

If it can not provide the patches, it = needs to send the link as today.
If the server has the same version as = the client, the server can send the link with the etag just to confirm = that it has the same version. 

Taking an example = from OMA; = the existing OMA-TS-XDM-Core (see = http://www.openmobilealliance.org/release_program/docs/Cop= yrightClick.asp?pck=3DXDM&file=3DV1_0_1-20061128-A/OMA-TS-XDM_Core-V1= _0_1-20061128-A.pdf  = has an xml schema = that it is possible to reuse for the version = information from the client, (see http://www.openmobilealliance.org/tech/profiles/xdm_xcapDi= rectory-V1_0_1.xsd) as it contains per = AUID the URIs for a document plus the etag.

This proposal will introduce = a requirement that the XCAP server needs to have a optional patch = history function to support this function, if not supported the server = can do as in the existing draft.

Comments?

Regards
Anders

------_=_NextPart_001_01C796F1.4EE08C51-- --===============1973600889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1973600889==-- From sip-bounces@ietf.org Tue May 15 09:57:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxX1-0001GI-Qi; Tue, 15 May 2007 09:57:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HnxX0-000197-0a for sip-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 09:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxWz-000189-M5 for sip@ietf.org; Tue, 15 May 2007 09:57:37 -0400 Received: from mailhost1.aepona.com ([194.46.24.5] helo=mailhost2.aepona.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnxWx-00009h-BR for sip@ietf.org; Tue, 15 May 2007 09:57:37 -0400 Received: from strauss.aepona.com ([10.10.12.27]) by mailhost2.aepona.com with esmtp (Exim 4.52) id 1HnxWw-000744-OU for sip@ietf.org; Tue, 15 May 2007 14:57:34 +0100 Message-ID: <4649BC4E.9070800@aepona.com> Date: Tue, 15 May 2007 14:57:34 +0100 From: Stephen McVarnock Organization: AePona Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-gb, en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Sip] UAS behaviour in response to a CANCEL request X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi folks, If a UAC sends a CANCEL request to the UAS, is the UAS under any obligation for the order in which it sends it's responses? i.e.:- It must send the 200 OK for the CANCEL before it sends the 487 for the INVITE request. or It must send the 487 to the INVITE before it sends the 200 OK for the CANCEL request. Having a look at section 9 of RFC 3261, it makes no mention of this which I assume implies that either situation should be dealt is acceptable. Thanks in advance for any help supplied. Regards, Steve -- *********************************************************************** * Stephen McVarnock * Email: stephen.mcvarnock@aepona.com * * Senior Software Developer * WWW : http://www.aepona.com * * Aepona Ltd., * Phone: +44 (0)28 9026 9114 * * Interpoint Building, * Fax : +44 (0)28 9026 9111 * * 20-24 York Street, * * * Belfast. BT15 1AQ * * * N. Ireland * * *********************************************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 15 15:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho36I-00080X-6Q; Tue, 15 May 2007 15:54:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ho36G-00080C-1C for sip-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 15:54:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho36F-000804-Np for sip@ietf.org; Tue, 15 May 2007 15:54:23 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho36D-0003AB-3f for sip@ietf.org; Tue, 15 May 2007 15:54:23 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070515195419m12006qaeve>; Tue, 15 May 2007 19:54:20 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4FJsIZZ018734 for ; Tue, 15 May 2007 15:54:18 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4FJsI3w018730; Tue, 15 May 2007 15:54:18 -0400 Date: Tue, 15 May 2007 15:54:18 -0400 Message-Id: <200705151954.l4FJsI3w018730@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4649BC4E.9070800@aepona.com> (Stephen.McVarnock@aepona.com) Subject: Re: [Sip] UAS behaviour in response to a CANCEL request References: <4649BC4E.9070800@aepona.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Stephen McVarnock If a UAC sends a CANCEL request to the UAS, is the UAS under any obligation for the order in which it sends it's responses? i.e.:- As Paul says, it doesn't matter how the responses are sent, because the network could reorder them before they are received. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 15 15:56:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho386-0000cI-K9; Tue, 15 May 2007 15:56:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ho385-0000cC-K8 for sip-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 15:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho385-0000c3-AJ for sip@ietf.org; Tue, 15 May 2007 15:56:17 -0400 Received: from ausmtp04.au.ibm.com ([202.81.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho382-0003bV-LH for sip@ietf.org; Tue, 15 May 2007 15:56:17 -0400 Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225]) by ausmtp04.au.ibm.com (8.13.8/8.13.8) with ESMTP id l4FKGCD1008166 for ; Wed, 16 May 2007 06:16:13 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4FJxh7c169812 for ; Wed, 16 May 2007 05:59:43 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4FJuB6E005377 for ; Wed, 16 May 2007 05:56:11 +1000 Received: from d23m0037.cn.ibm.com (d23m0037.cn.ibm.com [9.181.2.105]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4FJuAKh005358 for ; Wed, 16 May 2007 05:56:11 +1000 From: Xin Sheng Mao To: sip@ietf.org Message-ID: Date: Wed, 16 May 2007 04:01:20 +0800 X-MIMETrack: Serialize by Router on D23M0037/23/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 05/16/2007 04:01:21 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Xin Sheng Mao/China/IBM is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591157874==" Errors-To: sip-bounces@ietf.org --===============0591157874== Content-type: multipart/alternative; Boundary="0__=C7BBF84FDFFE7ACA8f9e8a93df938690918cC7BBF84FDFFE7ACA" Content-Disposition: inline --0__=C7BBF84FDFFE7ACA8f9e8a93df938690918cC7BBF84FDFFE7ACA Content-type: text/plain; charset=US-ASCII I will be out of the office starting 2007-05-14 and will not return until 2007-05-22. I am out of office starting 05/14 and will not be back until 05/22 --0__=C7BBF84FDFFE7ACA8f9e8a93df938690918cC7BBF84FDFFE7ACA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 2007-05-14 and will not return until 2007-05-22.

I am out of office starting 05/14 and will not be back until 05/22 --0__=C7BBF84FDFFE7ACA8f9e8a93df938690918cC7BBF84FDFFE7ACA-- --===============0591157874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0591157874==-- From sip-bounces@ietf.org Wed May 16 03:17:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDlY-0003ct-VN; Wed, 16 May 2007 03:17:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoDlX-0003cl-EL for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 03:17:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoDlX-0003cd-4J for sip@ietf.org; Wed, 16 May 2007 03:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDjE-0002Ix-O0 for sip@ietf.org; Wed, 16 May 2007 03:15:20 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoDjE-0002lb-6A for sip@ietf.org; Wed, 16 May 2007 03:15:20 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9B6FA208A6; Wed, 16 May 2007 09:15:19 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-64-464aaf872424 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80BE22089B; Wed, 16 May 2007 09:15:19 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:15:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 May 2007 09:15:18 +0200 Message-ID: <3C26DE1DC0C6724B8928D40F216ECFB004A82551@esealmw103.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on XCAP Diff Event draft Thread-Index: AceXifUMkYOWkGUPQMOug2ZEgQRpDA== From: "Sofie Lassborn \(TN/EAB\)" To: , "Jari Urpalainen" X-OriginalArrivalTime: 16 May 2007 07:15:19.0175 (UTC) FILETIME=[F5B21170:01C79789] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-TMDA-Confirmed: Wed, 16 May 2007 03:17:43 -0400 Cc: Subject: [Sip] Questions on XCAP Diff Event draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957959800==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0957959800== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79789.F5212373" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79789.F5212373 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, I have some thoughts and questions regarding the XCAP Diff Event draft (draft-urpalainen-sip-xcap-diff-event-01). What will the notification look like if a requested document cannot be found? No body or only element? What does it mean if a notification contains the document element with doc-selector but no etag attributes?=20 OMA has implemented an architecure where the XCAP server has been split up into so called XCAP Document Management Servers (XDMS). Each XDMS handles separate AUIDs. If a subscription is for several documents distributed over several XDMSes (different auids), what should then the notification look like if there are some documents that don't exist or directories that are empty and there are some documents that cannot be reached because one XDMS does not answer? According to RFC 3265 the "pending" value of the Subscripton-State header indicates that the subscription has been received, but that policy information is insufficient to accept or deny the subscription at this time. Is the intention in section 4.7 in the draft that the subscription state should be pending if the resource the subscription is for cannot be found? What would then the subscription state be for a subscription for white space separated resources where some can be found and some cannot be found? Generation of a "first full response" notification might take time especially if the subscription is for several AUIDs, spread over several XCAP Document Management Servers, at the same time. Is there a need for an "initial" initial notification that may be sent to the subscriber before the "full response" can be sent? Chapter 4.7, second paragraph It is unclear to me what is meant by "...it MUST fall back to sending all component changes again for this resource." Is the intention that the server shall send a "full response" as in an initial notification (my preferred interpretation)? Or is the intention that the server shall send several notifications with the patches not aggregated? Best regards, Sofie ------_=_NextPart_001_01C79789.F5212373 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions on XCAP Diff Event draft

Hi Jari,

I have some thoughts and questions = regarding the XCAP Diff Event draft (draft-urpalainen-sip-xcap-diff-event-01).
What will the = notification look like if a requested document cannot be found? No body = or only <xcap-diff> element? What does it mean if a notification = contains the document element with doc-selector but no etag attributes? =

OMA has = implemented an architecure where the XCAP server has been split up into = so called XCAP Document Management Servers (XDMS). Each XDMS handles = separate AUIDs. If a subscription is for several documents distributed = over several XDMSes (different auids), what should then the notification = look like if there are some documents that don’t exist or = directories that are empty and there are some documents that cannot be = reached because one XDMS does not answer?

According to RFC = 3265 the "pending" value of the Subscripton-State header = indicates that the subscription has been received, but that policy = information is insufficient to accept or deny the subscription at this = time. Is the intention in section 4.7 in the draft that the subscription = state should be pending if the resource the subscription is for cannot = be found? What would then the subscription state be for a subscription = for white space separated resources where some can be found and some = cannot be found?

Generation of a = “first full response” notification might take time = especially if the subscription is for several AUIDs, spread over several = XCAP Document Management Servers, at the same time. Is there a need for = an “initial” initial notification that may be sent to the = subscriber before the “full response” can be = sent?

Chapter 4.7, = second paragraph
It is unclear to me what is meant by “…it MUST fall back to = sending all component changes again for this resource.” Is the = intention that the server shall send a “full response” as in = an initial notification (my preferred interpretation)? Or is the = intention that the server shall send several notifications with the = patches not aggregated?

Best regards,
Sofie

------_=_NextPart_001_01C79789.F5212373-- --===============0957959800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0957959800==-- From sip-bounces@ietf.org Wed May 16 04:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEV5-0004If-5L; Wed, 16 May 2007 04:04:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoEV4-0004IX-0D for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:04:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEV3-0004IG-IU for sip@ietf.org; Wed, 16 May 2007 04:04:45 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEV2-0006Hv-Pq for sip@ietf.org; Wed, 16 May 2007 04:04:45 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 40A0C2119D; Wed, 16 May 2007 10:04:44 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-36-464abb1c7690 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3788D20FD2; Wed, 16 May 2007 10:04:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:04:44 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:04:43 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AEAAC2495; Wed, 16 May 2007 11:04:43 +0300 (EEST) Message-ID: <464ABB1A.3030305@ericsson.com> Date: Wed, 16 May 2007 11:04:42 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <0dd301c792ca$7dd21ec0$c4a36b80@amer.cisco.com> In-Reply-To: <0dd301c792ca$7dd21ec0$c4a36b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 08:04:43.0911 (UTC) FILETIME=[DCD0E170:01C79790] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, > I have become convinced, through my efforts with RTPSEC, that > multipart/alternative is harmful if it contains multiple SDP parts. yes; alternatives, capabilities, etc., in SDP should be expressed using (potentially new) SDP mechanisms (e.g., SDP attributes). I agree that multipart/alternative should not be used for two SDP bodies. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 04:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEdC-000227-Lh; Wed, 16 May 2007 04:13:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoEdC-00021x-2z for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEdB-00021o-OF for sip@ietf.org; Wed, 16 May 2007 04:13:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEdA-0000p2-5C for sip@ietf.org; Wed, 16 May 2007 04:13:09 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9F1D3203B3; Wed, 16 May 2007 10:13:07 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-4c-464abd13b773 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8610C2009C; Wed, 16 May 2007 10:13:07 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:13:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:13:06 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CBE6B2495; Wed, 16 May 2007 11:13:06 +0300 (EEST) Message-ID: <464ABD12.1010004@ericsson.com> Date: Wed, 16 May 2007 11:13:06 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 08:13:06.0980 (UTC) FILETIME=[08AB1E40:01C79792] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, > Section 6 would be OK, but now that SDPng is gone, it's irrelevant. I have seen a few statements like this on the list lately. SIP intends to be, by design, session-description-format agnostic. Therefore, we need a mechanism that allows endpoints to try and use different session-description formats even if SDPng is dead. Experimenting with new session-description formats is part of the innovation process we want to have in SIP. In short, I do not think such a mechanism is irrelevant only because SDPng did not succeed. We still need such a mechanism. Cheers, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 04:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEgQ-0004cb-PV; Wed, 16 May 2007 04:16:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoEgP-0004c6-9X for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEgO-0004by-VW for sip@ietf.org; Wed, 16 May 2007 04:16:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEgO-0002HT-55 for sip@ietf.org; Wed, 16 May 2007 04:16:28 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6A56E207EC; Wed, 16 May 2007 10:16:23 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-9e-464abdd72d6d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4BB5320011; Wed, 16 May 2007 10:16:23 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:16:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 10:16:22 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A754C2495; Wed, 16 May 2007 11:16:22 +0300 (EEST) Message-ID: <464ABDD6.9000503@ericsson.com> Date: Wed, 16 May 2007 11:16:22 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> In-Reply-To: <4643B58A.3060407@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 08:16:22.0964 (UTC) FILETIME=[7D7BE740:01C79792] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, yes, Paul and I talked about writing a draft to clarify a few issues that relate to content dispositions in SIP a while ago. We were quite busy at that point and did not have time to write it, but maybe it is time to do it now. Cheers, Gonzalo Paul Kyzivat wrote: > > > Francois Audet wrote: >> I think we are on to something here. I believe that Paul Kyzivat and Dan >> Wing have it >> right. >> >> What I'd like to see is something describing the following: >> >> - How to use Multipart/mixed >> >> I think Paul Kyzivat and Dan had some good explanation in this thread >> about it. We should really make proper treatment of multipart/mixed >> as mandatory >> as we can. This means, being able to understand parse the nested >> MIME bodies that >> you DO support. >> At a miminum, an implementation should be able to find in a >> Multipart/mixed the SDP >> for example. We probably need also to write some recommnedation on >> what happens if >> there is multiple SDPs in that multipart mixed. > > I would like to bring up something that isn't discussed much: > Content-Disposition. I brought it up earlier in this thread for a > slightly different reason. > > One *should not* look for a particular body part of interest solely > based on the Content-Type. Both the content type and the content > disposition need to be correct. For instance, a body part with content > type of application/sdp should not be considered an offer or answer > unless the content-disposition is "session". (This is confused because > there are are also defaulting rules for content-disposition.) > > *In principle* you could have a multipart/mixed that had to parts, both > with content-type of application/sdp. This could be quite legal if only > one of them had content-disposition of "session" and the other had some > other content-disposition. It would be sufficient for the other to have > "Content-Disposition:foo;handling=optional". > > I realize this is obscure, and it isn't likely that anyone will be > including an sdp body part that isn't intended to be an offer or answer. > But we are writing the specs here, and we ought to be complete and > precise about it. > >> It's not pretty out there. I've seen implementations that don't even >> send 415 >> when receiving multipart/mixed: they just ignore the payload, and >> believe >> it's an SDP-less INVITE. They then put an offer in the response, which >> the >> real offerer believes is an answer. Then all hell breaks loose. >> >> Some of them do send 415, but without the supported payload type in an >> Accept header in 415. >> >> >> - Multipart/alternative >> >> I agree with Dan that using Multipart/alternative in the way that was >> described >> in draft-jennings-sipping-multipart section 5 is in fact harmful. >> Especially now that we >> are defining capability negotiation. Section 6 would be OK, but now >> that SDPng is gone, >> it's irrelevant. >> >> What we really need to say is that multipart/alternative may be used >> only when we >> are using alternative payload types for the same information. For >> example, text/html and text/xml or whatever. It would be applicable >> if one day we re-created >> another SDPng for example. > > The perfect example for that is MESSAGE with text/plain and text/html, > quite analogous to an email message. > >> Section 3.1 explains this relatively well, but is restricted to Offers >> (for which we have >> no use cases anymore). I think it should instead talk about other >> examples (e.g., >> text/html, text/xml, or maybe some example with pictures). >> >> I really believe section 5 goes against the spririt of section 3.1 >> (specifically, of >> the quote of RFC 2046). What it really has it two application/sdp (one >> of them is encrypted inside a application/pkcs7mime), but really >> it's still two >> application/sdp >> >> But we should make it clear that it is NOT for negotiating multiple >> alternatives of the same payload type, in particular, not for >> application/sdp & >> application/sdp. >> If we decide to go forward, I'd be happy to help too. > > I don't have time to take authorship of the document, but I too can > contribute some text. > > Paul > >>> -----Original Message----- >>> From: Dan Wing [mailto:dwing@cisco.com] Sent: Thursday, May 10, 2007 >>> 09:19 >>> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net >>> Cc: sip@ietf.org >>> Subject: RE: [Sip] Support for Multipart/MIME >>> >>>>> I have become convinced, through my efforts with RTPSEC, that >>>>> multipart/alternative is harmful if it contains multiple SDP parts. >>>> Again, I am not in a position to disagree with you ,but is that >>>> harmfulness documented somewhere? >>> Nope. If we're going to move multipart/* forward in SIP, though, >>> I'll be happy to write that section. >>> >>> -d >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 08:18:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoISV-0007LQ-N1; Wed, 16 May 2007 08:18:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoISU-0007LL-Bk for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 08:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoISU-0007LD-22 for sip@ietf.org; Wed, 16 May 2007 08:18:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoIST-00075I-F8 for sip@ietf.org; Wed, 16 May 2007 08:18:22 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 16 May 2007 05:18:21 -0700 X-IronPort-AV: i="4.14,543,1170662400"; d="scan'208"; a="422481242:sNHT54078412" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4GCIKIE015079; Wed, 16 May 2007 05:18:20 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4GCIK06012254; Wed, 16 May 2007 12:18:20 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.1830); Wed, 16 May 2007 08:18:19 -0400 Received: from [10.86.243.214] ([10.86.243.214]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:18:19 -0400 Message-ID: <464AF68A.4010105@cisco.com> Date: Wed, 16 May 2007 08:18:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> In-Reply-To: <464ABDD6.9000503@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 12:18:19.0598 (UTC) FILETIME=[4A1276E0:01C797B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6611; t=1179317900; x=1180181900; c=relaxed/simple; s=sjdkim5002; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=konHRDYG8jUCtjPurz61AxhfaKsbAv07KGhlpRaqX9A=; b=IFzD7OKtaczRz3omADyTNE8E5XH8/KMQonC4jzTHPet8IfYY4tQ49jUyuODpzXogIYb4n/o5 h6z5hdWuSWJsIUqowisTQtfoUP/lFqybprHAabgV8MOKPmfWKMrfQORO; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Gonzalo, I guess the question is whether we want to write a document specifically focused on Content-Disposition, or if we want to combine work on that with work on specifying use of multipart. They aren't the same thing, but content-disposition becomes more significant when there are multiple body parts, so there is some justification for combining the work. Paul Gonzalo Camarillo wrote: > Hi, > > yes, Paul and I talked about writing a draft to clarify a few issues > that relate to content dispositions in SIP a while ago. We were quite > busy at that point and did not have time to write it, but maybe it is > time to do it now. > > Cheers, > > Gonzalo > > > Paul Kyzivat wrote: >> >> >> Francois Audet wrote: >>> I think we are on to something here. I believe that Paul Kyzivat and Dan >>> Wing have it >>> right. >>> >>> What I'd like to see is something describing the following: >>> >>> - How to use Multipart/mixed >>> >>> I think Paul Kyzivat and Dan had some good explanation in this thread >>> about it. We should really make proper treatment of multipart/mixed >>> as mandatory >>> as we can. This means, being able to understand parse the nested >>> MIME bodies that >>> you DO support. >>> At a miminum, an implementation should be able to find in a >>> Multipart/mixed the SDP >>> for example. We probably need also to write some recommnedation on >>> what happens if >>> there is multiple SDPs in that multipart mixed. >> >> I would like to bring up something that isn't discussed much: >> Content-Disposition. I brought it up earlier in this thread for a >> slightly different reason. >> >> One *should not* look for a particular body part of interest solely >> based on the Content-Type. Both the content type and the content >> disposition need to be correct. For instance, a body part with content >> type of application/sdp should not be considered an offer or answer >> unless the content-disposition is "session". (This is confused because >> there are are also defaulting rules for content-disposition.) >> >> *In principle* you could have a multipart/mixed that had to parts, >> both with content-type of application/sdp. This could be quite legal >> if only one of them had content-disposition of "session" and the other >> had some other content-disposition. It would be sufficient for the >> other to have "Content-Disposition:foo;handling=optional". >> >> I realize this is obscure, and it isn't likely that anyone will be >> including an sdp body part that isn't intended to be an offer or >> answer. But we are writing the specs here, and we ought to be complete >> and precise about it. >> >>> It's not pretty out there. I've seen implementations that don't even >>> send 415 >>> when receiving multipart/mixed: they just ignore the payload, and >>> believe >>> it's an SDP-less INVITE. They then put an offer in the response, which >>> the >>> real offerer believes is an answer. Then all hell breaks loose. >>> >>> Some of them do send 415, but without the supported payload type in an >>> Accept header in 415. >>> >>> >>> - Multipart/alternative >>> >>> I agree with Dan that using Multipart/alternative in the way that was >>> described >>> in draft-jennings-sipping-multipart section 5 is in fact harmful. >>> Especially now that we >>> are defining capability negotiation. Section 6 would be OK, but now >>> that SDPng is gone, >>> it's irrelevant. >>> >>> What we really need to say is that multipart/alternative may be used >>> only when we >>> are using alternative payload types for the same information. For >>> example, text/html and text/xml or whatever. It would be applicable >>> if one day we re-created >>> another SDPng for example. >> >> The perfect example for that is MESSAGE with text/plain and text/html, >> quite analogous to an email message. >> >>> Section 3.1 explains this relatively well, but is restricted to Offers >>> (for which we have >>> no use cases anymore). I think it should instead talk about other >>> examples (e.g., >>> text/html, text/xml, or maybe some example with pictures). >>> >>> I really believe section 5 goes against the spririt of section 3.1 >>> (specifically, of >>> the quote of RFC 2046). What it really has it two application/sdp (one >>> of them is encrypted inside a application/pkcs7mime), but really >>> it's still two >>> application/sdp >>> >>> But we should make it clear that it is NOT for negotiating multiple >>> alternatives of the same payload type, in particular, not for >>> application/sdp & >>> application/sdp. >>> If we decide to go forward, I'd be happy to help too. >> >> I don't have time to take authorship of the document, but I too can >> contribute some text. >> >> Paul >> >>>> -----Original Message----- >>>> From: Dan Wing [mailto:dwing@cisco.com] Sent: Thursday, May 10, 2007 >>>> 09:19 >>>> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net >>>> Cc: sip@ietf.org >>>> Subject: RE: [Sip] Support for Multipart/MIME >>>> >>>>>> I have become convinced, through my efforts with RTPSEC, that >>>>>> multipart/alternative is harmful if it contains multiple SDP parts. >>>>> Again, I am not in a position to disagree with you ,but is that >>>>> harmfulness documented somewhere? >>>> Nope. If we're going to move multipart/* forward in SIP, though, >>>> I'll be happy to write that section. >>>> >>>> -d >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 11:27:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLPG-0004FF-6E; Wed, 16 May 2007 11:27:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoLPE-0004F5-H1 for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 11:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLPD-0004Ex-QU for sip@ietf.org; Wed, 16 May 2007 11:27:12 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLPC-0007Qx-Hl for sip@ietf.org; Wed, 16 May 2007 11:27:11 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4GFR4Z07618; Wed, 16 May 2007 15:27:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 16 May 2007 10:26:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10788B71@zrc2hxm0.corp.nortel.com> In-Reply-To: <464ABD12.1010004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME thread-index: AceXkgtIpYMsVePuRrGX5xE1zP9WuwAPH33g References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <464ABD12.1010004@ericsson.com> From: "Francois Audet" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sip@ietf.org, Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that's exactly what I was saying. It's perfectly consistent with the intent of what Multipart/alternative is supposed to mean.=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Wednesday, May 16, 2007 01:13 > To: Audet, Francois (SC100:3055) > Cc: Dan Wing; Christer Holmberg (JO/LMF);=20 > Dale.Worley@comcast.net; sip@ietf.org > Subject: Re: [Sip] Support for Multipart/MIME >=20 > Hi, >=20 > > Section 6 would be OK, but now that SDPng is gone, it's irrelevant. >=20 > I have seen a few statements like this on the list lately.=20 > SIP intends to be, by design, session-description-format=20 > agnostic. Therefore, we need a mechanism that allows=20 > endpoints to try and use different session-description=20 > formats even if SDPng is dead. >=20 > Experimenting with new session-description formats is part of=20 > the innovation process we want to have in SIP. >=20 > In short, I do not think such a mechanism is irrelevant only=20 > because SDPng did not succeed. We still need such a mechanism. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 11:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLSA-0007Gz-IJ; Wed, 16 May 2007 11:30:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoLS9-0007Gu-7Z for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 11:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLS8-0007Gm-U7 for sip@ietf.org; Wed, 16 May 2007 11:30:12 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLS8-0008W8-HM for sip@ietf.org; Wed, 16 May 2007 11:30:12 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4GFU9225895; Wed, 16 May 2007 15:30:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 16 May 2007 10:30:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> In-Reply-To: <464AF68A.4010105@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME thread-index: AceXtFJHz89OmSEzQ+e6FULnhZLXNgAGq4TQ References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: sip@ietf.org, Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My preference is one document.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, May 16, 2007 05:18 > To: Gonzalo Camarillo > Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan Wing;=20 > Christer Holmberg (JO/LMF) > Subject: Re: [Sip] Support for Multipart/MIME >=20 > Hi Gonzalo, >=20 > I guess the question is whether we want to write a document=20 > specifically focused on Content-Disposition, or if we want to=20 > combine work on that with work on specifying use of multipart. >=20 > They aren't the same thing, but content-disposition becomes=20 > more significant when there are multiple body parts, so there=20 > is some justification for combining the work. >=20 > Paul >=20 > Gonzalo Camarillo wrote: > > Hi, > >=20 > > yes, Paul and I talked about writing a draft to clarify a=20 > few issues=20 > > that relate to content dispositions in SIP a while ago. We=20 > were quite=20 > > busy at that point and did not have time to write it, but=20 > maybe it is=20 > > time to do it now. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > >=20 > > Paul Kyzivat wrote: > >> > >> > >> Francois Audet wrote: > >>> I think we are on to something here. I believe that Paul=20 > Kyzivat and=20 > >>> Dan Wing have it right. > >>> > >>> What I'd like to see is something describing the following: > >>> > >>> - How to use Multipart/mixed > >>> > >>> I think Paul Kyzivat and Dan had some good explanation=20 > in this thread > >>> about it. We should really make proper treatment of=20 > multipart/mixed=20 > >>> as mandatory > >>> as we can. This means, being able to understand parse=20 > the nested=20 > >>> MIME bodies that > >>> you DO support. > >>> At a miminum, an implementation should be able to find in a=20 > >>> Multipart/mixed the SDP > >>> for example. We probably need also to write some=20 > recommnedation on=20 > >>> what happens if > >>> there is multiple SDPs in that multipart mixed. > >> > >> I would like to bring up something that isn't discussed much:=20 > >> Content-Disposition. I brought it up earlier in this thread for a=20 > >> slightly different reason. > >> > >> One *should not* look for a particular body part of=20 > interest solely=20 > >> based on the Content-Type. Both the content type and the content=20 > >> disposition need to be correct. For instance, a body part with=20 > >> content type of application/sdp should not be considered=20 > an offer or=20 > >> answer unless the content-disposition is "session". (This=20 > is confused=20 > >> because there are are also defaulting rules for=20 > content-disposition.) > >> > >> *In principle* you could have a multipart/mixed that had to parts,=20 > >> both with content-type of application/sdp. This could be=20 > quite legal=20 > >> if only one of them had content-disposition of "session" and the=20 > >> other had some other content-disposition. It would be=20 > sufficient for=20 > >> the other to have "Content-Disposition:foo;handling=3Doptional". > >> > >> I realize this is obscure, and it isn't likely that anyone will be=20 > >> including an sdp body part that isn't intended to be an offer or=20 > >> answer. But we are writing the specs here, and we ought to be=20 > >> complete and precise about it. > >> > >>> It's not pretty out there. I've seen implementations that don't=20 > >>> even send 415 > >>> when receiving multipart/mixed: they just ignore the=20 > payload, and=20 > >>> believe > >>> it's an SDP-less INVITE. They then put an offer in the=20 > response,=20 > >>> which the > >>> real offerer believes is an answer. Then all hell breaks loose. > >>> > >>> Some of them do send 415, but without the supported=20 > payload type in an > >>> Accept header in 415. > >>> > >>> > >>> - Multipart/alternative > >>> > >>> I agree with Dan that using Multipart/alternative in=20 > the way that=20 > >>> was described > >>> in draft-jennings-sipping-multipart section 5 is in=20 > fact harmful. > >>> Especially now that we > >>> are defining capability negotiation. Section 6 would be OK, but=20 > >>> now that SDPng is gone, > >>> it's irrelevant. > >>> > >>> What we really need to say is that multipart/alternative may be=20 > >>> used only when we > >>> are using alternative payload types for the same=20 > information. For > >>> example, text/html and text/xml or whatever. It would=20 > be applicable=20 > >>> if one day we re-created > >>> another SDPng for example. > >> > >> The perfect example for that is MESSAGE with text/plain and=20 > >> text/html, quite analogous to an email message. > >> > >>> Section 3.1 explains this relatively well, but is restricted to=20 > >>> Offers (for which we have > >>> no use cases anymore). I think it should instead talk=20 > about other=20 > >>> examples (e.g., > >>> text/html, text/xml, or maybe some example with pictures). > >>> > >>> I really believe section 5 goes against the spririt of=20 > section 3.1=20 > >>> (specifically, of > >>> the quote of RFC 2046). What it really has it two=20 > application/sdp (one > >>> of them is encrypted inside a application/pkcs7mime),=20 > but really=20 > >>> it's still two > >>> application/sdp > >>> > >>> But we should make it clear that it is NOT for=20 > negotiating multiple > >>> alternatives of the same payload type, in particular, not for=20 > >>> application/sdp & > >>> application/sdp. > >>> If we decide to go forward, I'd be happy to help too. > >> > >> I don't have time to take authorship of the document, but=20 > I too can=20 > >> contribute some text. > >> > >> Paul > >> > >>>> -----Original Message----- > >>>> From: Dan Wing [mailto:dwing@cisco.com] Sent: Thursday, May 10,=20 > >>>> 2007 > >>>> 09:19 > >>>> To: 'Christer Holmberg (JO/LMF)'; Dale.Worley@comcast.net > >>>> Cc: sip@ietf.org > >>>> Subject: RE: [Sip] Support for Multipart/MIME > >>>> > >>>>>> I have become convinced, through my efforts with RTPSEC, that=20 > >>>>>> multipart/alternative is harmful if it contains=20 > multiple SDP parts. > >>>>> Again, I am not in a position to disagree with you ,but is that=20 > >>>>> harmfulness documented somewhere? > >>>> Nope. If we're going to move multipart/* forward in=20 > SIP, though,=20 > >>>> I'll be happy to write that section. > >>>> > >>>> -d > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 12:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMKo-0005Hg-1k; Wed, 16 May 2007 12:26:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoMKm-0005D2-60 for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 12:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoMKl-00059f-PM for sip@ietf.org; Wed, 16 May 2007 12:26:39 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoMKl-0000KT-60 for sip@ietf.org; Wed, 16 May 2007 12:26:39 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4GGQbT4026300 for ; Wed, 16 May 2007 11:26:38 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 11:26:38 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 18:26: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: Wed, 16 May 2007 18:26:33 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800119095D@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notes of second review call on resolution of location-conveyance comments Thread-Index: AceX1veJrYjjapT0Rgqd1n4tzwVktQ== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 16 May 2007 16:26:34.0069 (UTC) FILETIME=[F7DE6050:01C797D6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Subject: [Sip] Notes of second review call on resolution of location-conveyance comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) The following represents the notes of the second conference call we held to review comments. Regards Keith Notes of review team call on WGLC comments on draft-ietf-sip-location- conveyance-07 held on 1st May 2007 1) Roll call The following participated in the call. Richard Barnes Keith Drage (moderator and scribe) James Polk (document editor) Brian Rosen (document editor) Henning Schulzrinne Hannes Tschofenig 2) Agenda bash Proposed to go through the action items, followed by the remaining agenda items=20 from the previous meeting, following by any other issues from the comments that=20 the editor's considered needed input from the review team. 3) Action points from previous review team discussion Action 1/1: Keith to take above list to WG for consensus call, as direction to=20 the editors. Done. Action complete on Thursday 3rd May. List was: - location conveyance should support the delivery of multiple locations; - the document will make no recommendations as to how the recipient chooses=20 which location to use. This is regarded as specific to the using application,=20 and therefore beyond the scope of the protocol extension; - the recipient should attempt to make use of all the locations given, and=20 should only respond with a 424 response if it is unable to use any of those=20 locations. This includes resolving all and any locations by reference; - as a result of the above, any 424 response is a collective statement about=20 all the locations given in the request rather than any specific location in the=20 request. One of the comments made on the list was that draft-ietf-pdif-lo may provide=20 useful information to support this. It was therefore discussed whether draft- ietf-sip-location-conveyance should contain a normative reference to this=20 document. It was agreed that this document contained provides that were=20 application specific rather than protocol specific, and therefore there should=20 not be a normative reference.=20 Brian questioned whether there should be more than one reference in the same=20 provided-by. Proposal was that SHOULD NOT add multiple locations. Brian agreed=20 to draft text to send to people on his proposal. Action 2/1: Brian to draft text on whether multiple locations should be added by=20 the same provided-by. Action 1/2: Hannes to send text to editor's and review team covering this issue This issue being, it is known limitation that when a proxy inserts a location by=20 reference, that the UA user is not a rule maker (RFC 3693 specifies the=20 rulemaker). There is some suitable text in the RELO document that covers the=20 same issue. This issue was still to complete. Action 1/3: Brian to provide text relating to the usage of TLS. This issue was still to complete. Action 1/4: Hannes to send text (can be just key points to be covered) to=20 editor's and review team covering this issue. This issue concerned the adequacy of the security conditions. This issue is still to complete. Action 1/5: Keith to post to list stating that the agreement is to remove and=20 asking for WG consensus. This action was done to complete on Thursday 3rd May. Action 1/6: Keith to send mail to Cullen Jenning / Jason Fischl regarding the=20 need of draft-ietf-sip-certs to provide any documentation on this issue. This action had been done. No reaction so far. Action 1/7: Keith to send mail to list asking for WG consensus to agreement to=20 remove emergency call text from location-conveyance. This action would complete on Thursday 5th. It was agreed that the conclusion on=20 this action would specifically address Ted's concerns and Keith would ensure=20 that he does agree with this conclusion. Action 2/2: Keith to summarise emergency call decision to list, and also correspond directly with Ted to ensure he is part of WG consensus. With regard to the paragraph in section 1 it was agreed to keep the paragraph,=20 but to remove the word "frequently" and strike the last sentence. Section 4.3=20 had already gone as a result of other decisions. Section 6 would go in total as=20 a result of this action. Action 1/8: Brian to post proposed procedures to list for covering the above,=20 and obtain WG consensus to this proposal. This being: - location-conveyance in responses to give location of the UAS would be=20 specifically removed from the document. This should be done by a subsequent=20 request in the opposite direction. - that location in responses would relate to location of UAC for test, but=20 this would be a new procedure. This would need to be considered by the WG in a=20 list discussion. This action was still to do. Needs to be decided (on list) if the echo is all=20 locations or just the one used. Action 1/9: Henning to draft strawman proposal and initiate discussion among=20 review team in order to get the concepts correct, prior to SIP WG discussion. This action specifically related to the new procedures for error handling. Henning had drafted a proposal to the list on this. Keith would initiate a 7 day=20 call on this. Action 2/3: Keith to initiate a 7 day call on Henning's error handling proposal. 4) Continuation of agenda from previous discussion Previous agenda 11) PIDF-LO usage Comments: 121, 153A Key questions: Point usage deprecated? Proxy usage - what can proxy say about this location - is this in scope of=20 this document or does GEOPRIV need to handle it? This had been partly discussed in the previous call. James proposed to keep Geo example and to keep the old 4.3 example (location by=20 reference). He would move the old civic example into a new appendix.=20 In the geo example, point would be updated to position, and therefore aligns=20 with GML 3.1 This should incorporate all Martin's comments in this area. Comment 153A had been partly covered by the action items. Proxy addition has to=20 be determined on context. Additional work may have to be done in future outside=20 the scope of this WG item. It was suggested that future work would allow the UAC=20 to request the proxy to insert a location on it's behalf, but this work would=20 only be done if people think it is desirable. therefore agreed to make no=20 recommendations on proxy usage. previous agenda 12) URI issues Comments: 7, 64 Key questions: In regard to comment 7, the review team had no answer to the question but=20 decided it did not impact the contents of draft-ietf-sip-location-conveyance. previous agenda 13) Routeing query allowed issues Comments: 11 Key questions: Brian agreed to seek resolution of this comment on the GEOPRIV list, as this is=20 essentially an UPDATE to a GEOPRIV document. The complete list of WGLC items for=20 Brian to resolve as this action is 6, 11 and 26. Action 2/4: Brian to address the issues relating to "Routeing query allowed=20 issues" GEOPRIV list and seek consensus there as to if and how this should be=20 documented. previous agenda 14) Retransmission allowed issues Comments: 61A Key questions: Is mechanism needed? In regard to the proxy adding location, it was agreed that this is=20 underspecified. Route-query-allowed is the new parameter, but retransmission=20 allowed is the RFC 4119 parameter. Agreed that this also needs to be resolved with the (old) agenda item 13) issues. previous agenda 15) Terminology usage Comments: 1, 19, 43A, 101A, 116B, 129A Key questions - Are "by value" and "by reference" the appropriate terms? - Is LbyR a using protocol? - Are there any circumstances where we need to talk about LIS rather than LS? In regard to the "by value" and "by reference" concern, noted that by value is=20 XML and by reference is URL. In location-conveyance, the Geolocation header=20 field is always a URL. Various discussions around use of "internal" and=20 "external", "direct location" and "indirect location". Whether we should do this=20 by definitions, or by inventing new terms? Action 2/5: Henning to make strawman terminology proposal to the review team.=20 Also need to check as part of this discussion whether all instances of the=20 existing terminology should be changed or just a specific subset. There was no current agreement on this, so the document remains unchanged in=20 regard to this terminology issue unless specific proposals can be agreed. In regards to the "LIS" usage, it was agreed that all remaining usages of this=20 could either be deleted or renamed, so that we do not have to mention the names=20 of the servers. In the examples, "lis" would become "ls".=20 previous agenda 16) Pull mechanisms Comments: 25, 144A Key questions: Are the mentioned pull mechanism valid, given that we don't cover them at=20 all? Location by reference is not push. It was however agreed that the editor's would=20 try and delete all references to "pull" and "push" as it appeared that this was=20 a concept that did not help the document, i.e. use words like "defined a mechanism for conveying the location", rather than "push". 5) Other issues It was identified that we use the term "conveyance" without explaining what we=20 mean by it. Either define, or change to a new term. Pointed out that the first=20 sentence of document defines it. 6) Conclusion No immediate need seen for another review team call. We have action items to=20 work out, and list consensus calls to complete, and the authors then need to=20 provide a new draft and a summary of the comment handling. WG chairs and editor's will decide what future action is required by the review=20 team. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 13:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNV4-000517-B8; Wed, 16 May 2007 13:41:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoNV2-00050z-RP for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 13:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoNV2-00050r-Hi for sip@ietf.org; Wed, 16 May 2007 13:41:20 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoNV1-0005oi-5e for sip@ietf.org; Wed, 16 May 2007 13:41:20 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l4GHeENo010866 for ; Wed, 16 May 2007 12:41:17 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 12:41:09 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 19:41:07 +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, 16 May 2007 19:41:07 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001190972@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Last Call: draft-ietf-rohc-sigcomp-sip (Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)) to Proposed Standard Thread-Index: AceW+kSx7WxZk0VhS9OnicnPvT6qggA5rgSQ From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 16 May 2007 17:41:07.0172 (UTC) FILETIME=[620BBA40:01C797E1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] FW: [rohc] Last Call: draft-ietf-rohc-sigcomp-sip (Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As SIP WG chair) As this contains some SIP header field parameters, I draw you attention the the following IESG last call. The document was reviewed by a number of SIP experts during WGLC in the ROHC group, and the attention of the SIP WG was drawn to this document at the time. If you have comments on the draft, please follow the instructions in the mail below, and DO NOT reply to this message. Regards Keith -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Tuesday, May 15, 2007 3:04 PM To: IETF-Announce Cc: rohc@ietf.org Subject: [rohc] Last Call: draft-ietf-rohc-sigcomp-sip (Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)) to Proposed Standard=20 The IESG has received a request from the Robust Header Compression WG (rohc) to consider the following document: - 'Applying Signaling Compression (SigComp) to the Session Initiation=20 Protocol (SIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-05-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 10482&rfc_flag=3D0 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 16 17:53:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRQZ-0005Az-FL; Wed, 16 May 2007 17:52:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoRQX-0004ua-KW for sip-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 17:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRQX-0004s9-8i for sip@ietf.org; Wed, 16 May 2007 17:52:57 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoRQW-00014v-2Y for sip@ietf.org; Wed, 16 May 2007 17:52:57 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007051621525501300a7qsve>; Wed, 16 May 2007 21:52:55 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4GLqtZZ002631 for ; Wed, 16 May 2007 17:52:55 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4GLqsfN002627; Wed, 16 May 2007 17:52:54 -0400 Date: Wed, 16 May 2007 17:52:54 -0400 Message-Id: <200705162152.l4GLqsfN002627@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: (jae@cs.columbia.edu) Subject: Re: [Sip] Draft revision on SIP UA discovery using Zeroconf References: X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This I-D seems to be a difficult read. It's like reading code, it describes all the mechanics, but there is no description at the beginning saying what the point of the mechanism is. (Unless you're already familiar with the problems DNS-SD is supposed to solve, maybe, but this is the SIP WG.) It seems like an improved organization would be: - description of the overall problem and the activities that the mechanism supports - information that a UA is expected to possess, e.g., display name, SIP URI, etc. - description of the mechanisms to carry out the supported activities Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 04:51:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobi7-0002mS-Lv; Thu, 17 May 2007 04:51:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hobi6-0002mN-5t for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 04:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hobi5-0002mF-Pr for sip@ietf.org; Thu, 17 May 2007 04:51:45 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hobi4-0000l7-HC for sip@ietf.org; Thu, 17 May 2007 04:51:45 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 17 May 2007 09:51:43 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sips if possible, sip if not. - a question on sip-sips-03 draft Thread-Index: AceYYJfPB+Ll0neERMi7a/KmABXGKw== From: "Attila Sipos" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What if you want to use sips where possible but don't mind a fallback to sip? So, if someone makes a call using sips in request URI and the called person doesn't have a sips URI registered, I guess the proxy will return 404 not found. So then then caller might say, ok, there isn't a sips URI, I will now try a sip URI and see if that works. The problem is that the called person might not have registered anything at all. So in such cases, the 2nd call attempt using sip is a waste. Is there a requirement for some kind of new SIP response code which says something like "no SIPS URI registered but there is a SIP one"? What are the potential problems with this idea? Regards, Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 04:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoboQ-00086u-9y; Thu, 17 May 2007 04:58:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HoboP-00086p-77 for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 04:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoboO-00086h-Tn for sip@ietf.org; Thu, 17 May 2007 04:58:16 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoboO-00019R-Gp for sip@ietf.org; Thu, 17 May 2007 04:58:16 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Sorry found the answer (RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft) Date: Thu, 17 May 2007 09:58:15 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C24332@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sips if possible, sip if not. - a question on sip-sips-03 draft Thread-Index: AceYYJfPB+Ll0neERMi7a/KmABXGKwAAM64Q From: "Attila Sipos" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry... found my answer.... While guessing a SIPS AOR from a known SIP AOR and using it to initiate a request is a valid thing to do, doing the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it) is not a valid thing to do as it would be a security downgrade. Although "downgrading" from SIPS to SIP is disallowed, it is possible that a redirect server or UAS sends a 3XX response to a request to a Audet Expires October 15, 2007 [Page 8] =20 Internet-Draft SIPS April 2007 SIPS URI with a contact header field containing a SIP URI. [RFC3261]/8.1.3.4 states that if the UAC decide to recurse to the SIP URI, it "SHOULD inform the user". When a proxy is handling the 3XX, it can obviously not indicate anything to the user that it is being redirected from SIPS to SIP: therefore, proxies would not be able recurse on the contact header field, and instead would either forward the 3XX to the UAC or reject the request. -----Original Message----- From: Attila Sipos=20 Sent: 17 May 2007 09:52 To: sip@ietf.org Subject: [Sip] sips if possible,sip if not. - a question on sip-sips-03 draft What if you want to use sips where possible but don't mind a fallback to sip? So, if someone makes a call using sips in request URI and the called person doesn't have a sips URI registered, I guess the proxy will return 404 not found. So then then caller might say, ok, there isn't a sips URI, I will now try a sip URI and see if that works. The problem is that the called person might not have registered anything at all. So in such cases, the 2nd call attempt using sip is a waste. Is there a requirement for some kind of new SIP response code which says something like "no SIPS URI registered but there is a SIP one"? What are the potential problems with this idea? Regards, Attila _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 12:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj4W-0006OE-KU; Thu, 17 May 2007 12:43:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hoj4V-0006O8-Or for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 12:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj4V-0006NJ-Ep for sip@ietf.org; Thu, 17 May 2007 12:43:23 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoj4U-0000Ee-5b for sip@ietf.org; Thu, 17 May 2007 12:43:23 -0400 Received: from [192.168.1.5] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4HFohKP009092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 May 2007 10:50:45 -0500 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Thu, 17 May 2007 11:43:13 -0500 To: "Attila Sipos" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 17, 2007, at 3:51 AM, Attila Sipos wrote: > > Is there a requirement for some kind of new SIP response code which > says something like "no SIPS URI registered but there is a SIP one"? > You mean like a 302? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 13:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojLZ-0005XC-Tt; Thu, 17 May 2007 13:01:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HojLY-0005X4-AX for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojLY-0005Ww-0p for sip@ietf.org; Thu, 17 May 2007 13:01:00 -0400 Received: from [217.205.209.100] (helo=vegastream.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojLV-0007Ni-Ny for sip@ietf.org; Thu, 17 May 2007 13:01:00 -0400 Content-Class: urn:content-classes:message Subject: RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 17 May 2007 18:00:56 +0100 Message-ID: <8F1F2062CA7D754A838F0E66097D23A0C2433D@veg-brk-svr-pri.vegastream> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Thread-Index: AceYon5voItln6xSR0apJFDPbknP3QAAghrw From: "Attila Sipos" To: , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >> > Is there a requirement for some kind of new SIP response code which >> > says something like "no SIPS URI registered but there is a SIP = one"? >> > >> >>You mean like a 302? embarassing. it's very quiet on sip@ietf.org today. Shouldn't there be some people arguing about sips or something? -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 17 May 2007 17:43 To: Attila Sipos Cc: sip@ietf.org Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft On May 17, 2007, at 3:51 AM, Attila Sipos wrote: > > Is there a requirement for some kind of new SIP response code which > says something like "no SIPS URI registered but there is a SIP one"? > You mean like a 302? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 13:09:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojTH-0003rT-1m; Thu, 17 May 2007 13:08:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HojTF-0003rL-Gr for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojTF-0003rD-7A for sip@ietf.org; Thu, 17 May 2007 13:08:57 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojTD-0002ZA-TV for sip@ietf.org; Thu, 17 May 2007 13:08:57 -0400 Received: from [192.168.1.5] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4HGGLmG009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 May 2007 11:16:22 -0500 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0C2433D@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0C2433D@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D197646-CFF3-4D2F-8794-062856A1C373@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Thu, 17 May 2007 12:08:53 -0500 To: "Attila Sipos" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 17, 2007, at 12:00 PM, Attila Sipos wrote: > >>>> Is there a requirement for some kind of new SIP response code which >>>> says something like "no SIPS URI registered but there is a SIP >>>> one"? >>>> >>> >>> You mean like a 302? > > embarassing. > > it's very quiet on sip@ietf.org today. > > Shouldn't there be some people arguing about sips or something? > Nah, we solved all that stuff. And we're tired of arguing about location conveyance. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 13:11:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojVU-0005po-7C; Thu, 17 May 2007 13:11:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HojVS-0005lr-KS for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojVS-0005l9-AL for sip@ietf.org; Thu, 17 May 2007 13:11:14 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojVR-0003G2-Ux for sip@ietf.org; Thu, 17 May 2007 13:11:14 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.13.8/IER-o) with ESMTP id l4HHBDaD005353 for ; Thu, 17 May 2007 12:11:13 -0500 (CDT) Received: from [135.180.240.247] (volker-hopc2.dnrc.bell-labs.com [135.180.240.247]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4HHBDI24908 for ; Thu, 17 May 2007 13:11:13 -0400 (EDT) Message-ID: <464C8CB1.4030906@bell-labs.com> Date: Thu, 17 May 2007 13:11:13 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: sip Content-Type: multipart/mixed; boundary="------------030203050906000803060104" X-Scanned-By: MIMEDefang 2.57 on 192.11.226.42 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --------------030203050906000803060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Below is a draft that proposes a correction to the definition of 503 (Service Unavailable) responses in RFC 3261. The goal of this draft is to avoid some of the problems that have been identified with 503, however, it does not attempt to provide a full blown overload control solution. http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-00.txt Comments, thoughts are highly appreciated. Thanks, Volker --------------030203050906000803060104 Content-Type: message/rfc822; name="I-D ACTION:draft-hilt-sip-correction-503-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-hilt-sip-correction-503-00.txt" Received: from ihemail4.lucent.com (ihemail4.dmz.lucent.com [135.245.2.39]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4EJp1I15702 for ; Mon, 14 May 2007 15:51:01 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.ORG [156.154.16.145]) by ihemail4.lucent.com (8.13.8/IER-i) with ESMTP id l4EJov5P011109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 May 2007 14:50:58 -0500 (CDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngYn-0006dv-GX; Mon, 14 May 2007 15:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HngYV-0006W2-AG for i-d-announce@ietf.org; Mon, 14 May 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HngYV-00053F-0X for i-d-announce@ietf.org; Mon, 14 May 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 698FC26EB2 for ; Mon, 14 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HngYU-0006Sr-69 for i-d-announce@ietf.org; Mon, 14 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 14 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: I-D ACTION:draft-hilt-sip-correction-503-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Scanned-By: MIMEDefang 2.57 on 135.245.0.39 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response Author(s) : V. Hilt Filename : draft-hilt-sip-correction-503-00.txt Pages : 9 Date : 2007-5-14 Overload occurs in the Session Initiation Protocol (SIP) when SIP servers have insufficient resources to process all SIP messages they receive. The SIP protocol specified in RFC 3261 provides the 503 (Service Unavailable) response code as a remedy for servers under overload. However, the current definition of 503 (Service Unavailable) has problems and can in fact amplify an overload condition. This document proposes an essential correction to RFC 3261 that avoids these problems and helps SIP servers to better cope with overload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hilt-sip-correction-503-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hilt-sip-correction-503-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hilt-sip-correction-503-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-14123858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hilt-sip-correction-503-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hilt-sip-correction-503-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-14123858.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------030203050906000803060104 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------030203050906000803060104-- From sip-bounces@ietf.org Thu May 17 13:46:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok3b-0006v0-QP; Thu, 17 May 2007 13:46:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hok3a-0006uh-9L for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 13:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hok3Z-0006uZ-W2 for sip@ietf.org; Thu, 17 May 2007 13:46:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hok3Y-0004vL-Lg for sip@ietf.org; Thu, 17 May 2007 13:46:29 -0400 Received: from [192.168.1.5] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4HGoK3w009750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 May 2007 11:53:19 -0500 In-Reply-To: <8F1F2062CA7D754A838F0E66097D23A0C24332@veg-brk-svr-pri.vegastream> References: <8F1F2062CA7D754A838F0E66097D23A0C24332@veg-brk-svr-pri.vegastream> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: Sorry found the answer (RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft) Date: Thu, 17 May 2007 12:27:50 -0500 To: Attila Sipos X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 17, 2007, at 3:58 AM, Attila Sipos wrote: > > Sorry... found my answer.... > > > While guessing a SIPS AOR from a known SIP > AOR and using it to initiate a request is a valid thing to do, > doing > the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using > it) > is not a valid thing to do as it would be a security downgrade. > > Although "downgrading" from SIPS to SIP is disallowed, it is > possible > that a redirect server or UAS sends a 3XX response to a request > to a > > > > Audet Expires October 15, 2007 > [Page 8] > > Internet-Draft SIPS April > 2007 > > > SIPS URI with a contact header field containing a SIP URI. > [RFC3261]/8.1.3.4 states that if the UAC decide to recurse to > the SIP > URI, it "SHOULD inform the user". When a proxy is handling the > 3XX, > it can obviously not indicate anything to the user that it is being > redirected from SIPS to SIP: therefore, proxies would not be able > recurse on the contact header field, and instead would either > forward > the 3XX to the UAC or reject the request. > I wonder if it would be worth making an explicit suggestion in the SIPS that proxies provide a 302 if they receive a SIPS request for an AOR for which they have only a SIP binding? We could also make a stronger recommendtation that if you don't know whether an AOR is SIPS or SIP you would try SIPS first and expect a 302 if you guess wrong. This could reduce the inclination for people to try SIP first. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 17 14:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hol70-0000GJ-0J; Thu, 17 May 2007 14:54:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hol6y-0000GD-5o for sip-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 14:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hol6x-0000G5-SO for sip@ietf.org; Thu, 17 May 2007 14:54:03 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hol6w-0002yL-K7 for sip@ietf.org; Thu, 17 May 2007 14:54:03 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI7000MP8I283@usaga01-in.huawei.com> for sip@ietf.org; Thu, 17 May 2007 11:54:02 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI7005508HZPQ@usaga01-in.huawei.com> for sip@ietf.org; Thu, 17 May 2007 11:54:02 -0700 (PDT) Date: Thu, 17 May 2007 13:52:19 -0500 From: Spencer Dawkins Subject: Re: Sorry found the answer (RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft) To: Dean Willis , Attila Sipos Message-id: <34b401c798b4$7f6e78b0$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8F1F2062CA7D754A838F0E66097D23A0C24332@veg-brk-svr-pri.vegastream> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Dean, > I wonder if it would be worth making an explicit suggestion in the SIPS > that proxies provide a 302 if they receive a SIPS request for an AOR for > which they have only a SIP binding? We could also make a stronger > recommendtation that if you don't know whether an AOR is SIPS or SIP you > would try SIPS first and expect a 302 if you guess wrong. This could > reduce the inclination for people to try SIP first. This seems very helpful (perhaps even "required" - I don't know how UACs know how to fall back without this type of guidance). Thanks, Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 03:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howbr-0000Jv-6U; Fri, 18 May 2007 03:10:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Howbq-0000Jm-Lm for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 03:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howbq-0000Jb-Ay for sip@ietf.org; Fri, 18 May 2007 03:10:42 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Howbo-0001e9-OO for sip@ietf.org; Fri, 18 May 2007 03:10:42 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4I7AEuw009523; Fri, 18 May 2007 10:10:38 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:10:37 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:10:37 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:10:36 +0300 Message-ID: <464D516C.4010501@nokia.com> Date: Fri, 18 May 2007 10:10:36 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "ext Anders Lindgren C (TN/EAB)" References: <6D34F0B7D5BCB246A42380744457CA36E508B4@esealmw107.eemea.ericsson.se> In-Reply-To: <6D34F0B7D5BCB246A42380744457CA36E508B4@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 07:10:36.0672 (UTC) FILETIME=[A2230800:01C7991B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] Re: Your draft xcap-diff-event:Sending etag information in the Subscribe. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Anders Lindgren C (TN/EAB) wrote: > > Hello Jari, > I have a comments/question related to how your draft > _http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01.txt_ > can be applied in a environment limited bandwidth e.g. where the > subscription is done over an air interface. > > As I see it an XCAP document can be quite large. It may also happen > that the changes can be quite rare and not that big. > > A user can also have quite many documents that he/she wants to > subscribe for. > My view is that the memory in a client is not a bottleneck today and > therefore it is quite likely that it is possible that clients will > keep a copy of needed XCAP documents. > > The method in the draft ( see 4.7) to limit air traffic is to use the > "niemi-sip-subnot-etags" draft. That makes it possible to supress some > Notifies. > Although there are no examples, i'm proposing Suppress-Notify-If-Match: * after the initial notification, if you need this re-subscription with aggregate mode. > > This method has one disadvantage and that is that it is based on one > etag per subscription and therefore not that useful when we are > subscribing for lots of documents in one Sunsbribe dialogue. The > method is useful when nothing has changed, but not that useful for > small changes to large documents as the client needs to do a XCAP GET > in order to fetch the version that the server has. > it is useful to allow to suppress the notify, when you want to just send some rpc-commands to the other end. And certainly it doesn't do what you want, if it were to be used with content sync with several http resources. > > My proposal is to use a different method to limit the information sent > over the air. > The proposal is that if the client includes a body with all documents > and etags it has, the Notifier shall respond with a Nofify that > contains all XML patches needed to be able to patch the client's > version of the documents to the same version as the server has > With http you can do instance manipulation (rfc3229). But it requires versioning support on the XCAP server, which is overkill for the problem at-hand, imo (). So sure you could add an even more sophisticated stuff with sip here by combining or listing locally already existing resources. So you could optimize this but you would add yet more complexity and "interesting" error cases... Also if you had every resource in sync you would practically send the same information within subscribe body what you will receive now within the initial notify (and of course, upstream speed may be much slower than downstream). > If it is possible to send version information for all documents that > the client has stored already in the first Subscribe, the Notifier can > use this information to start to send the XML patches to patch the > client versions to the latest server versions (instead of sending only > the link to the documents ) if the server has such patches stored. > > If it can not provide the patches, it needs to send the link as today. > If the server has the same version as the client, the server can send > the link with the etag just to confirm that it has the same version. > > Taking an example from OMA; the existing OMA-TS-XDM-Core (see > _http://www.openmobilealliance.org/release_program/docs/CopyrightClick.asp?pck=XDM&file=V1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A.pdf_ > > has an xml schema that it is possible to reuse for the version > information from the client, (see > _http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_0_1.xsd_) > as it contains per AUID the URIs for a document plus the etag. > > This proposal will introduce a requirement that the XCAP server needs > to have a optional patch history function to support this function, if > not supported the server can do as in the existing draft. > > Comments? > > Regards > Anders > Still for newly created resources with rapid following changes the same aggregate problem will exist. thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 03:12:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howdu-00020m-91; Fri, 18 May 2007 03:12:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Howds-00020W-Up for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 03:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Howds-00020O-Ku for sip@ietf.org; Fri, 18 May 2007 03:12:48 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Howdq-00022q-3n for sip@ietf.org; Fri, 18 May 2007 03:12:48 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4I7ChoR030501; Fri, 18 May 2007 10:12:43 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:12:29 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:12:29 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:12:29 +0300 Message-ID: <464D51DC.5080909@nokia.com> Date: Fri, 18 May 2007 10:12:28 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "ext Sofie Lassborn (TN/EAB)" References: <3C26DE1DC0C6724B8928D40F216ECFB004A82551@esealmw103.eemea.ericsson.se> In-Reply-To: <3C26DE1DC0C6724B8928D40F216ECFB004A82551@esealmw103.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 18 May 2007 07:12:29.0124 (UTC) FILETIME=[E529D840:01C7991B] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext11.nokia.com id l4I7ChoR030501 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] Re: Questions on XCAP Diff Event draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Sofie Lassborn (TN/EAB) wrote: > > Hi Jari, > > I have some thoughts and questions regarding the XCAP Diff Event draft=20 > (draft-urpalainen-sip-xcap-diff-event-01). > What will the notification look like if a requested document cannot be=20 > found? No body or only element? > good catch, actually the current xcap-diff format requires at least one=20 document update (but it should be fixed), so either of your proposals=20 should work. > > What does it mean if a notification contains the document element with=20 > doc-selector but no etag attributes? > This is not defined in xcap-diff format, as it is sort of an error case=20 with documents. With xcap-component subscription it is somewhat vague.=20 When etags are included, you could e.g. do a conditional replace based=20 on them. So perhaps it is better to add etags always, certainly I don't=20 want any negotiations about this. > > OMA has implemented an architecure where the XCAP server has been=20 > split up into so called XCAP Document Management Servers (XDMS). Each=20 > XDMS handles separate AUIDs. If a subscription is for several=20 > documents distributed over several XDMSes (different auids), what=20 > should then the notification look like if there are some documents=20 > that don=92t exist or directories that are empty and there are some=20 > documents that cannot be reached because one XDMS does not answer? > Good question. I could do a counterquestion, why did OMA do that, and=20 instead let the implementations figure these out ? I mean this=20 introduces a lot of complexity and several difficult error cases. But=20 the intention here (in the i-d) is to do what is typical in the ietf,=20 i.e. just to define the interface and let the implementations do the=20 rest. But back to the question, the i-d says that you send in the=20 initial notify request what you can "read", so probably you could still=20 compose this from separate responses from several xdms, as results from=20 different auids should be orthogonal. But hey, I really wouldn't=20 personally like to implement it ;-). > > According to RFC 3265 the "pending" value of the Subscripton-State=20 > header indicates that the subscription has been received, but that=20 > policy information is insufficient to accept or deny the subscription=20 > at this time. Is the intention in section 4.7 in the draft that the=20 > subscription state should be pending if the resource the subscription=20 > is for cannot be found? What would then the subscription state be for=20 > a subscription for white space separated resources where some can be=20 > found and some cannot be found? > While using "pending" I was wandering that I'll produce somewhat=20 confusing text..., I'll try to clarify this. > > Generation of a =93first full response=94 notification might take time=20 > especially if the subscription is for several AUIDs, spread over=20 > several XCAP Document Management Servers, at the same time. Is there a=20 > need for an =93initial=94 initial notification that may be sent to the=20 > subscriber before the =93full response=94 can be sent? > In practice, I wouldn't anticipate that you would need this empty body=20 or neutral body notify, i.e. clients will most likely keep the state=20 information based on the response of subscribe. But the spec allows to=20 use it although null body interpretation with content-type header _is_=20 interesting. > > Chapter 4.7, second paragraph > It is unclear to me what is meant by =93=85it MUST fall back to sending= =20 > all component changes again for this resource.=94 Is the intention that= =20 > the server shall send a =93full response=94 as in an initial notificati= on=20 > (my preferred interpretation)? Or is the intention that the server=20 > shall send several notifications with the patches not aggregated? > > Best regards, > Sofie > The latter, after sending the http reference, the server does not know=20 when the client has really read the content, thus no aggregation allowed=20 with "rapidly changing resources" thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 10:29:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3SD-0007dO-0R; Fri, 18 May 2007 10:29:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hp3SB-0007dF-Co for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 10:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp3SB-0007d7-30 for sip@ietf.org; Fri, 18 May 2007 10:29:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp3S9-0005aH-QS for sip@ietf.org; Fri, 18 May 2007 10:29:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 May 2007 10:29:09 -0400 X-IronPort-AV: i="4.14,552,1170651600"; d="scan'208"; a="60603053:sNHT83669056" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4IET9c6006360; Fri, 18 May 2007 10:29:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4IESoC8025956; Fri, 18 May 2007 14:29: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.1830); Fri, 18 May 2007 10:29:06 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:29:05 -0400 Message-ID: <464DB831.8040607@cisco.com> Date: Fri, 18 May 2007 10:29:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> In-Reply-To: <464AF68A.4010105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 14:29:06.0010 (UTC) FILETIME=[E3B96BA0:01C79958] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=983; t=1179498549; x=1180362549; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Paul=20Kyzivat=20; bh=2p/ihFA3bfaV+VtuE561jvAkpB20nfN9J4NcQCykjuA=; b=B8PPrpXhSdE8jMNB/fUDlg8/s0syDuECUM0LjkdJJ1VwaC/Sn2gGxHzXRXjB+uTN5/BZqZ9V icu95y99Z1zIEv40Xb3bcQL6zmpgZG4rJZWoq9H/WI3uf1KC3HSTpDI/; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sip@ietf.org, Francois Audet , Gonzalo Camarillo , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If we need any more motivation for this work, here is a quote from draft-ietf-mmusic-file-transfer-mech-02. The MMUSIC working group considered a few alternative approaches before deciding to use the encoding described in Section 6. In particular, the working group looked at the MIME 'external-body' type and the use of a single SDP parameter. A MIME 'external-body' could potentially be used to describe the file to be transfered. In fact, many of the SDP parameters this specification defines are also supported by 'external-body' body parts. The MMUSIC working group decided not to use 'external-body' body parts because a number of existing offer/answer implementations do not support multipart bodies. I don't think we can hold that work hostage until there is better support for multipart. But that means there is one more thing that has been screwed around because of the lack of multipart support. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 11:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4KX-00043V-Iq; Fri, 18 May 2007 11:25:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hp4KW-00043Q-KW for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 11:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4KW-00043I-Am for sip@ietf.org; Fri, 18 May 2007 11:25:20 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp4KW-0006Vl-1O for sip@ietf.org; Fri, 18 May 2007 11:25:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4IFPBK28445; Fri, 18 May 2007 15:25:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Sorry found the answer (RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft) Date: Fri, 18 May 2007 10:25:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1082F3B6@zrc2hxm0.corp.nortel.com> In-Reply-To: <34b401c798b4$7f6e78b0$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sorry found the answer (RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft) Thread-Index: AceYtN3KVwuxnPpLSUemODwOUewJHQAq64ig References: <8F1F2062CA7D754A838F0E66097D23A0C24332@veg-brk-svr-pri.vegastream> <34b401c798b4$7f6e78b0$6601a8c0@china.huawei.com> From: "Francois Audet" To: "Spencer Dawkins" , "Dean Willis" , "Attila Sipos" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, that has been added to the current working draft. But, it's not necessarily 302 (it could be 301 for example). And certain proxies may elect to just plainly reject it. That's all covered in the current working draft.=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Thursday, May 17, 2007 11:52 > To: Dean Willis; Attila Sipos > Cc: sip@ietf.org > Subject: Re: Sorry found the answer (RE: [Sip] sips if=20 > possible, sip if not. - a question on sip-sips-03 draft) >=20 > Hi, Dean, >=20 > > I wonder if it would be worth making an explicit suggestion in the =20 > > SIPS that proxies provide a 302 if they receive a SIPS=20 > request for an =20 > > AOR for which they have only a SIP binding? We could also make a =20 > > stronger recommendtation that if you don't know whether an AOR is =20 > > SIPS or SIP you would try SIPS first and expect a 302 if you guess =20 > > wrong. This could reduce the inclination for people to try=20 > SIP first. >=20 > This seems very helpful (perhaps even "required" - I don't=20 > know how UACs know how to fall back without this type of guidance). >=20 > Thanks, >=20 > Spencer=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 11:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4UM-0006Xl-Io; Fri, 18 May 2007 11:35:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hp4UL-0006Xg-E5 for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 11:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4UL-0006XY-4P for sip@ietf.org; Fri, 18 May 2007 11:35:29 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp4UJ-0007gN-SF for sip@ietf.org; Fri, 18 May 2007 11:35:29 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4IFYSH25562; Fri, 18 May 2007 15:34:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] Date: Fri, 18 May 2007 10:35:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1082F3E1@zrc2hxm0.corp.nortel.com> In-Reply-To: <464C8CB1.4030906@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] Thread-Index: AceYpn5xzhufUB4mTr+hOFof1qFdYQAuy2mg References: <464C8CB1.4030906@bell-labs.com> From: "Francois Audet" To: "Volker Hilt" , "sip" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Volker, Can I explain why you believe that for "small" servers (supporting < 20 clients) you believe that the retry after is problematic? I don't think it's that clear from the draft. And if so, would there be a way to mitigate the oscillation while allowing the Retry-After? I'm a little concerned about a rule that seems somewhat vague on this.=20 > -----Original Message----- > From: Volker Hilt [mailto:volkerh@bell-labs.com]=20 > Sent: Thursday, May 17, 2007 10:11 > To: sip > Subject: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] >=20 > Below is a draft that proposes a correction to the definition=20 > of 503 (Service Unavailable) responses in RFC 3261. The goal=20 > of this draft is to avoid some of the problems that have been=20 > identified with 503, however, it does not attempt to provide=20 > a full blown overload control solution. >=20 > http://www.ietf.org/internet-drafts/draft-hilt-sip-correction- 503-00.txt >=20 > Comments, thoughts are highly appreciated. >=20 > Thanks, >=20 > Volker >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 18 22:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpEgN-0007NX-4S; Fri, 18 May 2007 22:28:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HpEgL-0007NR-7p for sip-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 22:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpEgK-0007NJ-Si for sip@ietf.org; Fri, 18 May 2007 22:28:32 -0400 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpEgI-0003Fa-L9 for sip@ietf.org; Fri, 18 May 2007 22:28:32 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc15) with ESMTP id <20070519022830b1500sn3hhe>; Sat, 19 May 2007 02:28:30 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4J2STr5024912 for ; Fri, 18 May 2007 22:28:29 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4J2STUe024908; Fri, 18 May 2007 22:28:29 -0400 Date: Fri, 18 May 2007 22:28:29 -0400 Message-Id: <200705190228.l4J2STUe024908@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> (dean.willis@softarmor.com) Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Dean Willis > Is there a requirement for some kind of new SIP response code which > says something like "no SIPS URI registered but there is a SIP one"? You mean like a 302? Is a 302 allowed to offer a sip: URI as a contact for a sips: request-URI? 380 looks like it is intended to have this sort of effect, but its content has not been standardized: 21.3.5 380 Alternative Service The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization. And 416 seems plausible: 8.1.3.5 Processing 4xx Responses If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. But I can't tell if that last sentence is just a nit and should have read "... this time, using a SIP or SIPS URI." Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 21 05:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq40N-0000Bk-BG; Mon, 21 May 2007 05:16:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hq40M-0000BU-0P for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq40L-0000BL-JB; Mon, 21 May 2007 05:16:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hq40K-0003GI-8Z; Mon, 21 May 2007 05:16:37 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1179738994!10492990!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19467 invoked from network); 21 May 2007 09:16:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 21 May 2007 09:16:35 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4L9GY6Y017592; Mon, 21 May 2007 02:16:34 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l4L9GYP1014065; Mon, 21 May 2007 04:16:34 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4L9GWiZ014056; Mon, 21 May 2007 04:16:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 May 2007 17:16:25 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0434D7A7@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3pcc controller requirements Thread-Index: AcebiLS16GOiwefLSKGrz/qQ+onPAg== X-Priority: 1 Priority: Urgent Importance: high From: "Avasarala Ranjit-A20990" To: X-Vontu: Pass X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sipping@ietf.org Subject: [Sip] 3pcc controller requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918466712==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0918466712== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79B88.B54ABCC9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79B88.B54ABCC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Is there any doc or link where I can find the general requirements of a SIP based 3rd party call controller?=20 Thanks In Advance Regards Ranjit ------_=_NextPart_001_01C79B88.B54ABCC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3pcc controller requirements

Hi

Is there any doc or = link where I can find the general requirements of a SIP based 3rd party = call controller?

Thanks In = Advance

Regards
Ranjit

------_=_NextPart_001_01C79B88.B54ABCC9-- --===============0918466712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0918466712==-- From sip-bounces@ietf.org Mon May 21 05:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq4FG-00023L-5K; Mon, 21 May 2007 05:32:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hq4FD-00022S-Gp for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq4FC-000228-TP; Mon, 21 May 2007 05:31:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq4FB-0007Jb-76; Mon, 21 May 2007 05:31:58 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 974792077B; Mon, 21 May 2007 11:31:56 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-79-4651670ca404 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 764BC203D8; Mon, 21 May 2007 11:31:56 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 11:31:56 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 11:31:55 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D4DFF2578; Mon, 21 May 2007 12:31:55 +0300 (EEST) Message-ID: <4651670B.8060400@ericsson.com> Date: Mon, 21 May 2007 12:31:55 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "SUNIL J. KUMAR" References: <46290C498CFE7D409A02931CADABB3FA31A83E@mail2.spanservices.com> In-Reply-To: <46290C498CFE7D409A02931CADABB3FA31A83E@mail2.spanservices.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2007 09:31:56.0048 (UTC) FILETIME=[DF7A6100:01C79B8A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org, sipping@ietf.org Subject: [Sip] Re: [Sipping] 3pcc controller requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, 3pcc is described in the following RFC: http://www.ietf.org/rfc/rfc3725.txt Cheers, Gonzalo SUNIL J. KUMAR wrote: > This can be handled by SIP B2BUA. Please refer Camrillo draft on SIP > Border Controller for this/ > > > > /Sunil > > > > ------------------------------------------------------------------------ > > *From:* Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] > *Sent:* Monday, May 21, 2007 2:46 PM > *To:* sip@ietf.org > *Cc:* sipping@ietf.org > *Subject:* [Sipping] 3pcc controller requirements > *Importance:* High > > > > Hi > > Is there any doc or link where I can find the general requirements of a > SIP based 3rd party call controller? > > Thanks In Advance > > *Regards* > *Ranjit* > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 21 06:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq4kH-0004Hk-OJ; Mon, 21 May 2007 06:04:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hq4kG-0004Ha-9T for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 06:04:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq4kF-0004HS-Vy for sip@ietf.org; Mon, 21 May 2007 06:04:03 -0400 Received: from mail56.messagelabs.com ([193.109.254.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hq4kF-0005Rc-D7 for sip@ietf.org; Mon, 21 May 2007 06:04:03 -0400 X-VirusChecked: Checked X-Env-Sender: rayees.khan@digitalk.com X-Msg-Ref: server-8.tower-56.messagelabs.com!1179741841!124326617!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [213.249.130.39] Received: (qmail 25205 invoked from network); 21 May 2007 10:04:01 -0000 Received: from mail.digitalk.com (HELO svr-zoe.digitalk.com) (213.249.130.39) by server-8.tower-56.messagelabs.com with SMTP; 21 May 2007 10:04:01 -0000 Received: from svr-elmo.digitalk.com (unverified) by svr-zoe.digitalk.com (Content Technologies SMTPRS 4.3.19) with ESMTP id ; Mon, 21 May 2007 11:04:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 May 2007 11:04:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] 3pcc controller requirements thread-index: AcebiLS16GOiwefLSKGrz/qQ+onPAgAAaHkg From: "Rayees Khan" To: "Avasarala Ranjit-A20990" , X-Spam-Score: 0.3 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Subject: [Sip] RE: [Sipping] 3pcc controller requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1474621812==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1474621812== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79B8F.5AEFA7DF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79B8F.5AEFA7DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I think good point to begin with is BCP for 3PCC RFC 3725.=20 Additional requirements are imposed for transcoding in RFC 4117 and Camarillo's "Framework for transcoding with SIP" =20 =20 regards Rayees =20 ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: Monday, May 21, 2007 10:16 AM To: sip@ietf.org Cc: sipping@ietf.org Subject: [Sipping] 3pcc controller requirements Importance: High Hi=20 Is there any doc or link where I can find the general requirements of a SIP based 3rd party call controller?=20 Thanks In Advance=20 Regards=20 Ranjit=20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ ---------------------------------------------------------------------------= ------- IMPORTANT The information contained in this e-mail any attachments is intended only for the named recipient and may be privileged or confidential. If you are not the intended recipient, please notify us immediately=20 on +44 (0)1908 425000 and do not disclose, copy, distribute=20 or take any action based on the contents of this e-mail.=20 You should understand and accept that, when communicating with us by e-mail, it is not a totally secure communication medium. We accept no liability for any direct, indirect or consequential loss arising from any action taken in reliance on the information contained in this e-mail and give no warranty or representation as to its accuracy or reliability. DIGITALK has the facility to monitor and read both incoming and outgoing communications by e-mail. In line with industry efforts to reduce the proliferation of Un-Solicited SPAM messages,=20 DIGITALK uses various methods including Reverse-DNS=20 lookups and ban-lists to prevent malicious content reaching our users. This message and any attachments has been scanned for known viruses. However, we would advise you to ensure the content is indeed virus free. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or breach of confidentiality in relation to transmissions sent by e-mail. VAT No: GB 876 3287 81. Reg No: 3080801 Place of Registration: England Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes ---------------------------------------------------------------------------= -------" ------_=_NextPart_001_01C79B8F.5AEFA7DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3pcc controller requirements
 
I=20 think good point to begin with is BCP for 3PCC RFC=20 3725. 
Additional requirements are imposed for=20 transcoding in RFC 4117 and Camarillo's "Framework for transcoding wit= h=20 SIP"
 
 
regards
Rayees

 
From: Avasarala Ranjit-A20990=20 [mailto:ranjit@motorola.com]
Sent: Monday, May 21, 2007 10:16=20 AM
To: sip@ietf.org
Cc: sipping@ietf.org
Subject:= =20 [Sipping] 3pcc controller requirements
Importance:=20 High

Hi

Is there any doc or link = where I=20 can find the general requirements of a SIP based 3rd party call controller?= =20

Thanks In Advance =

Regards= =20
Ranjit= =20


___________________________________________________________________= ___
This=20 email has been scanned by the MessageLabs Email Security System.
For mor= e=20 information please visit http://www.messagelabs.com/email=20
______________________________________________________________________<= BR>

---------------------------------------------------------------------------= -------
IMPORTANT The information contained in this e-mail any
attachments is intended only for the named recipient and may be
privileged or confidential.

If you are not the intended recipient, please notify us immediately
on +44 (0)1908 425000 and do not disclose, copy, distribute
or take any action based on the contents of this e-mail.

You should understand and accept that, when communicating with us
by e-mail, it is not a totally secure communication medium.

We accept no liability for any direct, indirect or consequential loss
arising from any action taken in reliance on the information contained
in this e-mail and give no warranty or representation as to its accuracy
or reliability.

DIGITALK has the facility to monitor and read both incoming
and outgoing communications by e-mail. In line with industry efforts
to reduce the proliferation of Un-Solicited SPAM messages,
DIGITALK uses various methods including Reverse-DNS
lookups and ban-lists to prevent malicious content reaching our users.

This message and any attachments has been scanned for known
viruses. However, we would advise you to ensure the content is
indeed virus free. We do not, to the extent permitted by law, accept
any liability (whether in contract, negligence or otherwise) for any virus<= BR> infection and/or external compromise of security and/or breach of
confidentiality in relation to transmissions sent by e-mail.

VAT No: GB 876 3287 81. Reg No: 3080801
Place of Registration: England
Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes
---------------------------------------------------------------------------= -------"
 ------_=_NextPart_001_01C79B8F.5AEFA7DF-- --===============1474621812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1474621812==-- From sip-bounces@ietf.org Mon May 21 17:19:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqFI8-0006Mn-79; Mon, 21 May 2007 17:19:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqFI6-0006Mh-Ir for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 17:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqFI5-0006MZ-TN for sip@ietf.org; Mon, 21 May 2007 17:19:41 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqFI4-0003Tq-Hv for sip@ietf.org; Mon, 21 May 2007 17:19:41 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l4LLJdDw025370; Mon, 21 May 2007 16:19:39 -0500 (CDT) Received: from [127.0.0.1] ([135.104.20.65]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4LLJdI10938; Mon, 21 May 2007 17:19:39 -0400 (EDT) Message-ID: <46520CE9.6030001@bell-labs.com> Date: Mon, 21 May 2007 17:19:37 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] References: <464C8CB1.4030906@bell-labs.com> <1ECE0EB50388174790F9694F77522CCF1082F3E1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1082F3E1@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, > > Can I explain why you believe that for "small" servers (supporting < 20 > clients) you believe > that the retry after is problematic? I don't think it's that clear from > the draft. > The problem of 503 with Retry-After is described in greater detail in Sections 4.1 and 4.3 of draft-ietf-sipping-overload-reqs-00. In short, 503 with Retry-After may lead to the oscillation of traffic a server receives and the shifting of load between servers. > And if so, would there be a way to mitigate the oscillation while > allowing the Retry-After? > The proposed changes 5. and 6. would still allow a Retry-After header, although it would be restricted to a single request. An alternative to proposed change 1. (i.e. to not recommend the use of Retry-After in 503) could be use a Retry-After value based on milliseconds. This would provide a more fine grained control to overloaded proxies and may avoid some of the problems the current header has. It would work for servers irrespective of the number of clients. However, it would change the semantics of the Retry-After value. Overall, the goal of this draft is not to introduce a new overload control mechanism (which certainly should avoid traffic oscillations) but rather to see how far we can get with modest changes to the existing spec. > I'm a little concerned about a rule that seems somewhat vague on this. > >> -----Original Message----- >> From: Volker Hilt [mailto:volkerh@bell-labs.com] >> Sent: Thursday, May 17, 2007 10:11 >> To: sip >> Subject: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] >> >> Below is a draft that proposes a correction to the definition >> of 503 (Service Unavailable) responses in RFC 3261. The goal >> of this draft is to avoid some of the problems that have been >> identified with 503, however, it does not attempt to provide >> a full blown overload control solution. >> >> http://www.ietf.org/internet-drafts/draft-hilt-sip-correction- > 503-00.txt >> Comments, thoughts are highly appreciated. >> >> Thanks, >> >> Volker >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Volker Hilt Bell Labs / Alcatel-Lucent phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 21 18:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqG2D-0007GN-5r; Mon, 21 May 2007 18:07:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqG2A-0007GF-My for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 18:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqG2A-0007G7-Ct for sip@ietf.org; Mon, 21 May 2007 18:07:18 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqG29-0006xi-1m for sip@ietf.org; Mon, 21 May 2007 18:07:18 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l4LM7FUe017975 for ; Mon, 21 May 2007 17:07:16 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 17:06:33 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 00:06: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: Tue, 22 May 2007 00:06:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxg== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 21 May 2007 22:06:30.0936 (UTC) FILETIME=[496A0980:01C79BF4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) This is to announce a Working Group Last Call on http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framew ork-01.txt The WGLC is for 3 weeks and will end on 11th June 2007. Please respond to the editor, and to the SIP mailing list with comments. This WGLC is being held in conjunction with the two related documents in the SIPPING group, see mail below: Regards Keith ------------------------------------------------------------------------ ----------------------------- Hi all, This is to announce Working Group Last Call on the following documents: http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-data set-04.txt (Recently updated to address the merging issue discussed on the mailing list) http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-03 .txt (Unchanged since prior to IETF-68) This WGLC will end on 11 June 2007. Since the WG has previously reviewed these documents, the plan is to keep the same set of reviewers that previously volunteered:=20 Bob Penfield, Shida Schubert, Flemming Andreasen, Roni Even However, anyone additional that would like to volunteer would be appreciated to get a fresh set of eyes on the document.=20 Feedback should be sent to the authors' email addresses (which is cc'ed using the tools alias in the above for your convenience) and please copy the SIPPING mailing list. =20 Note: the original plan was to WGLC this set of documents along with the framework document that moved to SIP. So, stay tuned for an announcement on the SIP list of the WGLC plans for that document.=20 Thanks, Mary SIPPING WG co-chair ------------------------------------------------------------------------ ------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 21 20:49:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIYq-0002j6-1p; Mon, 21 May 2007 20:49:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqIYp-0002iw-5o for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 20:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIYo-0002il-S3 for sip@ietf.org; Mon, 21 May 2007 20:49:10 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqIYZ-000161-Bt for sip@ietf.org; Mon, 21 May 2007 20:49:10 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4M0mpS02381; Tue, 22 May 2007 00:48:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Mon, 21 May 2007 19:48:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> In-Reply-To: <200705190228.l4J2STUe024908@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Thread-Index: AceZvXL0MsnCTUGNQ/Gwp/BWO77THACTU1JQ References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> <200705190228.l4J2STUe024908@dragon.ariadne.com> From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 416 is ok for "SIPS is not OK, but SIP will work".=20 It is NOT ok for "SIP is not OK, but SIPS will works". For that, you can use 302 or 301.=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Friday, May 18, 2007 19:28 > To: sip@ietf.org > Subject: Re: [Sip] sips if possible, sip if not. - a question=20 > on sip-sips-03 draft >=20 > From: Dean Willis >=20 > > Is there a requirement for some kind of new SIP response=20 > code which > > says something like "no SIPS URI registered but there is=20 > a SIP one"? >=20 > You mean like a 302? >=20 > Is a 302 allowed to offer a sip: URI as a contact for a sips: > request-URI? >=20 > 380 looks like it is intended to have this sort of effect,=20 > but its content has not been standardized: >=20 > 21.3.5 380 Alternative Service >=20 > The call was not successful, but alternative services are possible. >=20 > The alternative services are described in the message body of the > response. Formats for such bodies are not defined here, and may be > the subject of future standardization. >=20 > And 416 seems plausible: >=20 > 8.1.3.5 Processing 4xx Responses >=20 > If a 416 (Unsupported URI Scheme) response is received (Section > 21.4.14), the Request-URI used a URI scheme not supported by the > server. The client SHOULD retry the request, this time,=20 > using a SIP > URI. >=20 > But I can't tell if that last sentence is just a nit and=20 > should have read "... this time, using a SIP or SIPS URI." >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 21 21:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIrc-0007Rs-Er; Mon, 21 May 2007 21:08:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqIrb-0007Rn-Ek for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 21:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqIrb-0007Rf-4z for sip@ietf.org; Mon, 21 May 2007 21:08:35 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqIrZ-0006u7-RE for sip@ietf.org; Mon, 21 May 2007 21:08:35 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4M18VS07022; Tue, 22 May 2007 01:08:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] Date: Mon, 21 May 2007 20:07:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF108943BC@zrc2hxm0.corp.nortel.com> In-Reply-To: <46520CE9.6030001@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] [Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt] Thread-Index: Aceb7cJO6WfbCJ3lSYe71WnMtwmzjwAH6fqA References: <464C8CB1.4030906@bell-labs.com> <1ECE0EB50388174790F9694F77522CCF1082F3E1@zrc2hxm0.corp.nortel.com> <46520CE9.6030001@bell-labs.com> From: "Francois Audet" To: "Volker Hilt" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thank you. That does answer my question.=20 > -----Original Message----- > From: Volker Hilt [mailto:volkerh@bell-labs.com]=20 > Sent: Monday, May 21, 2007 14:20 > To: Audet, Francois (SC100:3055) > Cc: sip > Subject: Re: [Sip] [Fwd: I-D=20 > ACTION:draft-hilt-sip-correction-503-00.txt] >=20 > Francois, > >=20 > > Can I explain why you believe that for "small" servers=20 > (supporting <=20 > > 20 > > clients) you believe > > that the retry after is problematic? I don't think it's that clear=20 > > from the draft. > >=20 > The problem of 503 with Retry-After is described in greater=20 > detail in Sections 4.1 and 4.3 of=20 > draft-ietf-sipping-overload-reqs-00. In short, > 503 with Retry-After may lead to the oscillation of traffic a=20 > server receives and the shifting of load between servers. >=20 > > And if so, would there be a way to mitigate the oscillation while=20 > > allowing the Retry-After? > >=20 > The proposed changes 5. and 6. would still allow a=20 > Retry-After header, although it would be restricted to a=20 > single request. >=20 > An alternative to proposed change 1. (i.e. to not recommend=20 > the use of Retry-After in 503) could be use a Retry-After=20 > value based on milliseconds. This would provide a more fine=20 > grained control to overloaded proxies and may avoid some of=20 > the problems the current header has. It would work for=20 > servers irrespective of the number of clients.=20 > However, it would change the semantics of the Retry-After value. >=20 > Overall, the goal of this draft is not to introduce a new=20 > overload control mechanism (which certainly should avoid=20 > traffic oscillations) but rather to see how far we can get=20 > with modest changes to the existing spec. >=20 > > I'm a little concerned about a rule that seems somewhat=20 > vague on this.=20 > >=20 > >> -----Original Message----- > >> From: Volker Hilt [mailto:volkerh@bell-labs.com] > >> Sent: Thursday, May 17, 2007 10:11 > >> To: sip > >> Subject: [Sip] [Fwd: I-D=20 > ACTION:draft-hilt-sip-correction-503-00.txt] > >> > >> Below is a draft that proposes a correction to the=20 > definition of 503=20 > >> (Service Unavailable) responses in RFC 3261. The goal of=20 > this draft=20 > >> is to avoid some of the problems that have been identified=20 > with 503,=20 > >> however, it does not attempt to provide a full blown=20 > overload control=20 > >> solution. > >> > >> http://www.ietf.org/internet-drafts/draft-hilt-sip-correction- > > 503-00.txt > >> Comments, thoughts are highly appreciated. > >> > >> Thanks, > >> > >> Volker > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > --=20 > Volker Hilt Bell Labs / Alcatel-Lucent > phone: +1 732 332 6432 101 Crawfords Corner Rd > email: volkerh@bell-labs.com Holmdel, NJ 07733 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 04:21:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPbq-000142-QU; Tue, 22 May 2007 04:20:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqPbo-00013m-RY for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 04:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqPbo-00013e-A7 for sip@ietf.org; Tue, 22 May 2007 04:20:44 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqPbn-0001MU-6F for sip@ietf.org; Tue, 22 May 2007 04:20:44 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 589292128E; Tue, 22 May 2007 10:20:42 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-63-4652a7dab0ae Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 374452131C; Tue, 22 May 2007 10:20:42 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 10:20:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 May 2007 10:20:41 +0200 Message-ID: <3C26DE1DC0C6724B8928D40F216ECFB004AB6F7F@esealmw103.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on your draft xcap-diff-event: synchronization of notifications and XCAP GET Thread-Index: AcecShXtKlMZKZgVRBGctn6ps0o0NA== From: "Sofie Lassborn \(TN/EAB\)" To: "Jari Urpalainen" , X-OriginalArrivalTime: 22 May 2007 08:20:41.0984 (UTC) FILETIME=[1659B800:01C79C4A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Subject: [Sip] Thoughts on your draft xcap-diff-event: synchronization of notifications and XCAP GET X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688597935==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0688597935== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79C4A.15FDD3C1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79C4A.15FDD3C1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, I have some thoughts about the synchronization in the client of the notifications of changes and retrieval of documents over XCAP. Scenario 1: "No xml patching" The subscription is in the "no xml patching" mode and a notification containing a link to a document and a new etag "aaa" is received by the client. Immediately after the notification has been sent out a change is made to the document by another client and the etag is updated to "bbb". The first client makes an XCAP GET request to retrieve the document and receives a document with etag "bbb" which is different from the one received in the notification.=20 The client knows how to use the retrieved document until the notification with the same etag, "bbb", is received and then when another notification with etag "ccc" is received the client makes a new XCAP GET request for this document. If the client in the XCAP GET receives a document with a different etag than "ccc", the client can use this document as it is newer than the one with etag "ccc". =20 -> Scenario 1 has no issues. Scenario 2: "xml patching" The subscription is in the "xml patching" mode and a notification containing a link to a document and a new etag "aaa" is received by the client. Immediately after the notification has been sent out a change is made to the document by another client and the etag is updated to "bbb". The first client makes an XCAP GET request to retrieve the document and receives a document with etag "bbb" which is different from the one received in the notification.=20 The client ignores all notifications until the notification with etag "bbb" has been received. When another notification with an etag "ccc" is received the client uses the included patch on his document. I.e. the client buffers all notifications that arrives while the client performs the XCAP GET and when the new document is received it applys all patches with newer etags than the one in the retrieved document.=20 -> Scenario 2 has no issues. Scenario 3: "Aggregation" The subscription is in the "aggregation" mode and a notification containing a link to a document and a new etag "aaa" is received by the client.=20 The client makes an XCAP GET request to retrieve the document and receives a document with etag "aaa".=20 Several changes are made to the document by another client and the etag is updated to "bbb" and then "ccc". A new "aggregated" notification with previous-etag "aaa" and new-etag "ccc" is received and the client uses the included patches on his document. -> Scenario 3 has no issues. Scenario 4: "Aggregation and unlucky timing" The subscription is in the "aggregation" mode and a notification containing a link to a document and a new etag "aaa" is received by the client. Immediately after the notification has been sent out a change is made to the document by another client and the etag is updated to "bbb". The first client makes an XCAP GET request to retrieve the document and receives a document with etag "bbb" which is different from the one received in the notification. Another change is made to the document by some other client and the etag is updated to "ccc".=20 When the "aggregated" notification with previous-etag "aaa" and new-etag "ccc" is received the client does not know how to apply these patches to his document. -> Scenario 4 has issues. Possible solution: In the aggregated notification each change that has been made to the document is represented by a patch operation.=20 Each patch operation is specified together with an etag value. The client will then be able to only apply those changes that has been made to the document with etag "bbb" and after.=20 For this to work the schemas for the patch operation elements in draft-ietf-simple-xml-patch-ops-02 need to be updated with etag attributes. In conjunction to the above scenarios I also wonder what the thoughts with aggregation are. Is the main idea that it should be possible for the server to "aggregate" several changes on a document into one or fewer patch elements, i.e. "hide" some of the changes to the client. This kind of functionality would be very complex to implement and scenario 4 above would not be solved. If instead the intention is to "aggregate" several patches in one notification and to reduce the number of notifications sent then each patch element could also be linked with the etag of the changed document and solve scenario 4 above. With the existing schemas this could be done by having several document elements pointing to the same document but with different etags and one patch element for each document element. My proposal, which would produce smaller xcap-diff documents, is instead to update the schemas for the patch operation elements in draft-ietf-simple-xml-patch-ops-02 with etag attributes. Best regards, Sofie ------_=_NextPart_001_01C79C4A.15FDD3C1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thoughts on your draft xcap-diff-event: synchronization of = notifications and XCAP GET

Hi = Jari,
I have some = thoughts about the synchronization in the client of the notifications of = changes and retrieval of documents over XCAP.

Scenario 1: = "No xml patching"
The subscription is in the "no xml patching" mode and a = notification containing a link to a document and a new etag = “aaa” is received by the client. Immediately after the = notification has been sent out a change is made to the document by = another client and the etag is updated to "bbb".
The first client makes an XCAP GET request to retrieve the document and = receives a document with etag “bbb” which is different from = the one received in the notification.
The client knows how to use the retrieved document until the = notification with the same etag, "bbb", is received and then = when another notification with etag "ccc" is received the = client makes a new XCAP GET request for this document. If the client in = the XCAP GET receives a document with a different etag than = "ccc", the client can use this document as it is newer than = the one with etag "ccc". 
-> Scenario 1 has no issues.
Scenario 2: = "xml patching"
The subscription is in the "xml patching" mode and a = notification containing a link to a document and a new etag = “aaa” is received by the client. Immediately after the = notification has been sent out a change is made to the document by = another client and the etag is updated to "bbb".
The first client makes an XCAP GET request to retrieve the document and = receives a document with etag “bbb” which is different from = the one received in the notification.
The client ignores all notifications until the notification with etag = "bbb" has been received. When another notification with an = etag "ccc" is received the client uses the included patch on = his document. I.e. the client buffers all notifications that arrives = while the client performs the XCAP GET and when the new document is = received it applys all patches with newer etags than the one in the = retrieved document.
-> Scenario 2 has no issues.
Scenario 3: = "Aggregation"
The subscription is in the "aggregation" mode and a = notification containing a link to a document and a new etag = “aaa” is received by the client.
The client makes an XCAP GET request to retrieve the document and = receives a document with etag “aaa”.
Several changes are made to the document by another client and the etag = is updated to "bbb" and then "ccc". A new = "aggregated" notification with previous-etag "aaa" = and new-etag "ccc" is received and the client uses the = included patches on his document.
-> Scenario 3 has no issues.
Scenario 4: = "Aggregation and unlucky timing"
The subscription is in the "aggregation" mode and a = notification containing a link to a document and a new etag = “aaa” is received by the client. Immediately after the = notification has been sent out a change is made to the document by = another client and the etag is updated to "bbb".
The first client makes an XCAP GET request to retrieve the document and = receives a document with etag “bbb” which is different from = the one received in the notification. Another change is made to the = document by some other client and the etag is updated to = "ccc".
When the "aggregated" notification with previous-etag = "aaa" and new-etag "ccc" is received the client does = not know how to apply these patches to his document.
-> Scenario 4 has issues.
Possible = solution:
In the aggregated notification each change that has been made to the = document is represented by a patch operation.
Each patch operation is specified together with an etag value. The = client will then be able to only apply those changes that has been made = to the document with etag “bbb” and after.
For this to work the schemas for the patch operation elements in = draft-ietf-simple-xml-patch-ops-02 need to be updated with etag = attributes.

In conjunction to = the above scenarios I also wonder what the thoughts with aggregation = are. Is the main idea that it should be possible for the server to = "aggregate" several changes on a document into one or fewer = patch elements, i.e. "hide" some of the changes to the client. = This kind of functionality would be very complex to implement and = scenario 4 above would not be solved. If instead the intention is to = "aggregate" several patches in one notification and to reduce = the number of notifications sent then each patch element could also be = linked with the etag of the changed document and solve scenario 4 above. = With the existing schemas this could be done by having several document = elements pointing to the same document but with different etags and one = patch element for each document element. My proposal, which would = produce smaller xcap-diff documents, is instead to update the schemas = for the patch operation elements in draft-ietf-simple-xml-patch-ops-02 = with etag attributes.

Best regards,
Sofie


------_=_NextPart_001_01C79C4A.15FDD3C1-- --===============0688597935== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0688597935==-- From sip-bounces@ietf.org Tue May 22 07:02:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqS8C-0008JT-4L; Tue, 22 May 2007 07:02:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqS8A-0008FL-9t for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 07:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqS89-0008De-8a for sip@ietf.org; Tue, 22 May 2007 07:02:17 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqS87-0005VV-Hb for sip@ietf.org; Tue, 22 May 2007 07:02:17 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4MB20h4026198; Tue, 22 May 2007 14:02:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 14:02:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 14:02:00 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 14:02:00 +0300 Message-ID: <4652CDA7.7030905@nokia.com> Date: Tue, 22 May 2007 14:01:59 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "ext Sofie Lassborn (TN/EAB)" References: <3C26DE1DC0C6724B8928D40F216ECFB004AB6F7F@esealmw103.eemea.ericsson.se> In-Reply-To: <3C26DE1DC0C6724B8928D40F216ECFB004AB6F7F@esealmw103.eemea.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 22 May 2007 11:02:00.0251 (UTC) FILETIME=[9F0C10B0:01C79C60] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext14.nokia.com id l4MB20h4026198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: sip@ietf.org Subject: [Sip] Re: Thoughts on your draft xcap-diff-event: synchronization of notifications and XCAP GET X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Sofie Lassborn (TN/EAB) wrote: > > Hi Jari, > I have some thoughts about the synchronization in the client of the=20 > notifications of changes and retrieval of documents over XCAP. > > Scenario 1: "No xml patching" > The subscription is in the "no xml patching" mode and a notification=20 > containing a link to a document and a new etag =93aaa=94 is received by= =20 > the client. Immediately after the notification has been sent out a=20 > change is made to the document by another client and the etag is=20 > updated to "bbb". > The first client makes an XCAP GET request to retrieve the document=20 > and receives a document with etag =93bbb=94 which is different from the= =20 > one received in the notification. > The client knows how to use the retrieved document until the=20 > notification with the same etag, "bbb", is received and then when=20 > another notification with etag "ccc" is received the client makes a=20 > new XCAP GET request for this document. If the client in the XCAP GET=20 > receives a document with a different etag than "ccc", the client can=20 > use this document as it is newer than the one with etag "ccc". > -> Scenario 1 has no issues. > Scenario 2: "xml patching" > The subscription is in the "xml patching" mode and a notification=20 > containing a link to a document and a new etag =93aaa=94 is received by= =20 > the client. Immediately after the notification has been sent out a=20 > change is made to the document by another client and the etag is=20 > updated to "bbb". > The first client makes an XCAP GET request to retrieve the document=20 > and receives a document with etag =93bbb=94 which is different from the= =20 > one received in the notification. > The client ignores all notifications until the notification with etag=20 > "bbb" has been received. When another notification with an etag "ccc"=20 > is received the client uses the included patch on his document. I.e.=20 > the client buffers all notifications that arrives while the client=20 > performs the XCAP GET and when the new document is received it applys=20 > all patches with newer etags than the one in the retrieved document. > -> Scenario 2 has no issues. > Scenario 3: "Aggregation" > The subscription is in the "aggregation" mode and a notification=20 > containing a link to a document and a new etag =93aaa=94 is received by= =20 > the client. > The client makes an XCAP GET request to retrieve the document and=20 > receives a document with etag =93aaa=94. > Several changes are made to the document by another client and the=20 > etag is updated to "bbb" and then "ccc". A new "aggregated"=20 > notification with previous-etag "aaa" and new-etag "ccc" is received=20 > and the client uses the included patches on his document. > -> Scenario 3 has no issues. > Scenario 4: "Aggregation and unlucky timing" > The subscription is in the "aggregation" mode and a notification=20 > containing a link to a document and a new etag =93aaa=94 is received by= =20 > the client. Immediately after the notification has been sent out a=20 > change is made to the document by another client and the etag is=20 > updated to "bbb". > The first client makes an XCAP GET request to retrieve the document=20 > and receives a document with etag =93bbb=94 which is different from the= =20 > one received in the notification. Another change is made to the=20 > document by some other client and the etag is updated to "ccc". > When the "aggregated" notification with previous-etag "aaa" and=20 > new-etag "ccc" is received the client does not know how to apply these=20 > patches to his document. > -> Scenario 4 has issues. > Possible solution: > In the aggregated notification each change that has been made to the=20 > document is represented by a patch operation. > Each patch operation is specified together with an etag value. The=20 > client will then be able to only apply those changes that has been=20 > made to the document with etag =93bbb=94 and after. > For this to work the schemas for the patch operation elements in=20 > draft-ietf-simple-xml-patch-ops-02 need to be updated with etag=20 > attributes. > right, this is the culprit, but i don't want to disallow aggregation. > > In conjunction to the above scenarios I also wonder what the thoughts=20 > with aggregation are. Is the main idea that it should be possible for=20 > the server to "aggregate" several changes on a document into one or=20 > fewer patch elements, i.e. "hide" some of the changes to the client.=20 > This kind of functionality would be very complex to implement and=20 > scenario 4 above would not be solved. > Well i have implemented a really stupid, but very simple logic in=20 , i.e. there's also an xml=20 diff utility which produces a diff document of two documents (let's say=20 initial and updated document). So i'll disagree that it were very=20 complex to implement (~lk lines of C code). And I'm certain that there=20 are better ways to implement it... And btw. even for this "very simple" xcap client i'd propose a similar=20 model, i.e. you would produce xcap updates based on diffing, at least my=20 personal experience showed that it was indeed very difficult to combine=20 internal patching and sending proper xcap requests at the same time ;-).=20 I mean all possible error cases and keeping a reasonable state machine... > > If instead the intention is to "aggregate" several patches in one=20 > notification and to reduce the number of notifications sent then each=20 > patch element could also be linked with the etag of the changed=20 > document and solve scenario 4 above. With the existing schemas this=20 > could be done by having several document elements pointing to the same=20 > document but with different etags and one patch element for each=20 > document element. My proposal, which would produce smaller xcap-diff=20 > documents, is instead to update the schemas for the patch operation=20 > elements in draft-ietf-simple-xml-patch-ops-02 with etag attributes. > > Best regards, > Sofie > So we would have etag history in two places ? (and it would mean=20 updating diff format) and would be somewhat shorter format (and even=20 more optimizations are possible). However, I still think the proposed=20 one is the best compromise which allows aggregation. This is definitely=20 a rare case and thus it is fully _optional_ both for the server and the=20 client (and as is xml-patching optional). So the non-aggregate mode is=20 the default mode with patching, but clients may try to use the aggregate=20 mode as well (which isn't as elegant as one would want, but possible).=20 Someday, it may be possible to have also e.g. proper versioning in the=20 xcap server, and then this protocol handshake ugliness disappears with=20 aggregate mode. We might want to optimize xml-patching mode, but that's=20 another thing. thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 13:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYD4-000069-Uw; Tue, 22 May 2007 13:31:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqYD3-000063-QN for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 13:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYD3-00005s-Gj for sip@ietf.org; Tue, 22 May 2007 13:31:45 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqYD1-0000Q2-8a for sip@ietf.org; Tue, 22 May 2007 13:31:45 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070522173140m13007hnfue>; Tue, 22 May 2007 17:31:42 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4MHVd3X002996 for ; Tue, 22 May 2007 13:31:39 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4MHVdBP002992; Tue, 22 May 2007 13:31:39 -0400 Date: Tue, 22 May 2007 13:31:39 -0400 Message-Id: <200705221731.l4MHVdBP002992@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> (audet@nortel.com) Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> <200705190228.l4J2STUe024908@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Francois Audet" 416 is ok for "SIPS is not OK, but SIP will work". It is NOT ok for "SIP is not OK, but SIPS will works". For that, you can use 302 or 301. What I like about 380 is that it seems to be designed for situations where the calling user should be consulted, as opposed to 301/302, which implementations seem to take as instructions for automatic redirection. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 13:38:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYJs-0005jr-61; Tue, 22 May 2007 13:38:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqYJr-0005jl-0W for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 13:38:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYJq-0005jd-NE for sip@ietf.org; Tue, 22 May 2007 13:38:46 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqYJp-000374-D5 for sip@ietf.org; Tue, 22 May 2007 13:38:46 -0400 Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4MGkCmu019795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 May 2007 11:46:17 -0500 In-Reply-To: <200705221731.l4MHVdBP002992@dragon.ariadne.com> References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> <200705190228.l4J2STUe024908@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> <200705221731.l4MHVdBP002992@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Tue, 22 May 2007 12:38:36 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 22, 2007, at 12:31 PM, Dale.Worley@comcast.net wrote: > From: "Francois Audet" > > 416 is ok for "SIPS is not OK, but SIP will work". > > It is NOT ok for "SIP is not OK, but SIPS will works". For that, > you can > use 302 or 301. > > What I like about 380 is that it seems to be designed for situations > where the calling user should be consulted, as opposed to 301/302, > which implementations seem to take as instructions for automatic > redirection. We've previously issued guidance on consulting users in the case of a 302. Part of the justification here is that redirecting someone who placed a "local" call to a destination for which they would be charged "long distance" (or any other situation producing a similar differentiation in cost) is something that users would want to be informed of and consent to. Are you suggesting that all such cases might be more appropriately dealt with by a 380? If so, how do we prevent malevolent types from abusing 302? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 14:00:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYet-00039i-NX; Tue, 22 May 2007 14:00:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqYes-0002vT-Fc for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 14:00:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqYer-0002oS-UD for sip@ietf.org; Tue, 22 May 2007 14:00:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqYeq-0005Rs-GW for sip@ietf.org; Tue, 22 May 2007 14:00:29 -0400 Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4MH80pU019894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 May 2007 12:08:00 -0500 In-Reply-To: <200705221731.l4MHVdBP002992@dragon.ariadne.com> References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> <200705190228.l4J2STUe024908@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> <200705221731.l4MHVdBP002992@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Tue, 22 May 2007 12:38:36 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 22, 2007, at 12:31 PM, Dale.Worley@comcast.net wrote: > From: "Francois Audet" > > 416 is ok for "SIPS is not OK, but SIP will work". > > It is NOT ok for "SIP is not OK, but SIPS will works". For that, > you can > use 302 or 301. > > What I like about 380 is that it seems to be designed for situations > where the calling user should be consulted, as opposed to 301/302, > which implementations seem to take as instructions for automatic > redirection. We've previously issued guidance on consulting users in the case of a 302. Part of the justification here is that redirecting someone who placed a "local" call to a destination for which they would be charged "long distance" (or any other situation producing a similar differentiation in cost) is something that users would want to be informed of and consent to. Are you suggesting that all such cases might be more appropriately dealt with by a 380? If so, how do we prevent malevolent types from abusing 302? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 16:33:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqb2Y-0000gL-7J; Tue, 22 May 2007 16:33:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqb2V-0000gF-BJ for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 16:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqb2T-0000fz-Eq for sip@ietf.org; Tue, 22 May 2007 16:33:02 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqb2S-0004nh-5Z for sip@ietf.org; Tue, 22 May 2007 16:33:01 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4MKVum13783; Tue, 22 May 2007 20:31:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Date: Tue, 22 May 2007 15:32:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF109020C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <200705221731.l4MHVdBP002992@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] sips if possible, sip if not. - a question on sip-sips-03 draft Thread-Index: AceclyJe3fM1QTglRiOt6C10nNwovwAFiG3w References: <8F1F2062CA7D754A838F0E66097D23A0012A3786@veg-brk-svr-pri.vegastream> <6C1F3DB4-F7DC-44A9-8970-2C3BEB2027C8@softarmor.com> <200705190228.l4J2STUe024908@dragon.ariadne.com> <1ECE0EB50388174790F9694F77522CCF1089439C@zrc2hxm0.corp.nortel.com> <200705221731.l4MHVdBP002992@dragon.ariadne.com> From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't agree at all with this 380 idea. To me, 380 basically redirects the request to a resource described in a message body instead of (or perhaps in addition to) in the Contact header. And, it's not standardized yet. I do not see anything in the description of 380 (section 21.3.5/RFC 3261) that implies that the Calling user should be consulted. Furthermore, RFC 3261 does state that for 3XX response that redirects from SIPS to SIP, you should consult the Calling party (see 8.1.3.4).=20 To top it off, since 380 is not defined today, it will be treated as a 300 by all existing UAs. So it really does not solve anything. > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Tuesday, May 22, 2007 10:32 > To: sip@ietf.org > Subject: Re: [Sip] sips if possible, sip if not. - a question=20 > on sip-sips-03 draft >=20 > From: "Francois Audet" >=20 > 416 is ok for "SIPS is not OK, but SIP will work".=20 >=20 > It is NOT ok for "SIP is not OK, but SIPS will works". For=20 > that, you can > use 302 or 301.=20 >=20 > What I like about 380 is that it seems to be designed for=20 > situations where the calling user should be consulted, as=20 > opposed to 301/302, which implementations seem to take as=20 > instructions for automatic redirection. >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 17:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqboO-0004JV-IO; Tue, 22 May 2007 17:22:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqboL-0004Ab-Ha for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 17:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqboJ-00043a-Mh for sip@ietf.org; Tue, 22 May 2007 17:22:28 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqboJ-0008J4-8x for sip@ietf.org; Tue, 22 May 2007 17:22:27 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 0E05420036; Tue, 22 May 2007 17:22:27 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19103-06; Tue, 22 May 2007 17:22:26 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 19F7020033; Tue, 22 May 2007 17:22:26 -0400 (EDT) To: " IETF SIP" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 22 May 2007 17:22:24 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/22/2007 05:22:23 PM, Serialize complete at 05/22/2007 05:22:23 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: Volker Hilt Subject: [Sip] Ambiguity, redirection and Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1938799765==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1938799765== Content-Type: multipart/alternative; boundary="=_alternative 007568F7852572E3_=" This is a multipart message in MIME format. --=_alternative 007568F7852572E3_= Content-Type: text/plain; charset="US-ASCII" Hi, I've had a look at this draft, and have a few questions / concerns. My apologies if this is covered somehow in the overload work (I am not following it closely), or if I missed some discussion going by. Basically, I think there are some potential problems with ambiguity, and also no good way to tell the client where (or if) to go somewhere else for service. Specifically: o 500 would become overloaded to mean either "something bad (but unspecified) happened" or "go somewhere else (maybe try again later)", but it seems impossible to determine which case it is. The name of this code implies only the former. o 503 changes its meaning to "I'm overloaded, back off (optionally don't try again for some time)". But this is not the name of this response -- it is Service Unavailable. The trouble is, there are many reasons why service may not be available, overload being just one. (Yes, I know this issue is raised as OPEN ISSUE 3 in the draft itself.) Proposals: 1. Can a new 5xx response code be defined specifically to handle overload scenarios, instead of overloading 503 / 500? This would have the explicit semantic of "I'm overloaded, back off (optionally for some time)". It could also have additional info on how the client should handle it (see next). 503 would keep its original meaning (go somewhere else), and 500 would keep its meaning (something bad happened). 2. Add a new header, to explicitly list one or more servers to go get service from, usable (at least) in 503 and the new 5xx, maybe 500 also. With this, 503 could have the additional semantic of "go somewhere else, and here's where" (optionally with a time to retry here). New 5xx could have the additional semantic of "I'm overloaded, go here instead" (optionally with a time to retry here). I can certainly see cases, even in overload handling, where the current server may want to explicitly send the client somewhere else, effectively redirecting to a different server. This could be either to an explicit server (or list of them), or just "go try somewhere else, you figure it out". Also handy for maintenance operations and for load sharing, possibly others. Lack of an explicit way to send clients elsewhere for service seems like a weakness overall. Hopefully, the above (or something along those lines) could help both dis-ambiguate, and help by acting as a redirection for those cases needing it. Minimally, it would at least make it easier to figure out (in the implementation) what the client is being told to do, and would make troubleshooting a whole lot easier. I do understand the desire to minimize changes. But it is also important to get the right behaviour, and not create situations open to too much interpretation. Yes, there would be lots of backwards compatibility issues, but any change in this stuff will have loads anyway. Just throwing some ideas out there to see if the flame throwers come out. (Donning my flame-proof suit now ..... ;-) Cheers, Peter Blatherwick --=_alternative 007568F7852572E3_= Content-Type: text/html; charset="US-ASCII"
Hi,  

I've had a look at this draft, and have a few questions / concerns.  My apologies if this is covered somehow in the overload work (I am not following it closely), or if I missed some discussion going by.  

Basically, I think there are some potential problems with ambiguity, and also no good way to tell the client where (or if) to go somewhere else for service.  Specifically:

o 500 would become overloaded to mean either "something bad (but unspecified) happened" or "go somewhere else (maybe try again later)", but it seems impossible to determine which case it is.   The name of this code implies only the former.  

o 503 changes its meaning to "I'm overloaded, back off (optionally don't try again for some time)".   But this is not the name of this response -- it is Service Unavailable.  The trouble is, there are many reasons why service may not be available, overload being just one.   (Yes, I know this issue is raised as OPEN ISSUE 3  in the draft itself.)  

Proposals:

1.  Can a new 5xx response code be defined specifically to handle overload scenarios, instead of overloading 503 / 500?  This would have the explicit semantic of "I'm overloaded, back off (optionally for some time)".   It could also have additional info on how the client should handle it (see next).  503 would keep its original meaning (go somewhere else), and 500 would keep its meaning (something bad happened).  

2.  Add a new header, to explicitly list one or more servers to go get service from, usable (at least) in 503 and the new 5xx, maybe 500 also.  With this, 503 could have the additional semantic of "go somewhere else, and here's where" (optionally with a time to retry here).   New 5xx could have the additional semantic of "I'm overloaded, go here instead" (optionally with a time to retry here).  

I can certainly see cases, even in overload handling, where the current server may want to explicitly send the client somewhere else, effectively redirecting to a different server. This could be either to an explicit server (or list of them), or just "go try somewhere else, you figure it out".   Also handy for maintenance operations and for load sharing, possibly others.  Lack of an explicit way to send clients elsewhere for service seems like a weakness overall.  Hopefully, the above (or something along those lines) could help both dis-ambiguate, and help by acting as a redirection for those cases needing it.  Minimally, it would at least make it easier to figure out (in the implementation) what the client is being told to do, and would make troubleshooting a whole lot easier.    

I do understand the desire to minimize changes.  But it is also important to get the right behaviour, and not create situations open to too much interpretation.  Yes, there would be lots of backwards compatibility issues, but any change in this stuff will have loads anyway.  

Just throwing some ideas out there to see if the flame throwers come out.   (Donning my flame-proof suit now .....    ;-)

Cheers,
Peter Blatherwick

--=_alternative 007568F7852572E3_=-- --===============1938799765== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1938799765==-- From sip-bounces@ietf.org Tue May 22 19:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdsx-0001YT-J2; Tue, 22 May 2007 19:35:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqdss-0001VY-Si for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 19:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqdss-0001VQ-If; Tue, 22 May 2007 19:35:18 -0400 Received: from kal-el.real.com ([207.188.23.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqdsr-00007o-5t; Tue, 22 May 2007 19:35:18 -0400 Received: from SEAL25947 ([::ffff:172.22.147.244]) (AUTH: LOGIN csteck, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by kal-el.real.com with esmtp; Tue, 22 May 2007 16:35:16 -0700 id 00080037.46537E34.00000801 From: "Chris Steck" To: "'mmusic \(E-mail\)'" , "'SIP IETF'" , avt@ietf.org Date: Tue, 22 May 2007 16:35:16 -0700 Message-ID: <00e501c79cc9$da1112a0$9383cf87@corp.real.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceck/nkw5z1pOa2QKGJBFBMtgRkbgAMleDw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Subject: [Sip] FW: [imtcmembers] IMTC Multimedia Standards Historical Archive - contributions? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org [Taking off my RealNetworks hat and putting on my IMTC CTO hat...] Sorry if you get this multiple times, A while back there were some threads going on pre-existing IPR for IP telephony and I encouraged people to drop the topic on the reflectors due to the unknown impact it may have on your causes to discuss and share information in that manner. Today I wanted to follow up by letting you all know about a valuable resource from IMTC which you can both leverage and help strengthen: The IMTC has an IPR AG which is developing a Multimedia Standards Historical Archive which contains contributions to standards meetings, reports, records of IPR licensing declarations, copies of standard organizations patent databases, publications such as journal articles, books, etc. See below for the process to contact the IMTC Secretariat if you think you have actual historical documentation that can benefit the archive. (or for that matter, want to join IMTC so that you can leverage the archive!) While the mail below is targeted at member companies, we also encourage non-members with documentation of interest to submit via the same process indicated below. (Please don't reply to this mail to the misc reflectors...) Thanks, Chris Steck CTO of IMTC -----Original Message----- From: Patrick Luthi [mailto:patrick.luthi@tandberg.com] Sent: Tuesday, May 22, 2007 8:55 AM To: IMTC Members Subject: [imtcmembers] IMTC Multimedia Standards Historical Archive - contributions? Dear IMTC Members, Many of you are aware of the existence of the IMTC Multimedia Standards Historical Archive and an increasing number of you are regularly consulting it. The IMTC Multimedia Standards Historical Archive contains contributions to standards meetings, reports, records of IPR licensing declarations, copies of standard organizations patent databases, publications such as journal articles, books, etc. Much of this information originated 10 to 25 years ago. Due to the huge amount of information, and the difficulty to find old documentation, archives containing this kind of information are incomplete, and must be built up step by step. For example, the ITU keeps fairly good records on ITU-T SG level, but none on the Rapporteurs Group level, which is the most important for IPR work. In addition, prior to 1995, the majority of records were still paper, making them almost inaccessible for today's purposes. Thanks to contributions made by members, we are slowly building up the IMTC archive. We would like to encourage members to submit their own old archived records to the IMTC to help us adding value to the historical archive. These contributions can be made in paper form, scanned copies of documents, or electronic files. Anything related to our industry that can help us complete our existing documentation is useful. We kindly ask members, willing to submit their records, to first send a list of documents to the Secretariat (jpolizotto@inventures.com). This will allow the IPR Activity Group to check if those documents are not already archived in the database and that way avoid submission of numerous duplicate records. For any questions on the Historical Archive or submissions of documents, please feel free to contact Jim Polizotto, IMTC Secretary (jpolizotto@inventures.com). Thank you and best regards, Patrick Luthi IMTC Vice President --- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 21:37:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqfnO-0003JX-KB; Tue, 22 May 2007 21:37:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqfnN-0003JR-3p for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 21:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqfnM-0003JJ-Pi for sip@ietf.org; Tue, 22 May 2007 21:37:44 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqfnM-0000SN-Dd for sip@ietf.org; Tue, 22 May 2007 21:37:44 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l4N1bapw017874; Tue, 22 May 2007 20:37:36 -0500 (CDT) Received: from [127.0.0.1] ([135.104.20.66]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4N1baI01098; Tue, 22 May 2007 21:37:36 -0400 (EDT) Message-ID: <46539ADD.6080900@bell-labs.com> Date: Tue, 22 May 2007 21:37:33 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: peter_blatherwick@mitel.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: IETF SIP Subject: [Sip] Re: Ambiguity, redirection and Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Peter, thanks much for the comments! > I've had a look at this draft, and have a few questions / concerns. My > apologies if this is covered somehow in the overload work (I am not > following it closely), or if I missed some discussion going by. > > Basically, I think there are some potential problems with ambiguity, and > also no good way to tell the client where (or if) to go somewhere else > for service. Specifically: > > o 500 would become overloaded to mean either "something bad (but > unspecified) happened" or "go somewhere else (maybe try again later)", > but it seems impossible to determine which case it is. The name of > this code implies only the former. > The changes proposed in the draft should not affect the 500 response code. In which respect would there be a change to 500? > o 503 changes its meaning to "I'm overloaded, back off (optionally don't > try again for some time)". But this is not the name of this response > -- it is Service Unavailable. The trouble is, there are many reasons > why service may not be available, overload being just one. (Yes, I > know this issue is raised as OPEN ISSUE 3 in the draft itself.) > 503 means that the "server is temporarily unable to process the request due to a temporary overloading or maintenance of the server." It seems that 503 is working reasonably well for maintenance but not for overload. So the question is if we can change the overload behavior without breaking the maintenance part. I believe that the proposed changes 1. - 4. would provide such a change if 503 is used as today for maintenance (with Retry-After) and without Retry-After as described for proxies under overload. > Proposals: > > 1. Can a new 5xx response code be defined specifically to handle > overload scenarios, instead of overloading 503 / 500? This would have > the explicit semantic of "I'm overloaded, back off (optionally for some > time)". It could also have additional info on how the client should > handle it (see next). 503 would keep its original meaning (go somewhere > else), and 500 would keep its meaning (something bad happened). > I think this would be closer to a new SIP extension for overload control, which I think is useful, than to a correction of RFC3261, which is the scope of this draft. > 2. Add a new header, to explicitly list one or more servers to go get > service from, usable (at least) in 503 and the new 5xx, maybe 500 also. > With this, 503 could have the additional semantic of "go somewhere > else, and here's where" (optionally with a time to retry here). New > 5xx could have the additional semantic of "I'm overloaded, go here > instead" (optionally with a time to retry here). > > I can certainly see cases, even in overload handling, where the current > server may want to explicitly send the client somewhere else, > effectively redirecting to a different server. This could be either to > an explicit server (or list of them), or just "go try somewhere else, > you figure it out". Also handy for maintenance operations and for load > sharing, possibly others. Lack of an explicit way to send clients > elsewhere for service seems like a weakness overall. I can see that it might be useful in some scenarios to provide these kind of hints to the client. But often a client is able to find backup servers even without such hints, e.g., through DNS. The client might also know of other server the overloaded server wasn't aware of. With a redirection list, a server would need to know all its peers that might possibly jump in if it is overloaded. I think that being specific in a response about what went wrong (e.g. "I'm overloaded") is useful since it will help the client to react properly (e.g. not to resend the request). > Hopefully, the > above (or something along those lines) could help both dis-ambiguate, > and help by acting as a redirection for those cases needing it. > Minimally, it would at least make it easier to figure out (in the > implementation) what the client is being told to do, and would make > troubleshooting a whole lot easier. > > I do understand the desire to minimize changes. But it is also > important to get the right behaviour, and not create situations open to > too much interpretation. Yes, there would be lots of backwards > compatibility issues, but any change in this stuff will have loads > anyway. > I agree. However, as mentioned, this draft is not intending to propose a SIP extension for overload control. > Just throwing some ideas out there to see if the flame throwers come > out. (Donning my flame-proof suit now ..... ;-) > This kind of input is highly appreciated! :) Thanks, Volker _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 22 23:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqhk8-0007jp-Sv; Tue, 22 May 2007 23:42:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqhk7-0007jj-B4 for sip-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 23:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqhk7-0007jb-1P for sip@ietf.org; Tue, 22 May 2007 23:42:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqhk5-0000Cw-Pd for sip@ietf.org; Tue, 22 May 2007 23:42:31 -0400 Received: from [192.168.1.3] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4N2o3VF025505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 May 2007 21:50:04 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Tue, 22 May 2007 22:42:26 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Sip] Updating contact info for Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I seem to have come detached from Cisco, so if you happen to have my old Cisco email address on file, please delete it. It doesn't route to me any more. My softarmor.com address (as used for this message) should continue to work for all IETF traffic. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 04:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqm8a-0005yH-Oj; Wed, 23 May 2007 04:24:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqm8Z-0005xr-Fm for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 04:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqm8Y-0005xc-OM for sip@ietf.org; Wed, 23 May 2007 04:24:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqm8Y-00013X-93 for sip@ietf.org; Wed, 23 May 2007 04:24:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C2D3E21466; Wed, 23 May 2007 10:24:01 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-cf-4653fa2115d6 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AAD17213A8; Wed, 23 May 2007 10:24:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:24:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:23:59 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E2FD62467; Wed, 23 May 2007 11:23:59 +0300 (EEST) Message-ID: <4653FA1F.7050008@ericsson.com> Date: Wed, 23 May 2007 11:23:59 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2007 08:24:00.0101 (UTC) FILETIME=[B6D9B950:01C79D13] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: sip@ietf.org, Paul Kyzivat , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have taken a stab at writing a quick draft about both issues (I agree it makes sense to tackle them in a single document). Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-00.txt I have marked a few open issues so that we can continue discussions around those on the list (this is, of course, just an initial draft). Cheers, Gonzalo Francois Audet wrote: > My preference is one document. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, May 16, 2007 05:18 >> To: Gonzalo Camarillo >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan Wing; >> Christer Holmberg (JO/LMF) >> Subject: Re: [Sip] Support for Multipart/MIME >> >> Hi Gonzalo, >> >> I guess the question is whether we want to write a document >> specifically focused on Content-Disposition, or if we want to >> combine work on that with work on specifying use of multipart. >> >> They aren't the same thing, but content-disposition becomes >> more significant when there are multiple body parts, so there >> is some justification for combining the work. >> >> Paul >> >> Gonzalo Camarillo wrote: >>> Hi, >>> >>> yes, Paul and I talked about writing a draft to clarify a >> few issues >>> that relate to content dispositions in SIP a while ago. We >> were quite >>> busy at that point and did not have time to write it, but >> maybe it is >>> time to do it now. >>> >>> Cheers, >>> >>> Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 10:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqrvZ-0000jM-Vg; Wed, 23 May 2007 10:35:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqrvY-0000jD-BB for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 10:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqrvY-0000j5-1V for sip@ietf.org; Wed, 23 May 2007 10:35:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqrvW-00045L-H3 for sip@ietf.org; Wed, 23 May 2007 10:35:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2007 10:34:58 -0400 X-IronPort-AV: i="4.14,570,1170651600"; d="scan'208"; a="121836356:sNHT61334968" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4NEYwB3004083; Wed, 23 May 2007 10:34:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4NEYjBi028096; Wed, 23 May 2007 14:34:58 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.1830); Wed, 23 May 2007 10:34:40 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:34:40 -0400 Message-ID: <46545100.5040707@cisco.com> Date: Wed, 23 May 2007 10:34:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> In-Reply-To: <4653FA1F.7050008@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2007 14:34:40.0423 (UTC) FILETIME=[7F1D8B70:01C79D47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8158; t=1179930898; x=1180794898; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=nHPIn0IIc158jNGJ1mbCmI9jQIk8YyR803sLkrenb+g=; b=kd6BXU5xyHdK+EG12TQ67WacFdT6Tgz4OXNIXBNHocsnDPv3JolYlVjgHaYpD2pT0jYV/J1h buXpC7h5/S34Tb+focvgfZedfxtqPBFnffDI0LmbO5FdOkgidKt+NLdE; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, Thank you for doing this. It is a great start. I largely agree with what you have written. One specific comment about the draft: - Open issue in section 3: perhaps a new Reason code, to be used with a 415 response would be adequate. I think there are a number of loose ends, some mentioned, some not. In many cases, while I have an opinion what the right answer might be I think it needs discussion. Here is what I came up with: - How to determine what processing a body part should receive In many cases the processing of a body part is determined by: the content disposition, the content type, and perhaps the context within which the message is received. For instance, this is true for type sdp with disposition session in an INVITE; for type text/plain with disposition render in a MESSAGE; and for type kpml with disposition ??? in a SUBSCRIBE. In these cases there is no overt *reference* to the body part. In other cases the processing is determined by the context of a reference to the body part via a cid: url that references the Content-ID of the body part. You mentioned this as well. The case I am concerned with is when there is ambiguity between these. For instance 3261 defines Content-Dispositions "alert" and "icon". While these aren't described very well, it appears that if a body part is present with disposition "alert" then it should be used for alerting based on its presence, without any overt reference. But there is also an Alert-Info header, which *could* contain a cid: url. If there was an Alert-Info header with a cid: url that referenced a body part, must that body part be of disposition "alert"? Its my feeling that the definition of each disposition should specify how use decisions should be made for body parts having this disposition. There should be one or more dispositions that state that their use is to be determined by how they are referenced. And headers that might reference body parts should define the acceptable dispositions for the body parts that are referenced. If a message contains a body part with type and disposition that defines how it is processed without need of a reference, and there *also* is a reference to it, then it should be processed both ways. (This however should happen rarely or never.) - What Content-Disposition type should multipart bodies have? When you have a multipart body, it has a disposition, and each of its contained body parts also has a disposition. I have never seen any specification of what disposition the multipart itself should have. None of the examples I have seen have had a Content-Disposition header in the multipart. According to the sip defaulting rules, a multipart body without a C-D header has disposition "render", which seems a bit weird. In the case of multipart/alternative, I think the disposition type of all the contained body parts should be identical. I think it would also make sense for the multipart/alternative itself to contain the same disposition. That would simplify processing, because the whole thing could be ignored if the disposition has a type that will be ignored. In the case of multipart/mixed, the disposition types of the contained body parts will typically vary. The type of the mixed body simply needs to be something that causes it to be processed. Using the default of "render" seems weird to me. It would make sense to me to have some special C-D type for this purpose. Potentially it could be defined as the default C-D for multipart/mixed in the same way that "session" is the default for type application/sdp. - Must the recipient of a message process all multipart bodies and their contents? Recursively? Note that a multipart body can contain other multipart body parts, thus potentially forming a tree of body parts of arbitrary shape and depth. So, the developer of a UA will want to know: do I have to parse all of that? I think the answer is: like anything else, you make this decision based on the disposition type and handling. (If you understand multipart/mixed (and you should) then you also understand that multipart/X where you don't know X should be processed the same as multipart/mixed.) If handling is optional and the disposition type and content type are known to you, then you must parse it. Each contained body part is then processed based on its own disposition. If the handling is optional and the disposition type or content type are not known to you then you can ignore it. (This puts a premium on having an agreed to disposition type that is typically used for multipart/mixed and which everyone that supports multipart is expected to support.) - What "handling" value should be used for multipart bodies and the contained body parts? If a body part is referenced by a cid: url in a header (or in another body part I suppose), then the handling of the body part should be required. Contained, non-multipart body parts that aren't referenced by cid: can have handling required or optional as appropriate for their use. A multipart body should have handling of required if any of the parts it contains are required. Otherwise it may have optional handling. Multipart/alternative is tricky. Only one alternative is to be used, and it is assumed that some alternatives may not be understood. So it seems that all except the first contained body part should have optional handling. The first may be required or optional depending on whether its ok to handle none. And the handling of the multipart/alternative container is as above. - What about "gratuitous" nesting of multiparts? It seems that it is technically valid to wrap a body part, such as an SDP offer, in one or many levels of multipart wrappers. A recipient who receives such a thing, and processes it according to what Gonzalo has specified and what I have suggested above, should be able to deal with this. But its not a good thing. So I think we ought to at least state that the sender of a request SHOULD NOT use a multipart wrapper when there is only one part, and SHOULD NOT nest one multipart/mixed within another unless there is a *reference* to the nested one. (Instead of nesting, include all the parts in the outer multipart.) And a sender SHOULD NOT nest one multipart/alternative within another. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > > I have taken a stab at writing a quick draft about both issues (I agree > it makes sense to tackle them in a single document). Until it appears in > the archives, you can fetch it from: > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-00.txt > > > I have marked a few open issues so that we can continue discussions > around those on the list (this is, of course, just an initial draft). > > Cheers, > > Gonzalo > > > Francois Audet wrote: >> My preference is one document. >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, May >>> 16, 2007 05:18 >>> To: Gonzalo Camarillo >>> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan Wing; Christer >>> Holmberg (JO/LMF) >>> Subject: Re: [Sip] Support for Multipart/MIME >>> >>> Hi Gonzalo, >>> >>> I guess the question is whether we want to write a document >>> specifically focused on Content-Disposition, or if we want to combine >>> work on that with work on specifying use of multipart. >>> >>> They aren't the same thing, but content-disposition becomes more >>> significant when there are multiple body parts, so there is some >>> justification for combining the work. >>> >>> Paul >>> >>> Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>> yes, Paul and I talked about writing a draft to clarify a >>> few issues >>>> that relate to content dispositions in SIP a while ago. We >>> were quite >>>> busy at that point and did not have time to write it, but >>> maybe it is >>>> time to do it now. >>>> >>>> Cheers, >>>> >>>> Gonzalo > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 11:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqslX-0004vg-Js; Wed, 23 May 2007 11:28:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqslW-0004va-Eb for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 11:28:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqslW-0004vS-4x for sip@ietf.org; Wed, 23 May 2007 11:28:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqslU-0003PZ-Qr for sip@ietf.org; Wed, 23 May 2007 11:28:42 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 23 May 2007 08:28:40 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="2155185:sNHT20678748" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4NFSerq006124; Wed, 23 May 2007 08:28:40 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4NFSQVT015161; Wed, 23 May 2007 15:28:39 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.1830); Wed, 23 May 2007 11:28:35 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 11:28:34 -0400 Message-ID: <46545DA4.7070108@cisco.com> Date: Wed, 23 May 2007 11:28:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> In-Reply-To: <46545100.5040707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2007 15:28:34.0812 (UTC) FILETIME=[06F623C0:01C79D4F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1669; t=1179934120; x=1180798120; c=relaxed/simple; s=sjdkim7002; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=nx5y+TvBKJmxgLF3XdQxFh7Zds1Bf55UEw1pcwML72Y=; b=CZcbX7gg3AsMbvPHyQTpmYh62lj48adOawAvWUg8dSk9xnWIdHCS11jmsipgFXegIwHI/y7p QEaLF80/zcbtFBFlpm4pgw4mBKhdXRjwdUCH64kOw6LX3xZKJ337G/q5; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, Francois Audet , Gonzalo Camarillo , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Revising one point: Paul Kyzivat wrote: > - What "handling" value should be used for multipart bodies and the > contained body parts? > > If a body part is referenced by a cid: url in a header (or in another > body part I suppose), then the handling of the body part should be > required. On reflection, this is tricky. If the header containing the reference is optional (as most are), then recipients that don't understand the header will have no need for the referenced part. If it were required and they don't support the type, then they would fail the request. This is bad. So if processing of the header is optional, then the referenced body part should have optional handling. But then there could be a problem if the recipient does understand and process the header, but doesn't understand the body part, and so because it is optional doesn't process it. In that case, the cid reference will be unsatisfied. This could also result in an inappropriate error. I think the solution here is that if a header contains a cid url, and if that url cannot be resolved to a body part that is supported, then the UA should treat it the same as if the header itself was not understood - typically ignoring it unless there is a Require in effect that demands failing the request. An alternative is to require that Content-ID be remembered even for parts that are not understood, so that references can be resolved even if they can't be processed. This would allow more precise errors to be generated. This wouldn't be so hard at an outer level, but it might be troublesome in conjunction with nesting. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 14:18:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvQ1-0001Tz-55; Wed, 23 May 2007 14:18:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqvPz-0001Tu-I8 for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 14:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvPz-0001Sb-7z for sip@ietf.org; Wed, 23 May 2007 14:18:39 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqvPx-0000W6-S0 for sip@ietf.org; Wed, 23 May 2007 14:18:39 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4NIHYx17494; Wed, 23 May 2007 18:17:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 13:17:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> In-Reply-To: <4653FA1F.7050008@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2sw References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> From: "Francois Audet" To: "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: sip@ietf.org, Paul Kyzivat , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is great Gonzallo. Thanks for doing this. Here are some comments: - In section 4, another example that I think you should list for=20 Multipart/Mixed is RFC 3204 which actually has examples of=20 INVITEs with Multipart/Mixed (one for SDP, the other for=20 QSIG/ISUP tunnelling). That spec also illustrates the content- disposition mechanism (i.e., "optional" for QSIG/ISUP). - I like your text on Multipart/Alternative. I'd like to include the=20 following snippet of text from draft-jennings-sipping-multipart-02.txt in there: It is critical that multipart/alternative offers follow the semantics of multipart/alternative, notably the following text from RFC2046 [2]: "THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a "multipart/alternative" entity represents the same data, but the mappings between the two are not necessarily without information loss. For example, information is lost when translating ODA to PostScript or plain text. It is recommended that each part should have a different Content-ID value in the case where the information content of the two parts is not identical." I'd also like to see an example of Multipart/Alternative for the MESSAGE message (with text/plain and text/html for example). - I believe that the following text in section 4 is not strong enough: If a UAS does not support multipart bodies and receives one, the UAS SHOULD return a 415 (Unsupported Media Type) response. Instead, it should read as follows: If a UAS does not support multipart bodies and receives one, the UAS MUST return a 415 (Unsupported Media Type) response, and it MUST=20 return a list of acceptable formats as specificed in [RFC3261]/21.4.13. I believe this is in line with RFC 3261/8.2.3. I will point out that=20 we have found in the field that if a UAS does NOT send a 415 and just "ignores" the Multipart body altogether, what happens is that the receiver of the INVITE interprets the INVITE as having NO initial Offer, and sends an an Offer of it's own in the 200/18X. This is interpreted by the sender of the INVITE as an Answer, resulting in all hell breaking loose. =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Wednesday, May 23, 2007 01:24 > To: Audet, Francois (SC100:3055) > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer Holmberg (JO/LMF) > Subject: Re: [Sip] Support for Multipart/MIME >=20 > Hi, >=20 > I have taken a stab at writing a quick draft about both=20 > issues (I agree it makes sense to tackle them in a single=20 > document). Until it appears in the archives, you can fetch it from: >=20 > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > andling-00.txt >=20 > I have marked a few open issues so that we can continue=20 > discussions around those on the list (this is, of course,=20 > just an initial draft). >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > Francois Audet wrote: > > My preference is one document.=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, May 16, 2007 05:18 > >> To: Gonzalo Camarillo > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan Wing; Christer=20 > >> Holmberg (JO/LMF) > >> Subject: Re: [Sip] Support for Multipart/MIME > >> > >> Hi Gonzalo, > >> > >> I guess the question is whether we want to write a document=20 > >> specifically focused on Content-Disposition, or if we want=20 > to combine=20 > >> work on that with work on specifying use of multipart. > >> > >> They aren't the same thing, but content-disposition becomes more=20 > >> significant when there are multiple body parts, so there is some=20 > >> justification for combining the work. > >> > >> Paul > >> > >> Gonzalo Camarillo wrote: > >>> Hi, > >>> > >>> yes, Paul and I talked about writing a draft to clarify a > >> few issues > >>> that relate to content dispositions in SIP a while ago. We > >> were quite > >>> busy at that point and did not have time to write it, but > >> maybe it is > >>> time to do it now. > >>> > >>> Cheers, > >>> > >>> Gonzalo >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 14:39:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvkB-0005XR-O0; Wed, 23 May 2007 14:39:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqvkA-0005OV-8Y for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 14:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqvk9-0005O8-V7 for sip@ietf.org; Wed, 23 May 2007 14:39:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqvk8-0004c7-JK for sip@ietf.org; Wed, 23 May 2007 14:39:29 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 11:39:27 -0700 X-IronPort-AV: i="4.14,571,1170662400"; d="scan'208"; a="156694780:sNHT48736890" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4NIdRcm015073; Wed, 23 May 2007 11:39:27 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4NIdOVB018782; Wed, 23 May 2007 18:39:27 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.1830); Wed, 23 May 2007 14:39:20 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 14:39:19 -0400 Message-ID: <46548A53.8070005@cisco.com> Date: Wed, 23 May 2007 14:39:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2007 18:39:19.0893 (UTC) FILETIME=[ACC2E850:01C79D69] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=527; t=1179945567; x=1180809567; c=relaxed/simple; s=sjdkim7002; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=fgkJPaV6Wyh1s4MwNoJS+2Hjlr3BPmGfjePXNPEsT1E=; b=F8VDZuVSj9vpCeN33otXwJnaKSVySog/9bmdiJBQNN8rCQmQj/Uu0Wnj/peYlwUW9fvTswbP 1uf1CmaOFIefytXNnF3DCH0pe7gTcz2GFHU+qY6xdhkm7Yx1tawYyuhT; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sip@ietf.org, Gonzalo Camarillo , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > I believe this is in line with RFC 3261/8.2.3. I will point out that > we have found in the field that if a UAS does NOT send a 415 and just > "ignores" the Multipart body altogether, what happens is that the > receiver of the INVITE interprets the INVITE as having NO initial > Offer, and sends an an Offer of it's own in the 200/18X. This is > interpreted by the sender of the INVITE as an Answer, resulting in > all hell breaking loose. This is great! I love it. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 14:48:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqvsi-0003jo-OL; Wed, 23 May 2007 14:48:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqvsg-0003jj-L9 for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 14:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqvsg-0003jZ-7o for sip@ietf.org; Wed, 23 May 2007 14:48:18 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqvsf-0006YD-Hr for sip@ietf.org; Wed, 23 May 2007 14:48:18 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 3D59F2003A; Wed, 23 May 2007 14:48:17 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00333-05; Wed, 23 May 2007 14:48:15 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 6955C20023; Wed, 23 May 2007 14:48:15 -0400 (EDT) In-Reply-To: <46539ADD.6080900@bell-labs.com> To: Volker Hilt Subject: Re: [Sip] Re: Ambiguity, redirection and Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 23 May 2007 14:48:11 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/23/2007 02:48:13 PM, Serialize complete at 05/23/2007 02:48:13 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011250559==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============0011250559== Content-Type: multipart/alternative; boundary="=_alternative 00674902852572E4_=" This is a multipart message in MIME format. --=_alternative 00674902852572E4_= Content-Type: text/plain; charset="US-ASCII" Hi, Thanks for comments back. See [PB] inline below. I've snipped a bunch to keep the volume to a dull roar. >> o 500 would become overloaded to mean either "something bad (but >> unspecified) happened" or "go somewhere else (maybe try again later)", >> but it seems impossible to determine which case it is. The name of >> this code implies only the former. >> > The changes proposed in the draft should not affect the 500 response > code. In which respect would there be a change to 500? [PB] The change, as I see it, is that 503 would no longer be used to send a client elsewhere, or cause the client to think it should go, in fact would make the client think it should NOT go. So, 500 would need to take on that meaning. [PB] The bits that triggered me thinking this way are: ISSUE 3, sec 4, "... Should all non-overload failures be changed to 500 (Server Internal Error)? It would, e.g., enable a proxy [or client] to try alternate servers for all non-overload failure cases." and sec 6.1 "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD NOT attempt to forward the request to an alternate server. ..." >> o 503 changes its meaning to "I'm overloaded, back off (optionally don't >> try again for some time)". But this is not the name of this response >> -- it is Service Unavailable. The trouble is, there are many reasons >> why service may not be available, overload being just one. (Yes, I >> know this issue is raised as OPEN ISSUE 3 in the draft itself.) >> > 503 means that the "server is temporarily unable to process the request > due to a temporary overloading or maintenance of the server." [PB] Current draft text is "... server is temporarily unable to process the request due to a temporary overloading ..." > It seems that 503 is working reasonably well for maintenance but not for > overload. So the question is if we can change the overload behavior > without breaking the maintenance part. I believe that the proposed > changes 1. - 4. would provide such a change if 503 is used as today for > maintenance (with Retry-After) and without Retry-After as described for > proxies under overload. [PB] But, for maintenance and similar cases, you may actually want the client to go elsewhere for service. Text in the draft would prohibit this from happening, see sec 6.1 "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD NOT attempt to forward the request to an alternate server. ..." Hence the proposal to make the desired redirect-like behaviour explicit somehow. >> Proposals: >> >> 1. Can a new 5xx response code be defined specifically to handle >> overload scenarios, instead of overloading 503 / 500? This would have >> the explicit semantic of "I'm overloaded, back off (optionally for some >> time)". It could also have additional info on how the client should >> handle it (see next). 503 would keep its original meaning (go somewhere >> else), and 500 would keep its meaning (something bad happened). >> > I think this would be closer to a new SIP extension for overload > control, which I think is useful, than to a correction of RFC3261, which > is the scope of this draft. [PB] Could be, or maybe not -- not really my call. Just a thought. But if such a thing were to be done in overload work, it would effectively be undoing this draft, would it not? >> 2. Add a new header, to explicitly list one or more servers to go get >> service from, usable (at least) in 503 and the new 5xx, maybe 500 also. >> With this, 503 could have the additional semantic of "go somewhere >> else, and here's where" (optionally with a time to retry here). New >> 5xx could have the additional semantic of "I'm overloaded, go here >> instead" (optionally with a time to retry here). >> >> I can certainly see cases, even in overload handling, where the current >> server may want to explicitly send the client somewhere else, >> effectively redirecting to a different server. This could be either to >> an explicit server (or list of them), or just "go try somewhere else, >> you figure it out". [snip] >> > I can see that it might be useful in some scenarios to provide these > kind of hints to the client. But often a client is able to find backup > servers even without such hints, e.g., through DNS. The client might > also know of other server the overloaded server wasn't aware of. With a > redirection list, a server would need to know all its peers that might > possibly jump in if it is overloaded. [PB] Certainly agree, it would be advantageous to be able to inform the client "go find somewhere else", but also think in other circumstances (notably clustered servers) it would be advantageous to be explicit "go here". I expect if we were to go for a new header (or similar), we could probably find some way to accommodate both meanings. > I think that being specific in a response about what went wrong (e.g. > "I'm overloaded") is useful since it will help the client to react > properly (e.g. not to resend the request). [PB] Certainly agree here too. In fact, if we could find some way to provide just that hint in 503 (reason = overload vs maintenance, vs load sharing ... ), then we could distinguish the cases. This would eliminate, or at least make less strong, the proposal for a new 5xx. Still think the redirect-like "go here" header would be good though. [snip] >> I do understand the desire to minimize changes. But it is also >> important to get the right behaviour, and not create situations open to >> too much interpretation. [snip] >> > I agree. However, as mentioned, this draft is not intending to propose a > SIP extension for overload control. [PB] One problem being, the changes in this draft do focus on overload, yet the more general overload work does not focus on any of the other scenarios. -- Peter --=_alternative 00674902852572E4_= Content-Type: text/html; charset="US-ASCII"
Hi,
Thanks for comments back.  See [PB] inline below.   I've snipped a bunch to keep the volume to a dull roar.  

>> o 500 would become overloaded to mean either "something bad (but
>> unspecified) happened" or "go somewhere else (maybe try again later)",
>> but it seems impossible to determine which case it is.   The name of
>> this code implies only the former.  
>>
> The changes proposed in the draft should not affect the 500 response
> code. In which respect would there be a change to 500?
[PB] The change, as I see it, is that 503 would no longer be used to
send a client elsewhere, or cause the client to think it should go,
in fact would make the client think it should NOT go.  So, 500 would
need to take on that meaning.  

[PB] The bits that triggered me thinking this way are:
ISSUE 3, sec 4,
  "... Should all non-overload failures be changed to 500 (Server
   Internal Error)?  It would, e.g., enable a proxy [or client] to
   try alternate servers for all non-overload failure cases."
and sec 6.1
  "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   NOT attempt to forward the request to an alternate server. ..."


>> o 503 changes its meaning to "I'm overloaded, back off (optionally don't
>> try again for some time)".   But this is not the name of this response
>> -- it is Service Unavailable.  The trouble is, there are many reasons
>> why service may not be available, overload being just one.   (Yes, I
>> know this issue is raised as OPEN ISSUE 3  in the draft itself.)  
>>
> 503 means that the "server is temporarily unable to process the request
> due to a temporary overloading or maintenance of the server."
[PB] Current draft text is
  "... server is temporarily unable to process the request due to a
   temporary overloading ..."

> It seems that 503 is working reasonably well for maintenance but not for
> overload. So the question is if we can change the overload behavior
> without breaking the maintenance part. I believe that the proposed
> changes 1. - 4. would provide such a change if 503 is used as today for
> maintenance (with Retry-After) and without Retry-After as described for
> proxies under overload.
[PB] But, for maintenance and similar cases, you may actually want the
client to go elsewhere for service.  Text in the draft would prohibit
this from happening, see sec 6.1
  "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
   NOT attempt to forward the request to an alternate server. ..."
Hence the proposal to make the desired redirect-like behaviour explicit
somehow.  


>> Proposals:
>>
>> 1.  Can a new 5xx response code be defined specifically to handle
>> overload scenarios, instead of overloading 503 / 500?  This would have
>> the explicit semantic of "I'm overloaded, back off (optionally for some
>> time)".   It could also have additional info on how the client should
>> handle it (see next).  503 would keep its original meaning (go somewhere
>> else), and 500 would keep its meaning (something bad happened).  
>>
> I think this would be closer to a new SIP extension for overload
> control, which I think is useful, than to a correction of RFC3261, which
> is the scope of this draft.

[PB] Could be, or maybe not -- not really my call.  Just a thought.  But
if such a thing were to be done in overload work, it would effectively
be undoing this draft, would it not?

>> 2.  Add a new header, to explicitly list one or more servers to go get
>> service from, usable (at least) in 503 and the new 5xx, maybe 500 also.
>> With this, 503 could have the additional semantic of "go somewhere
>> else, and here's where" (optionally with a time to retry here).   New
>> 5xx could have the additional semantic of "I'm overloaded, go here
>> instead" (optionally with a time to retry here).  
>>
>> I can certainly see cases, even in overload handling, where the current
>> server may want to explicitly send the client somewhere else,
>> effectively redirecting to a different server. This could be either to
>> an explicit server (or list of them), or just "go try somewhere else,
>> you figure it out".   [snip]  
>>
> I can see that it might be useful in some scenarios to provide these
> kind of hints to the client. But often a client is able to find backup
> servers even without such hints, e.g., through DNS. The client might
> also know of other server the overloaded server wasn't aware of. With a
> redirection list, a server would need to know all its peers that might
> possibly jump in if it is overloaded.

[PB] Certainly agree, it would be advantageous to be able to inform the
client "go find somewhere else", but also think in other circumstances
(notably clustered servers) it would be advantageous to be explicit
"go here".  I expect if we were to go for a new header (or similar),
we could probably find some way to accommodate both meanings.  

> I think that being specific in a response about what went wrong (e.g.
> "I'm overloaded") is useful since it will help the client to react
> properly (e.g. not to resend the request).

[PB] Certainly agree here too.  In fact, if we could find some way to
provide just that hint in 503 (reason = overload vs maintenance, vs
load sharing ... ), then we could distinguish the cases.  This would
eliminate, or at least make less strong, the proposal for a new 5xx.  
Still think the redirect-like "go here" header would be good though.  
[snip]
>> I do understand the desire to minimize changes.  But it is also
>> important to get the right behaviour, and not create situations open to
>> too much interpretation.  [snip]
>>
> I agree. However, as mentioned, this draft is not intending to propose a
> SIP extension for overload control.
[PB] One problem being, the changes in this draft do focus on overload,
yet the more general overload work does not focus on any of the other
scenarios.  

-- Peter


--=_alternative 00674902852572E4_=-- --===============0011250559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0011250559==-- From sip-bounces@ietf.org Wed May 23 14:52:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvxC-0007Sj-42; Wed, 23 May 2007 14:52:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqvxA-0007SV-1A for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 14:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqvx9-0007SH-1u for sip@ietf.org; Wed, 23 May 2007 14:52:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqvx7-0008Kf-DR for sip@ietf.org; Wed, 23 May 2007 14:52:55 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 11:52:53 -0700 X-IronPort-AV: i="4.14,571,1170662400"; d="scan'208"; a="156702160:sNHT49549707" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4NIqq9L012053; Wed, 23 May 2007 11:52:52 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4NIqp06013434; Wed, 23 May 2007 18:52:52 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Gonzalo Camarillo'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 11:52:51 -0700 Message-ID: <0aff01c79d6b$911914b0$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/A= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6480; t=1179946372; x=1180810372; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=DrjU9kNoEqTIbsUO1rnKC8WyJmOYqzOp+ErYwdYs8qo=; b=HhzC/egJ8P2ODgVZW5fMW1KMyjZn6wqbDAbCdJ2urQ2+sfHs3eiuR0JE4/1IIxTpuDcnZ86X b4ofLhtDqjkxi3YnVC0fjb04y7Xm6TfIbptNknPqypaB6eIKKwwRhhjy; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: sip@ietf.org, 'Paul Kyzivat' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, May 23, 2007 11:18 AM > To: Gonzalo Camarillo > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME > > This is great Gonzallo. Thanks for doing this. > > Here are some comments: > > - In section 4, another example that I think you should list for > Multipart/Mixed is RFC 3204 which actually has examples of > INVITEs with Multipart/Mixed (one for SDP, the other for > QSIG/ISUP tunnelling). That spec also illustrates the content- > disposition mechanism (i.e., "optional" for QSIG/ISUP). I wasn't aware of that usage in RFC3204. In both section 4.1 and its example, though, I don't think it's using multipart/mixed correctly. Here is its example (section 4.1 is similar): To illustrate the use of the 'application/QSIG' media type, below is an INVITE message which has the originating SDP information and an encapsulated QSIG SETUP message. Note that the two payloads are demarcated by the boundary parameter (specified in RFC 2046 [4]) which in the example has the value "unique- boundary-1". This is part of the specification of MIME multipart and is not related to the 'application/QSIG' media type. INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 Via: SIP/2.0/UDP sc10.nortelnetworks.com From: sip:14085655675@sc10.nortelnetworks.com To: sip:14084955072@sc1.nortelnetworks.com Call-ID: 1231999021712095500999@sc12.nortelnetworks.com CSeq: 1234 INVITE Contact: Content-Length: 358 Content-Type: multipart/mixed; boundary=unique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4 s=SDP seminar c=IN IP4 MG141.nortelnetworks.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/QSIG; version=iso 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 --unique-boundary-1-- Per the semantics of multipart/mixed, both of those bodies are interpreted by the recipient -- wouldn't that cause two calls to be set up? Or does the SDP describe the VoIP leg and the QSIG describes the PSTN leg? If the latter, I do feel multipart/related would have been a better choice. [[As MIME parsers are supposed to interpret unrecognized multipart/* as multipart/mixed, a MIME-compliant parser that currently has the RFC3204-described behavior should work correctly if it received a multipart/related instead of multipart/mixed.]] > - I like your text on Multipart/Alternative. Yes, that section is very well written and captures exactly the problem with multipart/alternative. ... > - I believe that the following text in section 4 is not strong enough: > > If a UAS does not support multipart bodies and receives > one, the UAS > SHOULD return a 415 (Unsupported Media Type) response. > > Instead, it should read as follows: > > If a UAS does not support multipart bodies and receives > one, the UAS > MUST return a 415 (Unsupported Media Type) response, and it MUST > return a list of acceptable formats as specificed in > [RFC3261]/21.4.13. > > I believe this is in line with RFC 3261/8.2.3. I will point > out that > we have found in the field that if a UAS does NOT send a > 415 and just > "ignores" the Multipart body altogether, what happens is that the > receiver of the > INVITE interprets the INVITE as having NO initial Offer, > and sends an > an > Offer of it's own in the 200/18X. This is interpreted by > the sender of > the > INVITE as an Answer, resulting in all hell breaking loose. That's awful. You could detect this situation by requiring the answerer to insert a reference to the Content-ID they're answering; if an ACK comes back without that Content-ID, you'll know you encountered such a defective implementation. -d > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: Wednesday, May 23, 2007 01:24 > > To: Audet, Francois (SC100:3055) > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer Holmberg (JO/LMF) > > Subject: Re: [Sip] Support for Multipart/MIME > > > > Hi, > > > > I have taken a stab at writing a quick draft about both > > issues (I agree it makes sense to tackle them in a single > > document). Until it appears in the archives, you can fetch it from: > > > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > andling-00.txt > > > > I have marked a few open issues so that we can continue > > discussions around those on the list (this is, of course, > > just an initial draft). > > > > Cheers, > > > > Gonzalo > > > > > > Francois Audet wrote: > > > My preference is one document. > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Wednesday, May 16, 2007 05:18 > > >> To: Gonzalo Camarillo > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > Wing; Christer > > >> Holmberg (JO/LMF) > > >> Subject: Re: [Sip] Support for Multipart/MIME > > >> > > >> Hi Gonzalo, > > >> > > >> I guess the question is whether we want to write a document > > >> specifically focused on Content-Disposition, or if we want > > to combine > > >> work on that with work on specifying use of multipart. > > >> > > >> They aren't the same thing, but content-disposition becomes more > > >> significant when there are multiple body parts, so there is some > > >> justification for combining the work. > > >> > > >> Paul > > >> > > >> Gonzalo Camarillo wrote: > > >>> Hi, > > >>> > > >>> yes, Paul and I talked about writing a draft to clarify a > > >> few issues > > >>> that relate to content dispositions in SIP a while ago. We > > >> were quite > > >>> busy at that point and did not have time to write it, but > > >> maybe it is > > >>> time to do it now. > > >>> > > >>> Cheers, > > >>> > > >>> Gonzalo > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 15:22:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqwPz-00007A-Fg; Wed, 23 May 2007 15:22:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqwPx-000075-HH for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 15:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqwPx-00006x-7Y for sip@ietf.org; Wed, 23 May 2007 15:22:41 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqwPv-0003gu-Qc for sip@ietf.org; Wed, 23 May 2007 15:22:41 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4NJMZp14539; Wed, 23 May 2007 19:22:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 14:22:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> In-Reply-To: <0aff01c79d6b$911914b0$c6f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIA== References: <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> <0aff01c79d6b$911914b0$c6f0200a@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan,=20 To answer your question about the Multipart usage for ISUP/QSIG tunnelling. No, it does not set-up two calls. It sets-up ONE call. The SDP is mandatory. The QSIG or ISUP is optional. If supported it provides additional information for the softswitches for legacy PSTN interop or other features. If not it should be safely ignored. So 3204 operates exactly as it should. Works fine. Has been working fine for years (except for implementations that have problems with Multipart MIME, which has forced the use of B2BUA that strip off these MIME bodies.) > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, May 23, 2007 11:18 AM > > To: Gonzalo Camarillo > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer Holmberg (JO/LMF) > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > > This is great Gonzallo. Thanks for doing this. > >=20 > > Here are some comments: > >=20 > > - In section 4, another example that I think you should list for=20 > > Multipart/Mixed is RFC 3204 which actually has examples of=20 > > INVITEs with Multipart/Mixed (one for SDP, the other for=20 > > QSIG/ISUP tunnelling). That spec also illustrates the content- > > disposition mechanism (i.e., "optional" for QSIG/ISUP). >=20 > I wasn't aware of that usage in RFC3204. In both section 4.1=20 > and its example, though, I don't think it's using=20 > multipart/mixed correctly. Here is its example (section 4.1=20 > is similar): >=20 > To illustrate the use of the 'application/QSIG' media=20 > type, below is > an INVITE message which has the originating SDP information and an > encapsulated QSIG SETUP message. >=20 > Note that the two payloads are demarcated by the boundary parameter > (specified in RFC 2046 [4]) which in the example has the value > "unique- boundary-1". This is part of the specification of MIME > multipart and is not related to the 'application/QSIG' media type. >=20 > INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 > Via: SIP/2.0/UDP sc10.nortelnetworks.com > From: sip:14085655675@sc10.nortelnetworks.com > To: sip:14084955072@sc1.nortelnetworks.com > Call-ID: 1231999021712095500999@sc12.nortelnetworks.com > CSeq: 1234 INVITE > Contact: > Content-Length: 358 > Content-Type: multipart/mixed; boundary=3Dunique-boundary-1 > MIME-Version: 1.0 >=20 > --unique-boundary-1 > Content-Type: application/SDP; charset=3DISO-10646 >=20 > v=3D0 > o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 > s=3DSDP seminar > c=3DIN IP4 MG141.nortelnetworks.com > t=3D 2873397496 2873404696 > m=3Daudio 9092 RTP/AVP 0 3 4 >=20 > --unique-boundary-1 > Content-type:application/QSIG; version=3Diso >=20 > 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 > 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 > --unique-boundary-1-- >=20 > Per the semantics of multipart/mixed, both of those bodies=20 > are interpreted by the recipient -- wouldn't that cause two=20 > calls to be set up? Or does the SDP describe the VoIP leg=20 > and the QSIG describes the PSTN leg? If the latter, I do=20 > feel multipart/related would have been a better choice. =20 >=20 > [[As MIME parsers are supposed to interpret unrecognized=20 > multipart/* as multipart/mixed, a MIME-compliant parser that=20 > currently has the RFC3204-described behavior=20 > should work correctly if it received a=20 > multipart/related instead of multipart/mixed.]] >=20 > > - I like your text on Multipart/Alternative. >=20 > Yes, that section is very well written and captures exactly=20 > the problem with multipart/alternative. >=20 > ... > > - I believe that the following text in section 4 is not=20 > strong enough: > >=20 > > If a UAS does not support multipart bodies and receives one, the=20 > > UAS > > SHOULD return a 415 (Unsupported Media Type) response. > >=20 > > Instead, it should read as follows: > >=20 > > If a UAS does not support multipart bodies and receives one, the=20 > > UAS > > MUST return a 415 (Unsupported Media Type) response, and it MUST=20 > > return a list of acceptable formats as specificed in=20 > > [RFC3261]/21.4.13. > >=20 > > I believe this is in line with RFC 3261/8.2.3. I will=20 > point out that > > we have found in the field that if a UAS does NOT send a > > 415 and just > > "ignores" the Multipart body altogether, what happens is that the=20 > > receiver of the > > INVITE interprets the INVITE as having NO initial Offer,=20 > and sends=20 > > an an > > Offer of it's own in the 200/18X. This is interpreted by=20 > the sender=20 > > of the > > INVITE as an Answer, resulting in all hell breaking loose. >=20 > That's awful. You could detect this situation by requiring=20 > the answerer to insert a reference to the Content-ID they're=20 > answering; if an ACK comes back without that Content-ID,=20 > you'll know you encountered such a defective implementation. >=20 > -d >=20 >=20 > =20 > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > Sent: Wednesday, May 23, 2007 01:24 > > > To: Audet, Francois (SC100:3055) > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer=20 > Holmberg (JO/LMF) > > > Subject: Re: [Sip] Support for Multipart/MIME > > >=20 > > > Hi, > > >=20 > > > I have taken a stab at writing a quick draft about both issues (I=20 > > > agree it makes sense to tackle them in a single=20 > document). Until it=20 > > > appears in the archives, you can fetch it from: > > >=20 > > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > > andling-00.txt > > >=20 > > > I have marked a few open issues so that we can continue=20 > discussions=20 > > > around those on the list (this is, of course, just an initial=20 > > > draft). > > >=20 > > > Cheers, > > >=20 > > > Gonzalo > > >=20 > > >=20 > > > Francois Audet wrote: > > > > My preference is one document.=20 > > > >=20 > > > >> -----Original Message----- > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > >> Sent: Wednesday, May 16, 2007 05:18 > > > >> To: Gonzalo Camarillo > > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > > Wing; Christer > > > >> Holmberg (JO/LMF) > > > >> Subject: Re: [Sip] Support for Multipart/MIME > > > >> > > > >> Hi Gonzalo, > > > >> > > > >> I guess the question is whether we want to write a document=20 > > > >> specifically focused on Content-Disposition, or if we want > > > to combine > > > >> work on that with work on specifying use of multipart. > > > >> > > > >> They aren't the same thing, but content-disposition=20 > becomes more=20 > > > >> significant when there are multiple body parts, so=20 > there is some=20 > > > >> justification for combining the work. > > > >> > > > >> Paul > > > >> > > > >> Gonzalo Camarillo wrote: > > > >>> Hi, > > > >>> > > > >>> yes, Paul and I talked about writing a draft to clarify a > > > >> few issues > > > >>> that relate to content dispositions in SIP a while ago. We > > > >> were quite > > > >>> busy at that point and did not have time to write it, but > > > >> maybe it is > > > >>> time to do it now. > > > >>> > > > >>> Cheers, > > > >>> > > > >>> Gonzalo > > >=20 > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 16:14:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxDh-0004CV-FZ; Wed, 23 May 2007 16:14:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqxDe-0004C6-So for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:14:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxDe-0004By-In for sip@ietf.org; Wed, 23 May 2007 16:14:02 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqxDd-0008NJ-Ad for sip@ietf.org; Wed, 23 May 2007 16:14:02 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4NKDvB22422; Wed, 23 May 2007 20:13:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 15:13:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com> In-Reply-To: <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9A= References: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Wednesday, May 23, 2007 12:53 > To: Audet, Francois (SC100:3055); 'Gonzalo Camarillo' > Cc: 'Paul Kyzivat'; sip@ietf.org; 'Christer Holmberg (JO/LMF)' > Subject: RE: [Sip] Support for Multipart/MIME >=20 > Yes, I expect RFC3204's syntax and semantics work fine=20 > between two implementations that implement RFC3204. >=20 > My question if it the choice of multipart/mixed in RFC3204=20 > was correct or if multipart/related would have been more=20 > appropriate for RFC3204. I have this question because the=20 > QSIG (and ISUP) are directly related to the SDP, and the=20 > QSIG/ISUP data provides additional information about that=20 > outgoing PSTN call leg that assists it in being set up. >=20 > My underlying question is what guidance we want to provide=20 > for Gonzalo's document. If RFC3204's use of multipart/mixed=20 > is what we want to do in SIP when there are bodyparts that=20 > have a relationship with each other, then Gonzalo's document=20 > will need to discourage use of multipart/related. For Multipart/Related (as described in RFC 2387), I don't think it's applicable to 3204 as I think they would be=20 independent. My reading of 2387 is that they depend on each other. This is not the case for 3204. They are not dependent. (And really, it's way too late to change 3204). But, if I interpret your question in a broader sense, I guess, the question is "Do we need to say anything about multipart/related?". I would extend it to parallel and digest... I guess we should. But I'm not sure what should be said.=20 If we don't have a use case for them, I'd rather we don't encourage people to use it and create interop problems... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 16:24:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxNR-0007P9-CK; Wed, 23 May 2007 16:24:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqxNP-0007P3-7F for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxNO-0007Os-Tk for sip@ietf.org; Wed, 23 May 2007 16:24:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqwtP-0006oI-Nw for sip@ietf.org; Wed, 23 May 2007 15:53:09 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 12:52:33 -0700 X-IronPort-AV: i="4.14,571,1170662400"; d="scan'208"; a="156731299:sNHT53367687" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4NJqXA6007014; Wed, 23 May 2007 12:52:33 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4NJqWV1020494; Wed, 23 May 2007 19:52:32 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Gonzalo Camarillo'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 12:52:31 -0700 Message-ID: <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8962; t=1179949953; x=1180813953; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=LVk9H31eJzd9P7W/W5KW7zvcyu8E22jDQLATOaDMi3w=; b=hZlrf2szOyHsTAcSI3A9u9h/eMFHV7T4DjBAhvwaVFtw7G+YyUDD2Cy9NxRMbPb06Zcoptjc 7N+S4+cZP2kLRuP36qrgv7qNWY0ZtYkT9IfqsAf6geS/tZYSQ5yrKw2x; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: sip@ietf.org, 'Paul Kyzivat' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yes, I expect RFC3204's syntax and semantics work fine between two implementations that implement RFC3204. My question if it the choice of multipart/mixed in RFC3204 was correct or if multipart/related would have been more appropriate for RFC3204. I have this question because the QSIG (and ISUP) are directly related to the SDP, and the QSIG/ISUP data provides additional information about that outgoing PSTN call leg that assists it in being set up. My underlying question is what guidance we want to provide for Gonzalo's document. If RFC3204's use of multipart/mixed is what we want to do in SIP when there are bodyparts that have a relationship with each other, then Gonzalo's document will need to discourage use of multipart/related. -d > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, May 23, 2007 12:22 PM > To: Dan Wing; Gonzalo Camarillo > Cc: Paul Kyzivat; sip@ietf.org; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME > > > Hi Dan, > > To answer your question about the Multipart usage for ISUP/QSIG > tunnelling. > > No, it does not set-up two calls. It sets-up ONE call. > > The SDP is mandatory. > > The QSIG or ISUP is optional. If supported it provides additional > information for the softswitches for legacy PSTN interop or other > features. > If not it should be safely ignored. > > So 3204 operates exactly as it should. Works fine. Has been > working fine > for years (except for implementations that have problems with > Multipart > MIME, > which has forced the use of B2BUA that strip off these MIME bodies.) > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Wednesday, May 23, 2007 11:18 AM > > > To: Gonzalo Camarillo > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > Holmberg (JO/LMF) > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > > This is great Gonzallo. Thanks for doing this. > > > > > > Here are some comments: > > > > > > - In section 4, another example that I think you should list for > > > Multipart/Mixed is RFC 3204 which actually has examples of > > > INVITEs with Multipart/Mixed (one for SDP, the other for > > > QSIG/ISUP tunnelling). That spec also illustrates the content- > > > disposition mechanism (i.e., "optional" for QSIG/ISUP). > > > > I wasn't aware of that usage in RFC3204. In both section 4.1 > > and its example, though, I don't think it's using > > multipart/mixed correctly. Here is its example (section 4.1 > > is similar): > > > > To illustrate the use of the 'application/QSIG' media > > type, below is > > an INVITE message which has the originating SDP > information and an > > encapsulated QSIG SETUP message. > > > > Note that the two payloads are demarcated by the > boundary parameter > > (specified in RFC 2046 [4]) which in the example has the value > > "unique- boundary-1". This is part of the specification of MIME > > multipart and is not related to the 'application/QSIG' > media type. > > > > INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 > > Via: SIP/2.0/UDP sc10.nortelnetworks.com > > From: sip:14085655675@sc10.nortelnetworks.com > > To: sip:14084955072@sc1.nortelnetworks.com > > Call-ID: 1231999021712095500999@sc12.nortelnetworks.com > > CSeq: 1234 INVITE > > Contact: > > Content-Length: 358 > > Content-Type: multipart/mixed; boundary=unique-boundary-1 > > MIME-Version: 1.0 > > > > --unique-boundary-1 > > Content-Type: application/SDP; charset=ISO-10646 > > > > v=0 > > o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4 > > s=SDP seminar > > c=IN IP4 MG141.nortelnetworks.com > > t= 2873397496 2873404696 > > m=audio 9092 RTP/AVP 0 3 4 > > > > --unique-boundary-1 > > Content-type:application/QSIG; version=iso > > > > 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 > > 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 > > --unique-boundary-1-- > > > > Per the semantics of multipart/mixed, both of those bodies > > are interpreted by the recipient -- wouldn't that cause two > > calls to be set up? Or does the SDP describe the VoIP leg > > and the QSIG describes the PSTN leg? If the latter, I do > > feel multipart/related would have been a better choice. > > > > [[As MIME parsers are supposed to interpret unrecognized > > multipart/* as multipart/mixed, a MIME-compliant parser that > > currently has the RFC3204-described behavior > > should work correctly if it received a > > multipart/related instead of multipart/mixed.]] > > > > > - I like your text on Multipart/Alternative. > > > > Yes, that section is very well written and captures exactly > > the problem with multipart/alternative. > > > > ... > > > - I believe that the following text in section 4 is not > > strong enough: > > > > > > If a UAS does not support multipart bodies and > receives one, the > > > UAS > > > SHOULD return a 415 (Unsupported Media Type) response. > > > > > > Instead, it should read as follows: > > > > > > If a UAS does not support multipart bodies and > receives one, the > > > UAS > > > MUST return a 415 (Unsupported Media Type) response, > and it MUST > > > return a list of acceptable formats as specificed in > > > [RFC3261]/21.4.13. > > > > > > I believe this is in line with RFC 3261/8.2.3. I will > > point out that > > > we have found in the field that if a UAS does NOT send a > > > 415 and just > > > "ignores" the Multipart body altogether, what happens > is that the > > > receiver of the > > > INVITE interprets the INVITE as having NO initial Offer, > > and sends > > > an an > > > Offer of it's own in the 200/18X. This is interpreted by > > the sender > > > of the > > > INVITE as an Answer, resulting in all hell breaking loose. > > > > That's awful. You could detect this situation by requiring > > the answerer to insert a reference to the Content-ID they're > > answering; if an ACK comes back without that Content-ID, > > you'll know you encountered such a defective implementation. > > > > -d > > > > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > > Sent: Wednesday, May 23, 2007 01:24 > > > > To: Audet, Francois (SC100:3055) > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > Holmberg (JO/LMF) > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > > > Hi, > > > > > > > > I have taken a stab at writing a quick draft about both > issues (I > > > > agree it makes sense to tackle them in a single > > document). Until it > > > > appears in the archives, you can fetch it from: > > > > > > > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > > > andling-00.txt > > > > > > > > I have marked a few open issues so that we can continue > > discussions > > > > around those on the list (this is, of course, just an initial > > > > draft). > > > > > > > > Cheers, > > > > > > > > Gonzalo > > > > > > > > > > > > Francois Audet wrote: > > > > > My preference is one document. > > > > > > > > > >> -----Original Message----- > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > >> Sent: Wednesday, May 16, 2007 05:18 > > > > >> To: Gonzalo Camarillo > > > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > > > Wing; Christer > > > > >> Holmberg (JO/LMF) > > > > >> Subject: Re: [Sip] Support for Multipart/MIME > > > > >> > > > > >> Hi Gonzalo, > > > > >> > > > > >> I guess the question is whether we want to write a document > > > > >> specifically focused on Content-Disposition, or if we want > > > > to combine > > > > >> work on that with work on specifying use of multipart. > > > > >> > > > > >> They aren't the same thing, but content-disposition > > becomes more > > > > >> significant when there are multiple body parts, so > > there is some > > > > >> justification for combining the work. > > > > >> > > > > >> Paul > > > > >> > > > > >> Gonzalo Camarillo wrote: > > > > >>> Hi, > > > > >>> > > > > >>> yes, Paul and I talked about writing a draft to clarify a > > > > >> few issues > > > > >>> that relate to content dispositions in SIP a while ago. We > > > > >> were quite > > > > >>> busy at that point and did not have time to write it, but > > > > >> maybe it is > > > > >>> time to do it now. > > > > >>> > > > > >>> Cheers, > > > > >>> > > > > >>> Gonzalo > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 16:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxO4-0000XY-6e; Wed, 23 May 2007 16:24:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqxO1-0000P8-Fe for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqxO1-0000Ox-5v for sip@ietf.org; Wed, 23 May 2007 16:24:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqxNz-0002S8-T2 for sip@ietf.org; Wed, 23 May 2007 16:24:45 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 13:24:43 -0700 X-IronPort-AV: i="4.14,571,1170662400"; d="scan'208"; a="156743639:sNHT42214149" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4NKOhtv031658; Wed, 23 May 2007 13:24:43 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4NKOg06025608; Wed, 23 May 2007 20:24:42 GMT From: "Dan Wing" To: "'Francois Audet'" , "'Gonzalo Camarillo'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 13:24:42 -0700 Message-ID: <0bb501c79d78$6599e7d0$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com> Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9AAAIzN4A== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1440; t=1179951883; x=1180815883; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=x418epCfEZwxBiuqsa4IcYObzs+f6ykiblnvzgqb5/E=; b=iG+mm5KVOMjkH2iT6+4fZ5w2pDNMGOvz8Ry5eNm49TptyPjWWSoFwHXHRLdqkHOqHljS7cJP 6kT5ziSPyX9b/IPcv/FakH4bz6vFZDqxrBbziu9WrSLJjBZpVDe1LqrI; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org, 'Paul Kyzivat' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > For Multipart/Related (as described in RFC 2387), I > don't think it's applicable to 3204 as I think they would be > independent. My reading of 2387 is that they depend on each > other. > > This is not the case for 3204. They are not dependent. In RFC3204, the QSIG or ISUP parts do not appear to have any meaning without the SDP. Or do they? For example, is it meaningful for me to send an INVITE that has only the QSIG part (and no SDP)? > (And really, it's way too late to change 3204). Even if consensus were to be formed that there was a mistake? Obviously no such consensus has been formed, but I would like to have the discussion. If we do consider it acceptable to change RFC3261's requirements around MIME multipart support, I suggest it is reasonable to analyze what we may have done wrong elsewhere around MIME with SIP. > But, if I interpret your question in a broader sense, I guess, > the question is "Do we need to say anything about > multipart/related?". I would extend it to parallel and digest... And external-body, and all the other parts. Yes, that is my underlying question in light of Gonzalo's document and Cullen's stated desire for the SIP community to document multipart support. > I guess we should. But I'm not sure what should be said. > If we don't have a use case for them, I'd rather we don't encourage > people to use it and create interop problems... -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 16:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqxaq-0005Yy-9v; Wed, 23 May 2007 16:38:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hqxap-0005Ys-1d for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqxao-0005Yk-OF for sip@ietf.org; Wed, 23 May 2007 16:37:58 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqxan-00063r-Fp for sip@ietf.org; Wed, 23 May 2007 16:37:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4NKbru10340; Wed, 23 May 2007 20:37:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 23 May 2007 15:36:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1095509E@zrc2hxm0.corp.nortel.com> In-Reply-To: <0bb501c79d78$6599e7d0$c6f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9AAAIzN4AAAR+nA References: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com> <0bb501c79d78$6599e7d0$c6f0200a@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Gonzalo Camarillo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > In RFC3204, the QSIG or ISUP parts do not appear to have any=20 > meaning without the SDP. Or do they? For example, is it=20 > meaningful for me to send an INVITE that has only the QSIG=20 > part (and no SDP)? Sure: it's just a delayed offer answer.=20 > > (And really, it's way too late to change 3204). >=20 > Even if consensus were to be formed that there was a mistake?=20 > Obviously no such consensus has been formed, but I would=20 > like to have the discussion. I really don't think it's a mistake. > If we do consider it acceptable to change RFC3261's=20 > requirements around MIME multipart support, I suggest it is=20 > reasonable to analyze what we may have done wrong elsewhere=20 > around MIME with SIP. >=20 > > But, if I interpret your question in a broader sense, I guess, the=20 > > question is "Do we need to say anything about=20 > multipart/related?". I=20 > > would extend it to parallel and digest... >=20 > And external-body, and all the other parts. Yes, that is my=20 > underlying question in light of Gonzalo's document and=20 > Cullen's stated desire for the SIP community to document=20 > multipart support. Yeah, I think it would be worthwile to talk about it, but not in the context of 3204. Frankly, what I think we should say is "RECOMMEND don't use unless some IETF RFC defines a use for them". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 23 18:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqznV-0002UA-UE; Wed, 23 May 2007 18:59:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HqznU-0002U4-7f for sip-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 18:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqznT-0002Tu-Ti for sip@ietf.org; Wed, 23 May 2007 18:59:11 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqznT-00048s-Go for sip@ietf.org; Wed, 23 May 2007 18:59:11 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l4NMxAJh018147; Wed, 23 May 2007 17:59:10 -0500 (CDT) Received: from [127.0.0.1] ([135.104.20.67]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4NMxAI20802; Wed, 23 May 2007 18:59:10 -0400 (EDT) Message-ID: <4654C739.9080601@bell-labs.com> Date: Wed, 23 May 2007 18:59:05 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: peter_blatherwick@mitel.com Subject: Re: [Sip] Re: Ambiguity, redirection and Fwd: I-D ACTION:draft-hilt-sip-correction-503-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org peter_blatherwick@mitel.com wrote: > >> o 500 would become overloaded to mean either "something bad (but > >> unspecified) happened" or "go somewhere else (maybe try again later)", > >> but it seems impossible to determine which case it is. The name of > >> this code implies only the former. > >> > > The changes proposed in the draft should not affect the 500 response > > code. In which respect would there be a change to 500? > > [PB] The change, as I see it, is that 503 would no longer be used to > send a client elsewhere, or cause the client to think it should go, > in fact would make the client think it should NOT go. So, 500 would > need to take on that meaning. > I don't think that the draft implies this change in semantics for 500s (and it certainly wasn't the intention). Even today, a client can always go somewhere else after a 500 if it has discovered an alternate server. I do think that there is an important point regarding the use for maintenance (see below). > [PB] The bits that triggered me thinking this way are: > ISSUE 3, sec 4, > "... Should all non-overload failures be changed to 500 (Server > Internal Error)? It would, e.g., enable a proxy [or client] to > try alternate servers for all non-overload failure cases." > and sec 6.1 > "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > NOT attempt to forward the request to an alternate server. ..." > > >> o 503 changes its meaning to "I'm overloaded, back off (optionally > don't > >> try again for some time)". But this is not the name of this response > >> -- it is Service Unavailable. The trouble is, there are many reasons > >> why service may not be available, overload being just one. (Yes, I > >> know this issue is raised as OPEN ISSUE 3 in the draft itself.) > >> > > 503 means that the "server is temporarily unable to process the request > > due to a temporary overloading or maintenance of the server." > > [PB] Current draft text is > "... server is temporarily unable to process the request due to a > temporary overloading ..." > The current draft covers overload only and does not address the maintenance aspect of 503. This is certainly something that needs to be addressed in the draft. One of the troubles of the maintenance and overload uses is that they have different requirements. For maintenance, it makes sense for a client to resend the request, which it should not do under overload. For this reason, if 503 is used for both cases, a client need to be able to tell what it is supposed to do. > > It seems that 503 is working reasonably well for maintenance but not for > > overload. So the question is if we can change the overload behavior > > without breaking the maintenance part. I believe that the proposed > > changes 1. - 4. would provide such a change if 503 is used as today for > > maintenance (with Retry-After) and without Retry-After as described for > > proxies under overload. > > [PB] But, for maintenance and similar cases, you may actually want the > client to go elsewhere for service. Text in the draft would prohibit > this from happening, see sec 6.1 > "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > NOT attempt to forward the request to an alternate server. ..." > Hence the proposal to make the desired redirect-like behaviour explicit > somehow. > Yes, I certainly agree. > >> Proposals: > >> > >> 1. Can a new 5xx response code be defined specifically to handle > >> overload scenarios, instead of overloading 503 / 500? This would have > >> the explicit semantic of "I'm overloaded, back off (optionally for some > >> time)". It could also have additional info on how the client should > >> handle it (see next). 503 would keep its original meaning (go > somewhere > >> else), and 500 would keep its meaning (something bad happened). > >> > > I think this would be closer to a new SIP extension for overload > > control, which I think is useful, than to a correction of RFC3261, which > > is the scope of this draft. > > [PB] Could be, or maybe not -- not really my call. Just a thought. But > if such a thing were to be done in overload work, it would effectively > be undoing this draft, would it not? > I wouldn't think so. I think getting the use of 503 under overload right is important and provides a basic/local way for a server to handle overload. It seems somewhat orthogonal to a SIP extension for overload control. > > I think that being specific in a response about what went wrong (e.g. > > "I'm overloaded") is useful since it will help the client to react > > properly (e.g. not to resend the request). > > [PB] Certainly agree here too. In fact, if we could find some way to > provide just that hint in 503 (reason = overload vs maintenance, vs > load sharing ... ), then we could distinguish the cases. This would > eliminate, or at least make less strong, the proposal for a new 5xx. I fully agree - and maybe there IS a case for a new response code. > Still think the redirect-like "go here" header would be good though. > > [snip] > >> I do understand the desire to minimize changes. But it is also > >> important to get the right behaviour, and not create situations open to > >> too much interpretation. [snip] > >> > > I agree. However, as mentioned, this draft is not intending to propose a > > SIP extension for overload control. > > [PB] One problem being, the changes in this draft do focus on overload, > yet the more general overload work does not focus on any of the other > scenarios. > Generally, I think an overload control mechanism should focus on overload control and not try to cover as much as possible. But it certainly should not break anything that works today. Volker _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 24 04:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr8zt-0000mH-Fi; Thu, 24 May 2007 04:48:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hr8zs-0000m9-9u for sip-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 04:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr8zr-0000m1-By for sip@ietf.org; Thu, 24 May 2007 04:48:35 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr8zp-0004gA-RF for sip@ietf.org; Thu, 24 May 2007 04:48:35 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JIJ00H1EF4NAS@siemenscomms.co.uk> for sip@ietf.org; Thu, 24 May 2007 09:48:23 +0100 (BST) Date: Thu, 24 May 2007 09:48:32 +0100 From: "Elwell, John" In-reply-to: To: SIP IETF , Gonzalo Camarillo Message-id: <0D5F89FAC29E2C41B98A6A762007F5D012F0CD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: I-D ACTION:draft-camarillo-sip-body-handling-00.txt Thread-Index: AcedjVFZpbLwAWpOS5eKVNsCRpXx9QAUOq6g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Subject: [Sip] RE: I-D ACTION:draft-camarillo-sip-body-handling-00.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, Concerning the handling parameter, there is no normative statement in RFC 3261 mandating that this be supported, as far as I can see. The only normative language seems to be "If the handling parameter is missing, the value "required" SHOULD be assumed." There is no normative statement concerning what to do if it is present. Therefore any UA that inserts handling=optional should not rely on this being taken account of by the peer UA. John > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: 23 May 2007 23:50 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-camarillo-sip-body-handling-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Message Body Handling in the Session > Initiation Protocol (SIP) > Author(s) : G. Camarillo > Filename : draft-camarillo-sip-body-handling-00.txt > Pages : 9 > Date : 2007-5-23 > > This document clarifies how message bodies are handled in SIP. > Additionally, it discusses to which degree SIP user agents need to > support MIME (Multipurpose Internet Mail > Extensions)-encoding of body > parts. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-h > andling-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-camarillo-sip-body-handling-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-camarillo-sip-body-handling-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 24 04:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr985-0005bK-E8; Thu, 24 May 2007 04:57:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hr984-0005b8-Iv for sip-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 04:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr984-0005b0-8l for sip@ietf.org; Thu, 24 May 2007 04:57:04 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr982-0006B1-Vg for sip@ietf.org; Thu, 24 May 2007 04:57:04 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JIJ00J3ZFISG5@siemenscomms.co.uk> for sip@ietf.org; Thu, 24 May 2007 09:56:52 +0100 (BST) Date: Thu, 24 May 2007 09:57:01 +0100 From: "Elwell, John" Subject: RE: [Sip] Support for Multipart/MIME In-reply-to: <1ECE0EB50388174790F9694F77522CCF1095509E@zrc2hxm0.corp.nortel.com> To: Francois Audet , Dan Wing , Gonzalo Camarillo Message-id: <0D5F89FAC29E2C41B98A6A762007F5D012F0D4@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] Support for Multipart/MIME Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9AAAIzN4AAAR+nAABovpxA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com> <0bb501c79d78$6599e7d0$c6f0200a@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF1095509E@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 23 May 2007 21:37 > To: Dan Wing; Gonzalo Camarillo > Cc: sip@ietf.org; Paul Kyzivat; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME > > > > > In RFC3204, the QSIG or ISUP parts do not appear to have any > > meaning without the SDP. Or do they? For example, is it > > meaningful for me to send an INVITE that has only the QSIG > > part (and no SDP)? > > Sure: it's just a delayed offer answer. [JRE]Moreover, QSIG or ISUP parts can be sent in other messages without SDP, e.g., in an INFO request. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 24 10:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDtc-0006uu-Q2; Thu, 24 May 2007 10:02:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrDtb-0006ox-KI for sip-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:02:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDtb-0006my-9i for sip@ietf.org; Thu, 24 May 2007 10:02:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrDtZ-0000XI-Tu for sip@ietf.org; Thu, 24 May 2007 10:02:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2007 10:02:26 -0400 X-IronPort-AV: i="4.14,573,1170651600"; d="scan'208"; a="121929490:sNHT54126544" 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 l4OE2PsY011197; Thu, 24 May 2007 10:02:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4OE2C5x001700; Thu, 24 May 2007 14:02:25 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.1830); Thu, 24 May 2007 10:02:17 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 10:02:17 -0400 Message-ID: <46559AE7.4060408@cisco.com> Date: Thu, 24 May 2007 10:02:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] RE: I-D ACTION:draft-camarillo-sip-body-handling-00.txt References: <0D5F89FAC29E2C41B98A6A762007F5D012F0CD@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D012F0CD@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2007 14:02:17.0412 (UTC) FILETIME=[23675840:01C79E0C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4085; t=1180015345; x=1180879345; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20RE=3A=20I-D=20ACTION=3Adraft-camarillo-sip-bo dy-handling-00.txt |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=yL7D6P05f/ZtVWvRZS+oQrlAS2x8DwTnEa/LSyPZQQ4=; b=lhcy+mxM8vUv+FVn3GfJMz5MCfQeD9kgPPHLsV3KmUWFcupchR6b9zckIXL8OaGd3l2aBdVX 8goMrvboTd7+t/O+28oCFfraDFPLWi7AujwnQqg+UZ3PUFFKozkvrmjR; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: SIP IETF , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Gonzalo, > > Concerning the handling parameter, there is no normative statement in > RFC 3261 mandating that this be supported, as far as I can see. The only > normative language seems to be "If the handling parameter is missing, > the value "required" SHOULD be assumed." There is no normative statement > concerning what to do if it is present. Therefore any UA that inserts > handling=optional should not rely on this being taken account of by the > peer UA. Things are a bit messed up wrt this header: - 3261 section 20.11 says: "This SIP header field extends the MIME Content-Type (RFC 2183 [18])." But RFC 2183 is about Content-Disposition, so there is clearly a typo here. - From reading that section you might think that 3261 invented the handling parameter. It isn't defined in 2183, but it is defined in 3204 which was published prior to 3261. That does have normative statements about how the parameter is to be processed. So 3261 should have referenced that. I don't know how we are going to dig ourselves out of this hole. I suppose the usual answer is a new option tag. Paul > John > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: 23 May 2007 23:50 >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-camarillo-sip-body-handling-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Message Body Handling in the Session >> Initiation Protocol (SIP) >> Author(s) : G. Camarillo >> Filename : draft-camarillo-sip-body-handling-00.txt >> Pages : 9 >> Date : 2007-5-23 >> >> This document clarifies how message bodies are handled in SIP. >> Additionally, it discusses to which degree SIP user agents need to >> support MIME (Multipurpose Internet Mail >> Extensions)-encoding of body >> parts. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-h >> andling-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-camarillo-sip-body-handling-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE >> /internet-drafts/draft-camarillo-sip-body-handling-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 24 15:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJK6-0000Vt-G9; Thu, 24 May 2007 15:50:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrJJz-0000N8-4V for sip-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJJy-0000Ms-N1; Thu, 24 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrJJy-00046s-Cx; Thu, 24 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5D36B3294A; Thu, 24 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HrJJy-0000ku-8P; Thu, 24 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 24 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-04.txt Pages : 54 Date : 2007-5-24 This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sips-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sips-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-24141947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-24141947.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Thu May 24 23:56:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrQuQ-0000CV-4n; Thu, 24 May 2007 23:56:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrQuP-0000CI-5I for sip-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 23:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrQuO-0000C2-RJ for sip@ietf.org; Thu, 24 May 2007 23:56:08 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrQuN-0001D7-3a for sip@ietf.org; Thu, 24 May 2007 23:56:08 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIK00JY1W8BDP@szxga01-in.huawei.com> for sip@ietf.org; Fri, 25 May 2007 11:55:23 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIK000H2W8A32@szxga01-in.huawei.com> for sip@ietf.org; Fri, 25 May 2007 11:55:23 +0800 (CST) Received: from z13645a ([10.70.145.63]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIK008R2W87NO@szxml03-in.huawei.com> for sip@ietf.org; Fri, 25 May 2007 11:55:22 +0800 (CST) Date: Fri, 25 May 2007 11:55:19 +0800 From: Lavis Chow To: sip@ietf.org Message-id: <009f01c79e80$830b8040$3f91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Aceefa2oNbwl9+WmRTaUso0VTPx50AAAq7XQ X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 (2006-07)] X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, In ETSI TS 102 027-2 V4.1.1 (2006-07), test case SIP_CC_PR_TR_SE_V_014, = it mentioned : TPId: SIP_CC_PR_TR_SE_V_014 Status: PICS: A.77/3.2 Ref: RFC 3261 [1] sections 17.2.2 and 17.2.3. Purpose: Ensure that the IUT in a server BYE Proceeding state, on = receipt of a BYE request, including a Via header set with a different branch = parameter without the magic cookie "z9hG4bK" but with the Request-URI, To tag, = From tag, Call-ID, CSeq and top Via header identical as in the first BYE = request, repeats its last response. But as per Via header comparison rule defined in RFC3261 20.42 Via,=20 Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal. So that one Via with different branch value, so second BYE with a = different branch parameter will never the transaction create by the first BYE, so = it shall not repeats its last response. so the test case is wrong. Does I miss sth? Thanks, Lavis=20 -------------------------------------------------------------------------= --- --------------------------------------------------------- =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA =D7=E9=A1=A3=BD=FB =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3= =CA =BC=FE=D6=D0 =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC= =FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA= =B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 This e-mail and its attachments contain confidential information from HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, total or partial=20 disclosure, reproduction, or dissemination) by persons other than the intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by=20 phone or email immediately and delete it! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 06:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXHR-00056q-UW; Fri, 25 May 2007 06:44:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrXHP-00056N-V7 for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 06:44:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXHP-000569-Kl for sip@ietf.org; Fri, 25 May 2007 06:44:19 -0400 Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXHO-00081M-5p for sip@ietf.org; Fri, 25 May 2007 06:44:19 -0400 Received: from [192.168.223.125] (cable-89-216-177-142.dynamic.sbb.co.yu [89.216.177.142]) by post.webmailer.de (mrclete mo4) (RZmta 6.8) with ESMTP id O014c4j4P8X1cQ for ; Fri, 25 May 2007 12:44:15 +0200 (MEST) Message-ID: <4656BDFE.7020006@zesium.com> Date: Fri, 25 May 2007 12:44:14 +0200 From: Nina Garaca User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: jOJcr21HrPtUiRe9YmcRL+xtCcHiEk+2Cyz0y9h7zgP4m305c2pJpepT4Heis7LEQrg= X-RZG-CLASS-ID: mo00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Contact header in 1xx responses/updates remote target or not? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, I have some questions regarding 1xx responses that establishes dialog (with To tag) . Q1: Should I expect that these responses have a Contact header? Q2: If they do so, should the remote target of the dialog be refreshed by that Contact at the side that has received that 1xx response and should the remote target of the dialog be refreshed by the Contact in the INVITE request at the side that has received that INVITE? Q3: If not, should the remote target of the dialog be refreshed by the Contact in the INVITE request at the side that has received that INVITE and has sent dialog establishing 1xx response? Thanks in advance. Best Regards Nina. -- Nina Garaca Software Development & Testing --- "ZESIUM mobile" d.o.o. Valentina Vodnika 8/9 21000 Novi Sad Serbia Tel: +381 (0)21 472 15 48 Fax: +381 (0)21 472 15 49 Mob: +381 (0)63 16 15 891 E-mail: nina.garaca@zesium.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 08:21:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYnY-00018r-LJ; Fri, 25 May 2007 08:21:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrYnX-00018l-1a for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 08:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYnW-00018d-O9 for sip@ietf.org; Fri, 25 May 2007 08:21:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrYnV-0002qq-GA for sip@ietf.org; Fri, 25 May 2007 08:21:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2007 08:21:33 -0400 X-IronPort-AV: i="4.14,579,1170651600"; d="scan'208"; a="122034240:sNHT48088686" 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 l4PCLXe0029948; Fri, 25 May 2007 08:21:33 -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.12.10/8.12.6) with ESMTP id l4PCLW5h004554; Fri, 25 May 2007 12:21:33 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.1830); Fri, 25 May 2007 08:21:32 -0400 Received: from [10.86.241.71] ([10.86.241.71]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 08:21:32 -0400 Message-ID: <4656D4CC.4040707@cisco.com> Date: Fri, 25 May 2007 08:21:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Nina Garaca Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? References: <4656BDFE.7020006@zesium.com> In-Reply-To: <4656BDFE.7020006@zesium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2007 12:21:32.0472 (UTC) FILETIME=[3AC07380:01C79EC7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1729; t=1180095693; x=1180959693; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Contact=20header=20in=201xx=20responses/updat es=20remote=20target=20or=0A=20not? |Sender:=20 |To:=20Nina=20Garaca=20; bh=NPFPXy1hHZyqjKy3ZvKStH8JENyTiOq+mEIQ37nBZXM=; b=ExkKDFqbglVGTypZ9W3gTfEw3ktgTLyhva3VIEexBDiUwJOQiBGKzd7Dn0bphmsLINHTLOMH 4FA4zjrfnAYBbFoZ2xe5hbkO8VZEaUqp7YGBLayJd0odxlzfyEjXaGd0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Nina Garaca wrote: > Hi All, > > I have some questions regarding 1xx responses that establishes dialog > (with To tag) . > > Q1: Should I expect that these responses have a Contact header? Yes. If it doesn't then it hasn't provided enough information to establish the dialog. > Q2: If they do so, should the remote target of the dialog be refreshed > by that Contact at the side that has received that 1xx response and > should the remote target of the dialog be refreshed by the Contact in > the INVITE request at the side that has received that INVITE? Wel, the first response isn't really a "refresh" since until then you don't have one to refresh. I suppose if the address were to change before the completion of the INVITE transaction then it *could* be refreshed in subsequent 1xx responses. But unless you are using reliable provisionals that is problematic, since you don't know if the provisionals have been received. One would hope that this situation will not arise. Regarding the UAS, I don't understand the question. It receives the initial INVITE, which contains the contact from the UAC. That is the only one it gets. In an initial INVITE there is no question of "refreshing". In the case of a reINVITE, the value is a "refresh", and it doesn't take effect (refresh) until and unless it successfully completes. (I believe there is some degree of controversy over this last point.) Paul > Q3: If not, should the remote target of the dialog be refreshed by the > Contact in the INVITE request > at the side that has received that INVITE and has sent dialog > establishing 1xx response? > > Thanks in advance. > Best Regards > Nina. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 10:29:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hran7-0005aa-77; Fri, 25 May 2007 10:29:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hran5-0005aV-8E for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hran4-0005aN-FI for sip@ietf.org; Fri, 25 May 2007 10:29:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hran3-00022s-6T for sip@ietf.org; Fri, 25 May 2007 10:29:14 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4PETC1H010314 for ; Fri, 25 May 2007 09:29:12 -0500 (CDT) Received: from [135.185.197.212] (dtrobinson-c1.ih.lucent.com [135.185.197.212]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l4PETCa10031 for ; Fri, 25 May 2007 09:29:12 -0500 (CDT) Message-ID: <4656F2B8.9090109@alcatel-lucent.com> Date: Fri, 25 May 2007 09:29:12 -0500 From: David Robinson User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [Sip] Questions about SDP session-id changes within a SIP dialog. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, After reading RFC 3725 BCP for 3rd Party Call Control it created an interesting question. Is an SDP session-id tied directly to a SIP dialog and cannot change in the SIP dialog? RFC 3725 seems to imply that but I cannot find any documentation that specifically states this. (Because of the mapping of the o= line ). Consider the following scenario when Early media is provided and the call is forwarded to another location. At Answer an Empty Re-Invite is used perform End to End SDP negotiation and the B2BUA proxies the SDP (without change) to complete the Path minimization. This causes a change in the SDP session ID to the originator also allowing for payload type numbers to be re-mapped. Without the possibility of changing the SDP session-id there are cases, mainly in inter-vendor situations, that cause collision of Dynamic Payload type numbers. Unfortunately trying to do all the remapping of payload types in the bearer stream is not a viable option. In addition to this scenario, there are scenarios (Blind Transfers for one) that a newly added leg is originated with an Empty Initial Invite requiring the Far office to send an initial offer and now how do you match up SDP media lines and payload types numbers for these? If changing the session-id is not the correct solution how do is this solved? RFC 3264 states that payload type number MUST not change within a session (i.e. SDP session) but it states that the Payload type number do not have to be the same in both directions and thanks to H248 this is the case. If I extend what is not in RFC3264 to say that if the upper layer protocol provides a new session-id within a SIP dialog then I can re map the Payload type numbers and the SDP Session-id and new SDP version number are considered valid and everything works. What is the opinion of the BCP 3725 authors or those working with SIP RFCs? Thanks Dave Robinson Alcatel-Lucent _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 11:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrbib-0006vZ-Qx; Fri, 25 May 2007 11:28:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hrbia-0006uM-AL for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 11:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrbia-0006uE-0f for sip@ietf.org; Fri, 25 May 2007 11:28:40 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrbiY-0007P3-M2 for sip@ietf.org; Fri, 25 May 2007 11:28:39 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 May 2007 11:28:38 -0400 X-IronPort-AV: i="4.14,580,1170651600"; d="scan'208"; a="122051237:sNHT46103554" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4PFScvg023468; Fri, 25 May 2007 11:28:38 -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.12.10/8.12.6) with ESMTP id l4PFSY5l021436; Fri, 25 May 2007 15:28:38 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.1830); Fri, 25 May 2007 11:28:37 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 11:28:37 -0400 Message-ID: <465700A3.5000503@cisco.com> Date: Fri, 25 May 2007 11:28:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Robinson Subject: Re: [Sip] Questions about SDP session-id changes within a SIP dialog. References: <4656F2B8.9090109@alcatel-lucent.com> In-Reply-To: <4656F2B8.9090109@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2007 15:28:37.0025 (UTC) FILETIME=[5D1B5110:01C79EE1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2703; t=1180106918; x=1180970918; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Questions=20about=20SDP=20session-id=20change s=20within=20a=20SIP=20dialog. |Sender:=20 |To:=20David=20Robinson=20; bh=wd3iKVQp5m9vB5Z+1B+SqMuhWQA4CzIWKyMM9bD+C8M=; b=kBZDcRjz290Hc1TUFyoZlwnSACKSxlc78S9K5mBxJxlJO/JrIVKtzkpR0/+rn5B6z7AKnpQN Bq3pjEmpsI8kT558Ejnpk3b3PjFI8GlStvIarKZwPLc1qWyBxuz+9nid; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The sipping list would be more appropriate for this. I will post a reply there and suggest further discussion proceed there. (I'm not including both lists in the same reply to avoid having all subsequent discussion go to both.) Paul David Robinson wrote: > All, > After reading RFC 3725 BCP for 3rd Party Call Control it created an > interesting question. > > Is an SDP session-id tied directly to a SIP dialog and cannot change in > the SIP dialog? > RFC 3725 seems to imply that but I cannot find any documentation that > specifically > states this. (Because of the mapping of the o= line ). > > Consider the following scenario when Early media is provided and the > call is forwarded to another location. At Answer an Empty Re-Invite is > used perform > End to End SDP negotiation and the B2BUA proxies the SDP (without > change) to > complete the Path minimization. This causes a change in the SDP session > ID to the > originator also allowing for payload type numbers to be re-mapped. > Without the > possibility of changing the SDP session-id there are cases, mainly in > inter-vendor situations, > that cause collision of Dynamic Payload type numbers. Unfortunately > trying to do all the > remapping of payload types in the bearer stream is not a viable option. > > In addition to this scenario, there are scenarios (Blind Transfers for > one) that a newly > added leg is originated with an Empty Initial Invite requiring the Far > office to send an > initial offer and now how do you match up SDP media lines and payload types > numbers for these? > > If changing the session-id is not the correct solution how do is this > solved? > RFC 3264 states that payload type number MUST not change within a session > (i.e. SDP session) but it states that the Payload type number do not > have to be > the same in both directions and thanks to H248 this is the case. > > If I extend what is not in RFC3264 to say that if the upper layer > protocol provides > a new session-id within a SIP dialog then I can re map the Payload type > numbers > and the SDP Session-id and new SDP version number are considered valid and > everything works. > > What is the opinion of the BCP 3725 authors or those working with SIP RFCs? > > Thanks > Dave Robinson > Alcatel-Lucent > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 16:03:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrg0G-0006gv-G3; Fri, 25 May 2007 16:03:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hrg0E-0006gd-PA for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 16:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrg0E-0006gS-E8 for sip@ietf.org; Fri, 25 May 2007 16:03:10 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrfzv-0006Sr-CK for sip@ietf.org; Fri, 25 May 2007 16:03:10 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 22F6420083 for ; Fri, 25 May 2007 16:02:51 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06277-04-7 for ; Fri, 25 May 2007 16:02:51 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 43C122002A for ; Fri, 25 May 2007 16:02:49 -0400 (EDT) From: Niall_Gallagher@mitel.com To: sip@ietf.org Message-ID: Date: Fri, 25 May 2007 16:02:47 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 05/25/2007 04:02:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] Out of Office -- Niall Gallagher X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 24/05/2007 and will not return until 04/06/2007. I will be on vacation from May 24th, until Monday, June 4th. I will not have access to email and will not be checking voicemail. If there are items requiring my attention please refer them to Tim Kostyniuk (tim_kostyniuk@mitel.com). Niall Niall _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 17:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrh65-0001od-2Y; Fri, 25 May 2007 17:13:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hrh63-0001oY-Nm for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 17:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrh63-0001oQ-E7 for sip@ietf.org; Fri, 25 May 2007 17:13:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrh62-0005z1-43 for sip@ietf.org; Fri, 25 May 2007 17:13:15 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 25 May 2007 14:13:13 -0700 X-IronPort-AV: i="4.14,581,1170662400"; d="scan'208"; a="2726128:sNHT20362560" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4PLDDok006429; Fri, 25 May 2007 14:13:13 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4PLD70C007357; Fri, 25 May 2007 21:13: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.1830); Fri, 25 May 2007 17:13:09 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.162]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 17:13:08 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 May 2007 16:13:07 -0500 To: Paul Kyzivat , "Elwell, John" From: "James M. Polk" Subject: Re: [Sip] RE: I-D ACTION:draft-camarillo-sip-body-handling-00.txt In-Reply-To: <46559AE7.4060408@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D012F0CD@GBNTHT12009MSX.gb002.siemens.net> <46559AE7.4060408@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2007 21:13:08.0609 (UTC) FILETIME=[7E54B710:01C79F11] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1479; t=1180127593; x=1180991593; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Sip]=20RE=3A=20I-D=0A=20=20ACTION=3Adraft-camarillo- sip-body-handling-00.txt |Sender:=20; bh=2dJe3KNbXNaEHu174m3tnfXpt+wdydtlv2tUsA6PZMo=; b=BECAkr87xxK8PrZ/l2iczjjuyaC27FcxiIvoI3+dJJiD4WyzPQ79kSKC7RCqyhfd88e/hNtO ux2TaYLcVnN1M3mpBG+JUigTMjylYMF5fm5XdxgK5Ks2UL402r6GvhUh; Authentication-Results: sj-dkim-7; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF , Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 09:02 AM 5/24/2007, Paul Kyzivat wrote: >Elwell, John wrote: >>Gonzalo, >>Concerning the handling parameter, there is no normative statement in >>RFC 3261 mandating that this be supported, as far as I can see. The only >>normative language seems to be "If the handling parameter is missing, >>the value "required" SHOULD be assumed." There is no normative statement >>concerning what to do if it is present. Therefore any UA that inserts >>handling=optional should not rely on this being taken account of by the >>peer UA. > >Things are a bit messed up wrt this header: > >- 3261 section 20.11 says: "This SIP header field extends the MIME > Content-Type (RFC 2183 [18])." But RFC 2183 is about > Content-Disposition, so there is clearly a typo here. > >- From reading that section you might think that 3261 invented the > handling parameter. It isn't defined in 2183, but it is defined > in 3204 which was published prior to 3261. That does have normative > statements about how the parameter is to be processed. So 3261 > should have referenced that. > >I don't know how we are going to dig ourselves out of this hole. how about write a quite Update to 3261 pointing to 3204 instead of 2183. Then obsoleting this new Update with Gonzalo's ID (that clears the handling parameter up)... just an (unusual) thought (to a non-straightforward problem) >I suppose the usual answer is a new option tag. > > Paul > >>John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 17:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhGb-0002Cd-6G; Fri, 25 May 2007 17:24:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrhGY-00026P-Pb for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 17:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrhGY-00022w-9Y for sip@ietf.org; Fri, 25 May 2007 17:24:06 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrhGX-0000IF-3i for sip@ietf.org; Fri, 25 May 2007 17:24:06 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc15) with ESMTP id <2007052521240401500cb8tce>; Fri, 25 May 2007 21:24:04 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4PLO48t026857 for ; Fri, 25 May 2007 17:24:04 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4PLO4Qt026853; Fri, 25 May 2007 17:24:04 -0400 Date: Fri, 25 May 2007 17:24:04 -0400 Message-Id: <200705252124.l4PLO4Qt026853@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <009f01c79e80$830b8040$3f91460a@china.huawei.com> (lavis@huawei.com) Subject: Re: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 (2006-07)] References: <009f01c79e80$830b8040$3f91460a@china.huawei.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Lavis Chow Purpose: Ensure that the IUT in a server BYE Proceeding state, on receipt of a BYE request, including a Via header set with a different branch parameter without the magic cookie "z9hG4bK" but with the Request-URI, To tag, From tag, Call-ID, CSeq and top Via header identical as in the first BYE request, repeats its last response. Since "z9hG4bK" is not to be present, it may be testing RFC 2543 behavior. Does this test make sense in that light? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri May 25 22:46:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrmId-00070F-6Q; Fri, 25 May 2007 22:46:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HrmIb-000706-8v for sip-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 22:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrmIa-0006zt-V0 for sip@ietf.org; Fri, 25 May 2007 22:46:32 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrmIa-0005E0-6y for sip@ietf.org; Fri, 25 May 2007 22:46:32 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIM00M6TNOFEZ@szxga01-in.huawei.com> for sip@ietf.org; Sat, 26 May 2007 10:45:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIM002QTNOF49@szxga01-in.huawei.com> for sip@ietf.org; Sat, 26 May 2007 10:45:51 +0800 (CST) Received: from z13645a ([10.70.145.63]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIM0007NNOCOY@szxml03-in.huawei.com> for sip@ietf.org; Sat, 26 May 2007 10:45:51 +0800 (CST) Date: Sat, 26 May 2007 10:45:38 +0800 From: Lavis Chow Subject: RE: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 (2006-07)] In-reply-to: <200705252124.l4PLO4Qt026853@dragon.ariadne.com> To: Dale.Worley@comcast.net, sip@ietf.org Message-id: <000301c79f3f$f7330320$3f91460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcefEwrvfbAxmNMnSWmY+7Bq2M+5DQALBCGg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Not sure the purpose is the "Purpose" list in the test case or for 2543 test? But the [Ref] listed in the test case is reference to RFC3261. And for RFC2543(not bis02 afterwards) server, it didn't check the Via for the request matching transaction at all. Lavis -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Saturday, May 26, 2007 5:24 AM To: sip@ietf.org Subject: Re: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 (2006-07)] From: Lavis Chow Purpose: Ensure that the IUT in a server BYE Proceeding state, on receipt of a BYE request, including a Via header set with a different branch parameter without the magic cookie "z9hG4bK" but with the Request-URI, To tag, From tag, Call-ID, CSeq and top Via header identical as in the first BYE request, repeats its last response. Since "z9hG4bK" is not to be present, it may be testing RFC 2543 behavior. Does this test make sense in that light? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat May 26 00:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HroIZ-00057G-0Z; Sat, 26 May 2007 00:54:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HroIX-000575-7U for sip-confirm+ok@megatron.ietf.org; Sat, 26 May 2007 00:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HroIW-00056x-U6 for sip@ietf.org; Sat, 26 May 2007 00:54:36 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HroIV-0005qV-Mu for sip@ietf.org; Sat, 26 May 2007 00:54:36 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070526045435b1600nvu4he>; Sat, 26 May 2007 04:54:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4Q4sY8t027176 for ; Sat, 26 May 2007 00:54:34 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4Q4sYOV027172; Sat, 26 May 2007 00:54:34 -0400 Date: Sat, 26 May 2007 00:54:34 -0400 Message-Id: <200705260454.l4Q4sYOV027172@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4656BDFE.7020006@zesium.com> (nina.garaca@zesium.com) Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not? References: <4656BDFE.7020006@zesium.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Nina Garaca Q1: Should I expect that these responses have a Contact header? As Paul says, if it didn't have a Contact header, it couldn't establish a dialog. Q2: If they do so, should the remote target of the dialog be refreshed by that Contact at the side that has received that 1xx response and should the remote target of the dialog be refreshed by the Contact in the INVITE request at the side that has received that INVITE? Responses are not "target refresh requests", so they don't change the target address at their end of the dialog. But of course, the responses to the dialog-initiating request establish the initial target address. Q3: If not, should the remote target of the dialog be refreshed by the Contact in the INVITE request at the side that has received that INVITE and has sent dialog establishing 1xx response? RFC 3261 section 12.2: INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat May 26 06:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrttl-0001zS-C1; Sat, 26 May 2007 06:53:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hrttk-0001zK-Iz for sip-confirm+ok@megatron.ietf.org; Sat, 26 May 2007 06:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrttk-0001zC-9N for sip@ietf.org; Sat, 26 May 2007 06:53:24 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrtti-0000Tn-R9 for sip@ietf.org; Sat, 26 May 2007 06:53:24 -0400 Received: (qmail 28502 invoked by uid 0); 26 May 2007 10:54:37 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 26 May 2007 10:54:37 -0000 Message-ID: <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: , References: <4656BDFE.7020006@zesium.com> <200705260454.l4Q4sYOV027172@dragon.ariadne.com> Subject: Re: [Sip] Contact header in 1xx responses/updates remote target ornot? Date: Sat, 26 May 2007 12:51:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dale, Not sure if I read your comment right, but RFC3261 12.2.1.2 says When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. It does not say anything about 1xx responses here though...Regards,Jeroen Dale.Worley@comcast.net wrote: > From: Nina Garaca > > Q1: Should I expect that these responses have a Contact header? > > As Paul says, if it didn't have a Contact header, it couldn't > establish a dialog. > > Q2: If they do so, should the remote target of the dialog be > refreshed by that Contact at the side that has received that 1xx > response and should the remote target of the dialog be refreshed by > the Contact in the INVITE request at the side that has received > that INVITE? > > Responses are not "target refresh requests", so they don't change the > target address at their end of the dialog. But of course, the > responses to the dialog-initiating request establish the initial > target address. > > Q3: If not, should the remote target of the dialog be refreshed by > the Contact in the INVITE request > at the side that has received that INVITE and has sent dialog > establishing 1xx response? > > RFC 3261 section 12.2: > > INVITE, the only target refresh request defined is re-INVITE (see > Section 14). Other extensions may define different target refresh > requests for dialogs established in other ways. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 27 15:21:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOI6-0002U1-CV; Sun, 27 May 2007 15:20:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsOI5-0002Tw-0O for sip-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 15:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOI4-0002To-My for sip@ietf.org; Sun, 27 May 2007 15:20:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsOI2-00060o-A3 for sip@ietf.org; Sun, 27 May 2007 15:20:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 61B9320488; Sun, 27 May 2007 21:20:29 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-82-4659d9fdc72f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 387B5203EB; Sun, 27 May 2007 21:20:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:20:29 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:20:28 +0200 Received: from [131.160.126.28] (rvi2-126-28.lmf.ericsson.se [131.160.126.28]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D22B42467; Sun, 27 May 2007 22:20:27 +0300 (EEST) Message-ID: <4659D9FA.70501@ericsson.com> Date: Sun, 27 May 2007 22:20:26 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> In-Reply-To: <46545100.5040707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2007 19:20:28.0555 (UTC) FILETIME=[15D9D5B0:01C7A094] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, thanks for your comments. Answers inline: Paul Kyzivat wrote: > Gonzalo, > > Thank you for doing this. It is a great start. I largely agree with what > you have written. > > One specific comment about the draft: > > - Open issue in section 3: perhaps a new Reason code, to be used > with a 415 response would be adequate. what do you mean by a reason code? Do you mean a Warning code?... because Reason header fields are not allowed in responses. > I think there are a number of loose ends, some mentioned, some not. In > many cases, while I have an opinion what the right answer might be I > think it needs discussion. Here is what I came up with: > > - How to determine what processing a body part should receive > > In many cases the processing of a body part is determined by: the > content disposition, the content type, and perhaps the context within > which the message is received. For instance, this is true for type sdp > with disposition session in an INVITE; for type text/plain with > disposition render in a MESSAGE; and for type kpml with disposition ??? > in a SUBSCRIBE. In these cases there is no overt *reference* to the body > part. > > In other cases the processing is determined by the context of a > reference to the body part via a cid: url that references the Content-ID > of the body part. You mentioned this as well. > > The case I am concerned with is when there is ambiguity between these. > For instance 3261 defines Content-Dispositions "alert" and "icon". While > these aren't described very well, it appears that if a body part is > present with disposition "alert" then it should be used for alerting > based on its presence, without any overt reference. But there is also an > Alert-Info header, which *could* contain a cid: url. If there was an > Alert-Info header with a cid: url that referenced a body part, must that > body part be of disposition "alert"? > > Its my feeling that the definition of each disposition should specify > how use decisions should be made for body parts having this disposition. > There should be one or more dispositions that state that their use is to > be determined by how they are referenced. And headers that might > reference body parts should define the acceptable dispositions for the > body parts that are referenced. > > If a message contains a body part with type and disposition that defines > how it is processed without need of a reference, and there *also* is a > reference to it, then it should be processed both ways. (This however > should happen rarely or never.) I have added more structure to the draft (i.e., a few new sections) that I believe make it easier to read. You can fetch a working version from: http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt The points above are covered in Sections 4.2, 4.3, and 5. I have added a few guidelines to authors of future extensions so that folks writing specs are also aware of all these issues and take them into consideration when writing new extensions. > - What Content-Disposition type should multipart bodies have? > > When you have a multipart body, it has a disposition, and each of its > contained body parts also has a disposition. I have never seen any > specification of what disposition the multipart itself should have. None > of the examples I have seen have had a Content-Disposition header in the > multipart. According to the sip defaulting rules, a multipart body > without a C-D header has disposition "render", which seems a bit weird. > > In the case of multipart/alternative, I think the disposition type of > all the contained body parts should be identical. I think it would also > make sense for the multipart/alternative itself to contain the same > disposition. That would simplify processing, because the whole thing > could be ignored if the disposition has a type that will be ignored. That's now covered in Section 4.1 > In the case of multipart/mixed, the disposition types of the contained > body parts will typically vary. The type of the mixed body simply needs > to be something that causes it to be processed. Using the default of > "render" seems weird to me. It would make sense to me to have some > special C-D type for this purpose. Potentially it could be defined as > the default C-D for multipart/mixed in the same way that "session" is > the default for type application/sdp. That's OPEN ISSUE 3 now. We may indeed need to define a new disposition type. > - Must the recipient of a message process all multipart bodies and their > contents? Recursively? > > Note that a multipart body can contain other multipart body parts, thus > potentially forming a tree of body parts of arbitrary shape and depth. > > So, the developer of a UA will want to know: do I have to parse all of > that? > > I think the answer is: like anything else, you make this decision based > on the disposition type and handling. (If you understand multipart/mixed > (and you should) then you also understand that multipart/X where you > don't know X should be processed the same as multipart/mixed.) > > If handling is optional and the disposition type and content type are > known to you, then you must parse it. Each contained body part is then > processed based on its own disposition. If the handling is optional and > the disposition type or content type are not known to you then you can > ignore it. > > (This puts a premium on having an agreed to disposition type that is > typically used for multipart/mixed and which everyone that supports > multipart is expected to support.) I think that is now clear in the new version... but let me know if you do not think so. > - What "handling" value should be used for multipart bodies and the > contained body parts? > > If a body part is referenced by a cid: url in a header (or in another > body part I suppose), then the handling of the body part should be > required. > > Contained, non-multipart body parts that aren't referenced by cid: can > have handling required or optional as appropriate for their use. > > A multipart body should have handling of required if any of the parts it > contains are required. Otherwise it may have optional handling. > > Multipart/alternative is tricky. Only one alternative is to be used, and > it is assumed that some alternatives may not be understood. So it seems > that all except the first contained body part should have optional > handling. The first may be required or optional depending on whether its > ok to handle none. And the handling of the multipart/alternative > container is as above. That's now covered in Section 4.1 > - What about "gratuitous" nesting of multiparts? > > It seems that it is technically valid to wrap a body part, such as an > SDP offer, in one or many levels of multipart wrappers. A recipient who > receives such a thing, and processes it according to what Gonzalo has > specified and what I have suggested above, should be able to deal with > this. > > But its not a good thing. > > So I think we ought to at least state that the sender of a request > SHOULD NOT use a multipart wrapper when there is only one part, and > SHOULD NOT nest one multipart/mixed within another unless there is a > *reference* to the nested one. (Instead of nesting, include all the > parts in the outer multipart.) And a sender SHOULD NOT nest one > multipart/alternative within another. That's now covered in Section 3.2 I have numbered the OPEN ISSUES. Now the draft contain 4 of them. I would like to discuss how to close them. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 27 15:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOKW-000438-1S; Sun, 27 May 2007 15:23:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsOKV-000413-3T for sip-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 15:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOKU-00040v-Q1 for sip@ietf.org; Sun, 27 May 2007 15:23:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsOKU-00070A-4F for sip@ietf.org; Sun, 27 May 2007 15:23:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A4EA12058F; Sun, 27 May 2007 21:23:01 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-9c-4659da951dc0 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8C0F42023D; Sun, 27 May 2007 21:23:01 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:23:00 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:23:00 +0200 Received: from [131.160.126.28] (rvi2-126-28.lmf.ericsson.se [131.160.126.28]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F28092467; Sun, 27 May 2007 22:22:59 +0300 (EEST) Message-ID: <4659DA93.9040702@ericsson.com> Date: Sun, 27 May 2007 22:22:59 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <46545DA4.7070108@cisco.com> In-Reply-To: <46545DA4.7070108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2007 19:23:00.0614 (UTC) FILETIME=[707C3260:01C7A094] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, I have added a few guidelines about this in Section 5 of the new version of the draft: http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt With those guidelines and the behavior defined in other sections, we should be OK. Let me know if you agree or want to add further clarifications or behavior. Thanks, Gonzalo Paul Kyzivat wrote: > Revising one point: > > Paul Kyzivat wrote: > >> - What "handling" value should be used for multipart bodies and the >> contained body parts? >> >> If a body part is referenced by a cid: url in a header (or in another >> body part I suppose), then the handling of the body part should be >> required. > > On reflection, this is tricky. > > If the header containing the reference is optional (as most are), then > recipients that don't understand the header will have no need for the > referenced part. If it were required and they don't support the type, > then they would fail the request. This is bad. > > So if processing of the header is optional, then the referenced body > part should have optional handling. > > But then there could be a problem if the recipient does understand and > process the header, but doesn't understand the body part, and so because > it is optional doesn't process it. In that case, the cid reference will > be unsatisfied. This could also result in an inappropriate error. > > I think the solution here is that if a header contains a cid url, and if > that url cannot be resolved to a body part that is supported, then the > UA should treat it the same as if the header itself was not understood - > typically ignoring it unless there is a Require in effect that demands > failing the request. > > An alternative is to require that Content-ID be remembered even for > parts that are not understood, so that references can be resolved even > if they can't be processed. This would allow more precise errors to be > generated. This wouldn't be so hard at an outer level, but it might be > troublesome in conjunction with nesting. > > Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 27 15:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOQe-0007C6-0d; Sun, 27 May 2007 15:29:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsOQc-0007Bv-Ih for sip-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 15:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOQc-0007Bn-95 for sip@ietf.org; Sun, 27 May 2007 15:29:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsOQb-0000Q6-Hs for sip@ietf.org; Sun, 27 May 2007 15:29:22 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CDFFA20508; Sun, 27 May 2007 21:29:20 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-eb-4659dc10daef Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A1AC720401; Sun, 27 May 2007 21:29:20 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:29:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:29:19 +0200 Received: from [131.160.126.28] (rvi2-126-28.lmf.ericsson.se [131.160.126.28]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3AF7A2467; Sun, 27 May 2007 22:29:19 +0300 (EEST) Message-ID: <4659DC0E.1020005@ericsson.com> Date: Sun, 27 May 2007 22:29:18 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10954E05@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2007 19:29:20.0024 (UTC) FILETIME=[52A19180:01C7A095] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, Paul Kyzivat , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Francois, thanks for the comments. Answers inline: [by the way, Gonzalo has one 'l'; it is Camarillo the one with two 'l's ;o) ] Francois Audet wrote: > This is great Gonzallo. Thanks for doing this. > > Here are some comments: > > - In section 4, another example that I think you should list for > Multipart/Mixed is RFC 3204 which actually has examples of > INVITEs with Multipart/Mixed (one for SDP, the other for > QSIG/ISUP tunnelling). That spec also illustrates the content- > disposition mechanism (i.e., "optional" for QSIG/ISUP). I have added another reference to it in Section 3 as an additional example. You can fetch the new working version of the draft from: http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt > > - I like your text on Multipart/Alternative. I'd like to include the > following snippet of text from draft-jennings-sipping-multipart-02.txt > in there: > > It is critical that multipart/alternative offers follow the semantics > of multipart/alternative, notably the following text from RFC2046 > [2]: > > "THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each > part of a "multipart/alternative" entity represents the same > data, but the mappings between the two are not necessarily > without information loss. For example, information is lost > when translating ODA to PostScript or plain text. It is > recommended that each part should have a different Content-ID > value in the case where the information content of the two > parts is not identical." > > I'd also like to see an example of Multipart/Alternative for the > MESSAGE message (with text/plain and text/html for example). I have not copy/pasted the text above, but I have included all of it rephrasing it. > > - I believe that the following text in section 4 is not strong enough: > > If a UAS does not support multipart bodies and receives one, the UAS > SHOULD return a 415 (Unsupported Media Type) response. > > Instead, it should read as follows: > > If a UAS does not support multipart bodies and receives one, the UAS > MUST return a 415 (Unsupported Media Type) response, and it MUST > return a list of acceptable formats as specificed in > [RFC3261]/21.4.13. When it comes to response generation, I always use SHOULD because a request may cause other error, apart from the ones we are defining here, and the UAS may need to return a different status code. That's why I do not use MUST in this case. In any event, I have added more text stressing the importance of this. > > I believe this is in line with RFC 3261/8.2.3. I will point out that > we have found in the field that if a UAS does NOT send a 415 and just > "ignores" the Multipart body altogether, what happens is that the > receiver of the > INVITE interprets the INVITE as having NO initial Offer, and sends an > an > Offer of it's own in the 200/18X. This is interpreted by the sender of > the > INVITE as an Answer, resulting in all hell breaking loose. Yes, this is really bad. I have added text stressing the importance of being able to produce error responses (Section 3.3). Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun May 27 15:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOqp-0001Ka-KI; Sun, 27 May 2007 15:56:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsOqo-0001JD-63 for sip-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 15:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsOqn-0001J5-Sc for sip@ietf.org; Sun, 27 May 2007 15:56:25 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsOqn-0000RQ-4v for sip@ietf.org; Sun, 27 May 2007 15:56:25 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5D32E2016E; Sun, 27 May 2007 21:56:24 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-4a-4659e26873e4 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 38110200B1; Sun, 27 May 2007 21:56:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:56:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 May 2007 21:56:23 +0200 Received: from [131.160.126.28] (rvi2-126-28.lmf.ericsson.se [131.160.126.28]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3B7682467; Sun, 27 May 2007 22:56:23 +0300 (EEST) Message-ID: <4659E265.9000507@ericsson.com> Date: Sun, 27 May 2007 22:56:21 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Sip] RE: I-D ACTION:draft-camarillo-sip-body-handling-00.txt References: <0D5F89FAC29E2C41B98A6A762007F5D012F0CD@GBNTHT12009MSX.gb002.siemens.net> <46559AE7.4060408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2007 19:56:23.0435 (UTC) FILETIME=[1A426DB0:01C7A099] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: SIP IETF , Paul Kyzivat , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Section 4.1 of the new revision below explains how to set the handling parameter: http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt We could add a sentence saying that UAs MUST support the handling parameter to the draft somewhere. Do we know of any implementation that implements MIME but does not implement this parameter? If there are no such implementations, we could be fine with just explicitly mandating its support from now on. Cheers, Gonzalo James M. Polk wrote: > At 09:02 AM 5/24/2007, Paul Kyzivat wrote: >> Elwell, John wrote: >>> Gonzalo, >>> Concerning the handling parameter, there is no normative statement in >>> RFC 3261 mandating that this be supported, as far as I can see. The only >>> normative language seems to be "If the handling parameter is missing, >>> the value "required" SHOULD be assumed." There is no normative statement >>> concerning what to do if it is present. Therefore any UA that inserts >>> handling=optional should not rely on this being taken account of by the >>> peer UA. >> >> Things are a bit messed up wrt this header: >> >> - 3261 section 20.11 says: "This SIP header field extends the MIME >> Content-Type (RFC 2183 [18])." But RFC 2183 is about >> Content-Disposition, so there is clearly a typo here. >> >> - From reading that section you might think that 3261 invented the >> handling parameter. It isn't defined in 2183, but it is defined >> in 3204 which was published prior to 3261. That does have normative >> statements about how the parameter is to be processed. So 3261 >> should have referenced that. >> >> I don't know how we are going to dig ourselves out of this hole. > > how about write a quite Update to 3261 pointing to 3204 instead of 2183. > Then obsoleting this new Update with Gonzalo's ID (that clears the > handling parameter up)... > > just an (unusual) thought (to a non-straightforward problem) > >> I suppose the usual answer is a new option tag. >> >> Paul >> >>> John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 01:05:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsXQE-0005JX-D5; Mon, 28 May 2007 01:05:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsXQD-0005JS-Ml for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 01:05:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsXQD-0005JK-Cl for sip@ietf.org; Mon, 28 May 2007 01:05:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsXQA-0004x8-TA for sip@ietf.org; Mon, 28 May 2007 01:05:33 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2007 01:05:31 -0400 X-IronPort-AV: i="4.14,585,1170651600"; d="scan'208"; a="61322983:sNHT50769790" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4S55U7U013017; Mon, 28 May 2007 01:05:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4S55LBi000682; Mon, 28 May 2007 05:05: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.1830); Mon, 28 May 2007 01:05:24 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 01:05:24 -0400 Message-ID: <465A6313.4030304@cisco.com> Date: Mon, 28 May 2007 01:05:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> In-Reply-To: <4659D9FA.70501@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2007 05:05:24.0589 (UTC) FILETIME=[CCB7A1D0:01C7A0E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4488; t=1180328730; x=1181192730; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=OynW5VKHXZqdAD3DQy9siJ4GRok8WorGfo0tsm25kMg=; b=gjyBre8lJmLVRCXaJk7ns/sY/GoHTYtVB9SsQLnwGJFbOZxXOXPWqliEJ1lm2eJFiWb4sRns 7eaUI2ujMMu2980t4Nheq+643KTpVAdulbs+oSorrFpJtVZvXlSod2BI; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo - comments inline. This is looking good. Paul Gonzalo Camarillo wrote: > Hi Paul, > > thanks for your comments. Answers inline: > > Paul Kyzivat wrote: >> Gonzalo, >> >> Thank you for doing this. It is a great start. I largely agree with >> what you have written. >> >> One specific comment about the draft: >> >> - Open issue in section 3: perhaps a new Reason code, to be used >> with a 415 response would be adequate. > > what do you mean by a reason code? Do you mean a Warning code?... > because Reason header fields are not allowed in responses. Never mind. I just wasn't thinking. > I have added more structure to the draft (i.e., a few new sections) that > I believe make it easier to read. You can fetch a working version from: > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt I believe you have covered my concerns. I've been thinking if there are other similar issues regarding references to body parts. I think another is that it can be possible for a reference to be present in a body part. (For example if one body part is an application/sipfrag.) Potentially the reference could then be in an optional part that is not understood by the recipient. Again, we wouldn't want processing to depend on whether a reference was processed or not. I'm not convinced there are any cases where this can be a real issue. It wouldn't be if the referenced body part were "within" the body part containing the reference. I think the sipfrag case would always fall into this category. I don't have any other examples in mind, so maybe this isn't really an issue. I'd just rather find any now rather than later. Can anybody else think of anything in this category? (Or do I have a monopoly on that job?) Re Issues: > OPEN ISSUE 1: do we need to say something about other types? Related > (rfc2387), parallel, digest, external-body. I don't know much about these. I quickly scanned 2387 and see that it has some special rules re processing Content-Disposition of the contained (related) parts. I *think* those are consistent with what we are doing. > OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/ > alternative', but is this valid generally with any content type? > Would it be possible to provide two alternative body parts using the > same format and, thus, the same content type but in, say, different > languages? Its my understanding that the distinction is based on which can be understood, relative to Content-Type. It isn't apparent to me that making this decision based on other attributes is valid. For one thing the parts are supposed to be ordered by increasing richness. If they differed by language this wouldn't be true. So I think what you have is ok. > OPEN ISSUE 3: do we need to talk about encrypted body parts? ??? > OPEN ISSUE 4: the handling parameter is a Content-Disposition > parameter. Therefore, in order to set the handling parameter, it is > necessary to provide the 'multipart' body with a disposition type. > Otherwise, its disposition type would be, by default, render. Which > disposition type shall we use for 'multipart/mixed' bodies? Shall we > create a new disposition type for this purpose? I think we need a new disposition type. I also think we should specify that this new one is the default for bodies of multipart/* content-type. That should fix up most examples and prior use, which afaict have not specified a content-disposition. > OPEN ISSUE 5: we could define a new response code (Content or > Disposition Type not Supported in this Context) to report known > content and disposition types appearing in an unsupported context in > order to be more explicit than always using 415. It would avoid > receiving a 415 response with an Accept header field containing all > the content types used in the request. How useful would this really > be? I'm inclined to say yes for completeness. But I don't expect to see any implementations using this the change their behavior at runtime. Another thing in Section 3: You have used SHOULD in this section. I thought we wanted to change this to MUST. Did we? There are also a couple of typos in Section 3: s/extensions relay on them/extensions rely on them/ s/miltipart/multipart/ That's it for now, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 03:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZIO-0006ma-Mk; Mon, 28 May 2007 03:05:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsZIN-0006l6-Eg for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 03:05:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZIN-0006ky-4y for sip@ietf.org; Mon, 28 May 2007 03:05:35 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsZIL-0007MT-NZ for sip@ietf.org; Mon, 28 May 2007 03:05:35 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2698020529 for ; Mon, 28 May 2007 09:05:33 +0200 (CEST) X-AuditID: c1b4fb3c-aacefbb0000073d5-07-465a7f3d083b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1AA4A203FB for ; Mon, 28 May 2007 09:05:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 09:05:32 +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, 28 May 2007 09:05:31 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: Alternative and identical Content-Types thread-index: Aceg9pSceHh6/9mnS66/zBPVezlLfQ== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 28 May 2007 07:05:32.0856 (UTC) FILETIME=[952DE380:01C7A0F6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: Alternative and identical Content-Types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Gonzalo's draft say that, when multipart/alternative is used, different body parts can not have the same content type. Below are a couple of use-cases where the same content type is used, and which may still be feasible for alternative: 1. =20 Let's assume I have two HTML bodies. They both contain the same=20 information, but one is "text friendly", while the other contains=20 pictures etc. Now, is that alternative or mixed(or parallel)? =20 2. =20 Let's assume I have the same information, but in different languages -=20 ie the Content-Language values are different. Is that alternative or=20 Mixed(or parallel)? =20 Now, we may not have the expertise to determine whether alternative is allowed or not in these cases. But, if the think there could be cases where the same content type would be used for alternative, we need to allow it. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 03:16:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZT0-0001fx-LI; Mon, 28 May 2007 03:16:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsZSy-0001fm-Vr for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 03:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsZSy-0001eB-Hp for sip@ietf.org; Mon, 28 May 2007 03:16:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsZSy-0008Ed-2M for sip@ietf.org; Mon, 28 May 2007 03:16:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8900B20FA5 for ; Mon, 28 May 2007 09:16:31 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-e8-465a81cfaf3d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 73D33204BF for ; Mon, 28 May 2007 09: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.1830); Mon, 28 May 2007 09:16:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 May 2007 09:16:30 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: Nested bodies with option-tag? thread-index: Aceg+B07PiGjGQNSQgO7ayQN6jGF/g== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 28 May 2007 07:16:31.0226 (UTC) FILETIME=[1D992DA0:01C7A0F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: Nested bodies with option-tag? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195297092==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1195297092== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A0F8.1D4EDA98" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A0F8.1D4EDA98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Gonzalo's draft describes a use-case where nested multipart bodies may be used. >From the implementation community we know that multipart is not widely supported - which is the reason the draft was put together in the first place. And, when looking at the implementations that actually do support multipart, I have one seen one or two that actually supports nested bodies. I wonder whether we should define an option-tag for the support of nested bodies. Considering the limited support of non-nested multipart, and the fact that it is still probably going to take a while before we really needed nested multiparts (read: before we will have an alternative to SDP), simply saying that entities MUST also support nested multiparts may not have the real-life effect we wish (read: people will not implement it no matter what the spec says), and we will not get rid of the interop problems.=20 I think it's a big step forward if we manage to get people to implement support of non-nested multipart bodies... Comments? Regards, Christer ------_=_NextPart_001_01C7A0F8.1D4EDA98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME: Nested bodies with option-tag?

Hi,

Gonzalo's draft describes a use-case = where nested multipart bodies may be used.

From the implementation community we = know that multipart is not widely supported - which is the reason the = draft was put together in the first place.

And, when looking at the = implementations that actually do support multipart, I have one seen one = or two that actually supports nested bodies.


I wonder whether we should define an = option-tag for the support of nested bodies. Considering the limited = support of non-nested multipart, and the fact that it is still probably = going to take a while before we really needed nested multiparts (read: = before we will have an alternative to SDP), simply saying that entities = MUST also support nested multiparts may not have the real-life effect we = wish (read: people will not implement it no matter what the spec says), = and we will not get rid of the interop problems.

I think it's a big step forward if we = manage to get people to implement support of non-nested multipart = bodies...

Comments?

Regards,

Christer

------_=_NextPart_001_01C7A0F8.1D4EDA98-- --===============1195297092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1195297092==-- From sip-bounces@ietf.org Mon May 28 03:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsa6s-0005L3-BI; Mon, 28 May 2007 03:57:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsa6q-0005Kp-Bd for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 03:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsa6p-0005Ja-Bf for sip@ietf.org; Mon, 28 May 2007 03:57:43 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsa6o-0006oT-Ko for sip@ietf.org; Mon, 28 May 2007 03:57:43 -0400 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, 28 May 2007 10:58:29 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0495C0AD@IsrExch01.israel.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceg/fpTq7HWxiTqReuw0BP532rq6Q== From: "Even, Roni" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip-chairs@tools.ietf.org, volkerh@bell-labs.com Subject: [Sip] Review of draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, The draft is basically ready for publication but I would like to see = some clarifications in it. 1. The draft explains describes two mechanisms the session independent = and the session dependent policies. I did not see what the relationship = between them if any is. I think that at least the draft should say that = they can be implemented independently if there are no other = recommendations. 2. Section 3.2 describes how a UA discovers the policy servers for = session independent policies based on the configuration framework = ua-profile.=20 "ua-profile" event package [4] provides a mechanism to discover policy servers in the local network and the home domain. The "local- network" profile-type enables a UA to discover a policy server in the local domain. The "user" profile type enables the discovery of a policy server in the home domain. A UA compliant to this specification SHOULD attempt to discover and subscribe to the policy servers in these two domains" The configuration framework does not specify the profile data which is = out of scope. So what is the meaning of this section - is this one way to find the = policy server or do you suggest that if you want to have session = independent policies you should have the policy servers defined in the = profile data but then how does a UA identify it in the profile data, is = it by name? I think this needs more clarification. 3. In section 4.2 " Endpoints set up a separate policy channel to each policy server and can specifically decide which information they want to disclose to which policy server" How does this work with the trust model between the UA and the proxy. = The UA claimed that it got the policy from the proxy but from this = sentence you can assume that the UA got the policy only to what it = asked. I think that the UA need to include in document sent to the proxy = all the information it can map from SDP. =20 4. In section 4.4.2 what will be the proxy behavior if it sends the = Invite with the policy server URI to an endpoint who do not support = session policy. The EP can ignore the request and respond 200 that will = not include the support for the session policy. What will the proxy do = or is it left to local implementation. 5. In section 4.4.6 in the note " If, however, a policy server cannot respond with a policy right away, it may return a policy that temporarily denies the session and update this policy as the actual policy decision becomes available" I am not sure how does that work, what will the UA do in this case. Will = it continue with the call without any media sessions? Typo In section 4.4.3 third line should be field and not filed=20 Roni Even _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 03:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsa7J-0005cc-Ld; Mon, 28 May 2007 03:58:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsa7I-0005c4-1s for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 03:58:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsa7H-0005bw-NT for sip@ietf.org; Mon, 28 May 2007 03:58:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsa7F-0006zQ-N3 for sip@ietf.org; Mon, 28 May 2007 03:58:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0EFD420414; Mon, 28 May 2007 09:58:09 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-2e-465a8b90adc7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D97B32001A; Mon, 28 May 2007 09:58:08 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 09:58:08 +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 Subject: RE: [Sip] Support for Multipart/MIME - order of bodies Date: Mon, 28 May 2007 09:58:07 +0200 Message-ID: <7374777208BDC7449D5620EF942325670473A195@esealmw113.eemea.ericsson.se> In-Reply-To: <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - order of bodies thread-index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAOLNj2A= References: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "Francois Audet" , "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 28 May 2007 07:58:08.0640 (UTC) FILETIME=[EE2C5000:01C7A0FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, One question is when "parallel" should be used instead of "mixed". When mixed is used, the order of the bodies is significant, which is not the case for parallel. And, for ISUP or QSIG, is there a difference in which order the ISUP/QSIG and SDP bodies are presented? I know that support of ISUP/QSIG bodies are implemented using mixed, and I am not proposing to change that. But, I think the draft should maybe talk a little more about the differences between parallel and mixed. In most cases I guess it doesn't matter which one would use. At least I can't think of any SIP use-case where the order of the bodies would be significant. Regards, Christer =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 23. toukokuuta 2007 22:53 > To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF) > Cc: 'Paul Kyzivat'; sip@ietf.org; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME >=20 > Yes, I expect RFC3204's syntax and semantics work fine=20 > between two implementations that implement RFC3204. >=20 > My question if it the choice of multipart/mixed in RFC3204=20 > was correct or if multipart/related would have been more=20 > appropriate for RFC3204. I have this question because the=20 > QSIG (and ISUP) are directly related to the SDP, and the=20 > QSIG/ISUP data provides additional information about that=20 > outgoing PSTN call leg that assists it in being set up. >=20 > My underlying question is what guidance we want to provide=20 > for Gonzalo's document. If RFC3204's use of multipart/mixed=20 > is what we want to do in SIP when there are bodyparts that=20 > have a relationship with each other, then Gonzalo's document=20 > will need to discourage use of multipart/related. >=20 > -d=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, May 23, 2007 12:22 PM > > To: Dan Wing; Gonzalo Camarillo > > Cc: Paul Kyzivat; sip@ietf.org; Christer Holmberg (JO/LMF) > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > >=20 > > Hi Dan, > >=20 > > To answer your question about the Multipart usage for ISUP/QSIG=20 > > tunnelling. > >=20 > > No, it does not set-up two calls. It sets-up ONE call. > >=20 > > The SDP is mandatory. > >=20 > > The QSIG or ISUP is optional. If supported it provides additional=20 > > information for the softswitches for legacy PSTN interop or other=20 > > features. > > If not it should be safely ignored. > >=20 > > So 3204 operates exactly as it should. Works fine. Has been working=20 > > fine for years (except for implementations that have problems with=20 > > Multipart MIME, which has forced the use of B2BUA that=20 > strip off these=20 > > MIME bodies.) > >=20 > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: Wednesday, May 23, 2007 11:18 AM > > > > To: Gonzalo Camarillo > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > Holmberg (JO/LMF) > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > >=20 > > > > This is great Gonzallo. Thanks for doing this. > > > >=20 > > > > Here are some comments: > > > >=20 > > > > - In section 4, another example that I think you should=20 > list for=20 > > > > Multipart/Mixed is RFC 3204 which actually has examples of=20 > > > > INVITEs with Multipart/Mixed (one for SDP, the other for=20 > > > > QSIG/ISUP tunnelling). That spec also illustrates the content- > > > > disposition mechanism (i.e., "optional" for QSIG/ISUP). > > >=20 > > > I wasn't aware of that usage in RFC3204. In both section 4.1 and=20 > > > its example, though, I don't think it's using multipart/mixed=20 > > > correctly. Here is its example (section 4.1 is similar): > > >=20 > > > To illustrate the use of the 'application/QSIG' media=20 > type, below=20 > > > is > > > an INVITE message which has the originating SDP > > information and an > > > encapsulated QSIG SETUP message. > > >=20 > > > Note that the two payloads are demarcated by the > > boundary parameter > > > (specified in RFC 2046 [4]) which in the example has the value > > > "unique- boundary-1". This is part of the specification of MIME > > > multipart and is not related to the 'application/QSIG'=20 > > media type. > > >=20 > > > INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 > > > Via: SIP/2.0/UDP sc10.nortelnetworks.com > > > From: sip:14085655675@sc10.nortelnetworks.com > > > To: sip:14084955072@sc1.nortelnetworks.com > > > Call-ID: 1231999021712095500999@sc12.nortelnetworks.com > > > CSeq: 1234 INVITE > > > Contact: > > > Content-Length: 358 > > > Content-Type: multipart/mixed; = boundary=3Dunique-boundary-1 > > > MIME-Version: 1.0 > > >=20 > > > --unique-boundary-1 > > > Content-Type: application/SDP; charset=3DISO-10646 > > >=20 > > > v=3D0 > > > o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 > > > s=3DSDP seminar > > > c=3DIN IP4 MG141.nortelnetworks.com > > > t=3D 2873397496 2873404696 > > > m=3Daudio 9092 RTP/AVP 0 3 4 > > >=20 > > > --unique-boundary-1 > > > Content-type:application/QSIG; version=3Diso > > >=20 > > > 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 > > > 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 > > > --unique-boundary-1-- > > >=20 > > > Per the semantics of multipart/mixed, both of those bodies are=20 > > > interpreted by the recipient -- wouldn't that cause two=20 > calls to be=20 > > > set up? Or does the SDP describe the VoIP leg and the QSIG=20 > > > describes the PSTN leg? If the latter, I do feel=20 > multipart/related=20 > > > would have been a better choice. > > >=20 > > > [[As MIME parsers are supposed to interpret unrecognized > > > multipart/* as multipart/mixed, a MIME-compliant parser that=20 > > > currently has the RFC3204-described behavior=20 > should=20 > > > work correctly if it received a multipart/related instead of=20 > > > multipart/mixed.]] > > >=20 > > > > - I like your text on Multipart/Alternative. > > >=20 > > > Yes, that section is very well written and captures exactly the=20 > > > problem with multipart/alternative. > > >=20 > > > ... > > > > - I believe that the following text in section 4 is not > > > strong enough: > > > >=20 > > > > If a UAS does not support multipart bodies and > > receives one, the > > > > UAS > > > > SHOULD return a 415 (Unsupported Media Type) response. > > > >=20 > > > > Instead, it should read as follows: > > > >=20 > > > > If a UAS does not support multipart bodies and > > receives one, the > > > > UAS > > > > MUST return a 415 (Unsupported Media Type) response, > > and it MUST > > > > return a list of acceptable formats as specificed in=20 > > > > [RFC3261]/21.4.13. > > > >=20 > > > > I believe this is in line with RFC 3261/8.2.3. I will > > > point out that > > > > we have found in the field that if a UAS does NOT send a > > > > 415 and just > > > > "ignores" the Multipart body altogether, what happens > > is that the > > > > receiver of the > > > > INVITE interprets the INVITE as having NO initial Offer, > > > and sends > > > > an an > > > > Offer of it's own in the 200/18X. This is interpreted by > > > the sender > > > > of the > > > > INVITE as an Answer, resulting in all hell breaking loose. > > >=20 > > > That's awful. You could detect this situation by requiring the=20 > > > answerer to insert a reference to the Content-ID they're=20 > answering;=20 > > > if an ACK comes back without that Content-ID, you'll know you=20 > > > encountered such a defective implementation. > > >=20 > > > -d > > >=20 > > >=20 > > > =20 > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo=20 > [mailto:Gonzalo.Camarillo@ericsson.com] > > > > > Sent: Wednesday, May 23, 2007 01:24 > > > > > To: Audet, Francois (SC100:3055) > > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > > Holmberg (JO/LMF) > > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > I have taken a stab at writing a quick draft about both > > issues (I > > > > > agree it makes sense to tackle them in a single > > > document). Until it > > > > > appears in the archives, you can fetch it from: > > > > >=20 > > > > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > > > > andling-00.txt > > > > >=20 > > > > > I have marked a few open issues so that we can continue > > > discussions > > > > > around those on the list (this is, of course, just an initial=20 > > > > > draft). > > > > >=20 > > > > > Cheers, > > > > >=20 > > > > > Gonzalo > > > > >=20 > > > > >=20 > > > > > Francois Audet wrote: > > > > > > My preference is one document.=20 > > > > > >=20 > > > > > >> -----Original Message----- > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > >> Sent: Wednesday, May 16, 2007 05:18 > > > > > >> To: Gonzalo Camarillo > > > > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > > > > Wing; Christer > > > > > >> Holmberg (JO/LMF) > > > > > >> Subject: Re: [Sip] Support for Multipart/MIME > > > > > >> > > > > > >> Hi Gonzalo, > > > > > >> > > > > > >> I guess the question is whether we want to write a=20 > document=20 > > > > > >> specifically focused on Content-Disposition, or if we want > > > > > to combine > > > > > >> work on that with work on specifying use of multipart. > > > > > >> > > > > > >> They aren't the same thing, but content-disposition > > > becomes more > > > > > >> significant when there are multiple body parts, so > > > there is some > > > > > >> justification for combining the work. > > > > > >> > > > > > >> Paul > > > > > >> > > > > > >> Gonzalo Camarillo wrote: > > > > > >>> Hi, > > > > > >>> > > > > > >>> yes, Paul and I talked about writing a draft to clarify a > > > > > >> few issues > > > > > >>> that relate to content dispositions in SIP a while ago. We > > > > > >> were quite > > > > > >>> busy at that point and did not have time to write it, but > > > > > >> maybe it is > > > > > >>> time to do it now. > > > > > >>> > > > > > >>> Cheers, > > > > > >>> > > > > > >>> Gonzalo > > > > >=20 > > > > >=20 > > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 04:02:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsaAy-0007zy-PE; Mon, 28 May 2007 04:02:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsaAw-0007zp-Ra for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 04:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsaAw-0007zh-HI for sip@ietf.org; Mon, 28 May 2007 04:01:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsaAu-0007p8-Vd for sip@ietf.org; Mon, 28 May 2007 04:01:58 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 775DD205D3; Mon, 28 May 2007 10:01:56 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-0c-465a8c7405a3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E54120640; Mon, 28 May 2007 10:01:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 10:01: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 Subject: RE: [Sip] Support for Multipart/MIME Date: Mon, 28 May 2007 10:01:55 +0200 Message-ID: <7374777208BDC7449D5620EF942325670473A1D0@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1095509E@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME thread-index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAADEa9AAAIzN4AAAR+nAAOFi+yA= References: <1ECE0EB50388174790F9694F77522CCF10955027@zrc2hxm0.corp.nortel.com> <0bb501c79d78$6599e7d0$c6f0200a@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF1095509E@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg (JO/LMF)" To: "Francois Audet" , "Dan Wing" , "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 28 May 2007 08:01:56.0076 (UTC) FILETIME=[75BC4AC0:01C7A0FE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I agree with Francois. You can send the QSIG/ISUP without SDP, and as far as the information itself is concerned, I don't think the QSIG/ISUP and SDP is related. So, I don't think mixed is a misstake. One question (as I wrote in anther mail) is whether parallel would also be feasible. Regards, Christer=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 23. toukokuuta 2007 23:37 > To: Dan Wing; Gonzalo Camarillo (JO/LMF) > Cc: Paul Kyzivat; sip@ietf.org; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME >=20 > =20 > > In RFC3204, the QSIG or ISUP parts do not appear to have=20 > any meaning=20 > > without the SDP. Or do they? For example, is it=20 > meaningful for me to=20 > > send an INVITE that has only the QSIG part (and no SDP)? >=20 > Sure: it's just a delayed offer answer.=20 >=20 > > > (And really, it's way too late to change 3204). > >=20 > > Even if consensus were to be formed that there was a mistake?=20 > > Obviously no such consensus has been formed, but I would=20 > like to have=20 > > the discussion. >=20 > I really don't think it's a mistake. >=20 > > If we do consider it acceptable to change RFC3261's requirements=20 > > around MIME multipart support, I suggest it is reasonable=20 > to analyze=20 > > what we may have done wrong elsewhere around MIME with SIP. > >=20 > > > But, if I interpret your question in a broader sense, I=20 > guess, the=20 > > > question is "Do we need to say anything about > > multipart/related?". I > > > would extend it to parallel and digest... > >=20 > > And external-body, and all the other parts. Yes, that is my=20 > > underlying question in light of Gonzalo's document and=20 > Cullen's stated=20 > > desire for the SIP community to document multipart support. >=20 > Yeah, I think it would be worthwile to talk about it, but not=20 > in the context of 3204. >=20 > Frankly, what I think we should say is "RECOMMEND don't use=20 > unless some IETF RFC defines a use for them". >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 11:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsh9g-0007fi-VE; Mon, 28 May 2007 11:29:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsh9g-0007fd-97 for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 11:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsh9f-0007fV-Vh for sip@ietf.org; Mon, 28 May 2007 11:29:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsh9e-0003md-Ku for sip@ietf.org; Mon, 28 May 2007 11:29:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2007 11:29:06 -0400 X-IronPort-AV: i="4.14,587,1170651600"; d="scan'208"; a="61340271:sNHT46446982" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4SFT6vA017640; Mon, 28 May 2007 11:29:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4SFT1Bi026790; Mon, 28 May 2007 15:29:06 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.1830); Mon, 28 May 2007 11:29:04 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 11:29:04 -0400 Message-ID: <465AF53F.2050808@cisco.com> Date: Mon, 28 May 2007 11:29:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] MIME: Alternative and identical Content-Types References: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2007 15:29:04.0668 (UTC) FILETIME=[ECD28DC0:01C7A13C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1999; t=1180366146; x=1181230146; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20MIME=3A=20Alternative=20and=20identical=20Con tent-Types |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=PI5oXDHuzfxVrbJArxOlgI6FgvWr4tUB+TX1R3UgrLY=; b=Ws37Wq2I/lEcPw+mqHwVyieP4SxzBiQ+L60FHo/Hbi/g5vR+G/3LS/XsDAl7XtDckkngWWy8 TIlR+jeu6p8hWgBpUJGKGS4YCyJdGK3yc9713nBOI7Ue+39rPm00jH+y; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, As best I understand, multipart/alternative assumes that you either do or don't "support" a particular alternative, and that the alternatives are arranged from least-preferred to most-preferred by the sender. The recipient is supposed to use the most-preferred (as defined by the sender) that it "supports". I guess we could allow different attributes, besides content-type to be used to decide if a part is "supported", *if* we can come up with a well defined meaning for "supported". I guess this could work for content-language. But I don't know about the text-friendly vs image-containing html. Maybe, but it needs better definition. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > Gonzalo's draft say that, when multipart/alternative is used, different > body parts can not have the same content type. > > Below are a couple of use-cases where the same content type is used, and > which may still be feasible for alternative: > > 1. > > Let's assume I have two HTML bodies. They both contain the same > information, but one is "text friendly", while the other contains > pictures etc. Now, is that alternative or mixed(or parallel)? > > > 2. > > Let's assume I have the same information, but in different languages - > ie the Content-Language values are different. Is that alternative or > Mixed(or parallel)? > > > > Now, we may not have the expertise to determine whether alternative is > allowed or not in these cases. But, if the think there could be cases > where the same content type would be used for alternative, we need to > allow it. > > Regards, > > Christer > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 11:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshF2-0001Qx-72; Mon, 28 May 2007 11:34:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HshF0-0001PR-Cg for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 11:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshF0-0001PJ-33 for sip@ietf.org; Mon, 28 May 2007 11:34:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HshEz-0004T4-Na for sip@ietf.org; Mon, 28 May 2007 11:34:38 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 May 2007 08:34:37 -0700 X-IronPort-AV: i="4.14,587,1170662400"; d="scan'208"; a="158164925:sNHT44007840" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4SFYbG8024952; Mon, 28 May 2007 08:34:37 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4SFYV08018077; Mon, 28 May 2007 15:34:37 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.1830); Mon, 28 May 2007 11:34:32 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 11:34:32 -0400 Message-ID: <465AF687.6080209@cisco.com> Date: Mon, 28 May 2007 11:34:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2007 15:34:32.0378 (UTC) FILETIME=[B02721A0:01C7A13D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2053; t=1180366477; x=1181230477; c=relaxed/simple; s=sjdkim7002; 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[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20; bh=YQWfaZNWWniZGpJj9D4I9dEJZu+PgD16EEV35HjyAOw=; b=kD6YkWXWr/XuHmvDVzq3AcTHKjsadML/CBtHIchs4hUkSCpY+cajuf+Y70qrdHM2K2MITsUx 1VTBqdx6scg13n7JU6bjxymvRi0p+XNcqxD5IMrnHzq2pBGxlZYNjdPc; Authentication-Results: sj-dkim-7; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If we have a significant body of implementations that support un-nested multipart, but that don't support nested multipart, then maybe such a tag would be useful. But first we should probably try to understand the situation and choose the best migration approach. But I would hesitate to give *new* implementations the option to only support un-nested. If you are doing a new implementation you should implement nesting from the beginning. Paul Christer Holmberg (JO/LMF) wrote: > > Hi, > > Gonzalo's draft describes a use-case where nested multipart bodies may > be used. > > From the implementation community we know that multipart is not widely > supported - which is the reason the draft was put together in the first > place. > > And, when looking at the implementations that actually do support > multipart, I have one seen one or two that actually supports nested bodies. > > > I wonder whether we should define an option-tag for the support of > nested bodies. Considering the limited support of non-nested multipart, > and the fact that it is still probably going to take a while before we > really needed nested multiparts (read: before we will have an > alternative to SDP), simply saying that entities MUST also support > nested multiparts may not have the real-life effect we wish (read: > people will not implement it no matter what the spec says), and we will > not get rid of the interop problems. > > I think it's a big step forward if we manage to get people to implement > support of non-nested multipart bodies... > > Comments? > > Regards, > > Christer > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 13:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsigl-0003qs-BC; Mon, 28 May 2007 13:07:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsigj-0003qj-NR for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 13:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsigj-0003qb-Dd for sip@ietf.org; Mon, 28 May 2007 13:07:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsigf-000266-EW for sip@ietf.org; Mon, 28 May 2007 13:07:21 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6AAF221257; Mon, 28 May 2007 19:07:16 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-e6-465b0c44f844 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50C7820256; Mon, 28 May 2007 19:07:16 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 19:07: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, 28 May 2007 19:07:15 +0200 Message-ID: <6D34F0B7D5BCB246A42380744457CA36F766C2@esealmw107.eemea.ericsson.se> In-Reply-To: <464D516C.4010501@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your draft xcap-diff-event:Sending etag information in the Subscribe. Thread-Index: AceZG6UoLuO2NI1IRGKCfLHs2EI7EQDLLvHw References: <6D34F0B7D5BCB246A42380744457CA36E508B4@esealmw107.eemea.ericsson.se> <464D516C.4010501@nokia.com> From: "Anders Lindgren C (TN/EAB)" To: "Jari Urpalainen" X-OriginalArrivalTime: 28 May 2007 17:07:16.0052 (UTC) FILETIME=[A45C6940:01C7A14A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: sip@ietf.org Subject: [Sip] RE: Your draft xcap-diff-event:Sending etag information in the Subscribe. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello Jari, Thanks for your answers. I'm try to do my best to understand how your I-D together with other I-D's or RFC can be used to provide us with of methods to able to be use in a number of scenarios. I do also think that we must let implementers have a number of methods to select from in order to best solve found issues. This is list of some scenarios I see. 1) The number of documents that a client want to monitor is huge. Number of SIP sessions must be limited as it costs to refresh them over the air. =20 2) The documents to monitor belong to a number of users. The number of SIP sessions must be limited as it cost to refresh them over the air. ( e.g. a user is a member of many groups and is allowed to see the content of each group documents) 3) Fiber is used between a client and the network. Number of SIP sessions or number of bytes sent is not an issue 4) It exist large documents. Changes are normally small ( e.g. a resource list with 500 contacts and display name is changed or a contact is added once a week) 5) The client has to need to be able to present the difference between its cached version of a document and the latest document stored on the server to the client user. 6) The monitored XML node is large. Changes are normally done only to child element/attributes to the node ( e.g. a list element within a resource-list document. A diplay name of one of the contact is changed). Number of bytes sent between a server and a client is an issue. Some more questions: A) 1) is handle by your I-D as you can list a number of documents and directories related to the R-URI. 2) is not handled. Do you think your I-D can be combined with http://tools.ietf.org/html/draft-ietf-sip-uri-list-subscribe-01 to be able to use a exploder function in the network to have one Subscribe sessions for all possible documents independent upon owner? As I see it the parameter "path" is more or less replaced with the URI list in the body therefore "path" needs to optional and not mandatory in this case? B) As I see it a limited patch history function in the XCAP server can be useful to handle 4) and 5). As you did not like my idea to send the version information upstream via SIP, I have another idea and that is to make it possible for a XCAP client to via the XCAP send do a Conditional GET and if the etags are different receive a diff document instead of a full document if such patch history exists. My view is that it is better to keep a patch history on the server than keeping a copy of every version. I also know that in OMA it exists requirement to be able to provide a history of who and want certain clients added to the document and this is more or less a patch history plus an indication about who and when the patch was done. What's your view? C) 6) needs that it is possible also to send xml patches also when you subscribe for a XML node. My understanding of your I-D is that that is not supported. Is that true? Br Anders=20 -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 Sent: den 18 maj 2007 09:11 To: Anders Lindgren C (TN/EAB) Cc: sip@ietf.org Subject: Re: Your draft xcap-diff-event:Sending etag information in the Subscribe. ext Anders Lindgren C (TN/EAB) wrote: > > Hello Jari, > I have a comments/question related to how your draft=20 > _http://tools.ietf.org/wg/sip/draft-urpalainen-sip-xcap-diff-event-01. > txt_ can be applied in a environment limited bandwidth e.g. where the=20 > subscription is done over an air interface. > > As I see it an XCAP document can be quite large. It may also happen=20 > that the changes can be quite rare and not that big. > > A user can also have quite many documents that he/she wants to=20 > subscribe for. > My view is that the memory in a client is not a bottleneck today and=20 > therefore it is quite likely that it is possible that clients will=20 > keep a copy of needed XCAP documents. > > The method in the draft ( see 4.7) to limit air traffic is to use the=20 > "niemi-sip-subnot-etags" draft. That makes it possible to supress some > Notifies. > Although there are no examples, i'm proposing Suppress-Notify-If-Match:=20 * after the initial notification, if you need this re-subscription with aggregate mode. > > This method has one disadvantage and that is that it is based on one=20 > etag per subscription and therefore not that useful when we are=20 > subscribing for lots of documents in one Sunsbribe dialogue. The=20 > method is useful when nothing has changed, but not that useful for=20 > small changes to large documents as the client needs to do a XCAP GET=20 > in order to fetch the version that the server has. > it is useful to allow to suppress the notify, when you want to just send some rpc-commands to the other end. And certainly it doesn't do what you want, if it were to be used with content sync with several http resources. > > My proposal is to use a different method to limit the information sent > over the air. > The proposal is that if the client includes a body with all documents=20 > and etags it has, the Notifier shall respond with a Nofify that=20 > contains all XML patches needed to be able to patch the client's=20 > version of the documents to the same version as the server has > With http you can do instance manipulation (rfc3229). But it requires versioning support on the XCAP server, which is overkill for the problem at-hand, imo (). So sure you could add an even more sophisticated stuff with sip here by combining or listing locally already existing resources. So you could optimize this but you would add yet more complexity and "interesting"=20 error cases... Also if you had every resource in sync you would practically send the same information within subscribe body what you will receive now within the initial notify (and of course, upstream speed may be much slower than downstream). > If it is possible to send version information for all documents that=20 > the client has stored already in the first Subscribe, the Notifier can > use this information to start to send the XML patches to patch the=20 > client versions to the latest server versions (instead of sending only > the link to the documents ) if the server has such patches stored. > > If it can not provide the patches, it needs to send the link as today. > If the server has the same version as the client, the server can send=20 > the link with the etag just to confirm that it has the same version. > > Taking an example from OMA; the existing OMA-TS-XDM-Core (see=20 > _http://www.openmobilealliance.org/release_program/docs/CopyrightClick > = .asp?pck=3DXDM&file=3DV1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A= . > pdf_=20 > = .asp?pck=3DXDM&file=3DV1_0_1-20061128-A/OMA-TS-XDM_Core-V1_0_1-20061128-A= . > pdf> has an xml schema that it is possible to reuse for the version=20 > information from the client, (see > _http://www.openmobilealliance.org/tech/profiles/xdm_xcapDirectory-V1_ > 0_1.xsd_) as it contains per AUID the URIs for a document plus the=20 > etag. > > This proposal will introduce a requirement that the XCAP server needs=20 > to have a optional patch history function to support this function, if > not supported the server can do as in the existing draft. > > Comments? > > Regards > Anders > Still for newly created resources with rapid following changes the same aggregate problem will exist. thanks, Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 15:58:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HslMT-00067p-OR; Mon, 28 May 2007 15:58:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HslMS-00067g-NC for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 15:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HslMS-00067X-DP for sip@ietf.org; Mon, 28 May 2007 15:58:36 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HslMH-0000mo-Aj for sip@ietf.org; Mon, 28 May 2007 15:58:36 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070528195824b1600o0822e>; Mon, 28 May 2007 19:58:24 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4SJwN8t021474 for ; Mon, 28 May 2007 15:58:23 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4SJwNgD021470; Mon, 28 May 2007 15:58:23 -0400 Date: Mon, 28 May 2007 15:58:23 -0400 Message-Id: <200705281958.l4SJwNgD021470@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> (christer.holmberg@ericsson.com) Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg (JO/LMF)" I wonder whether we should define an option-tag for the support of nested bodies. I don't think there's a lot to be gained from defining such an option-tag. The sender should already be aware that there is a risk the recipient can't understand nested bodies, and have arranged for suitable fallbacks. Conversely, the recipient should (at least) be able to skip the nested multipart body part in the proper "I don't understand this body part" way. All an option-tag would do is allow the sender to not add a fallback. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 16:02:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HslQ9-0007tA-FV; Mon, 28 May 2007 16:02:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HslQ8-0007sw-2M for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 16:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HslQ7-0007so-P0 for sip@ietf.org; Mon, 28 May 2007 16:02:23 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HslPz-0001q2-1R for sip@ietf.org; Mon, 28 May 2007 16:02:23 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc11) with ESMTP id <20070528200212m11008qn1ae>; Mon, 28 May 2007 20:02:12 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4SK2B8t021748 for ; Mon, 28 May 2007 16:02:11 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4SK2BBk021744; Mon, 28 May 2007 16:02:11 -0400 Date: Mon, 28 May 2007 16:02:11 -0400 Message-Id: <200705282002.l4SK2BBk021744@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> (christer.holmberg@ericsson.com) Subject: Re: [Sip] MIME: Alternative and identical Content-Types References: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg (JO/LMF)" Gonzalo's draft say that, when multipart/alternative is used, different body parts can not have the same content type. Below are a couple of use-cases where the same content type is used, and which may still be feasible for alternative: You have a good point, though the use cases you've presented might be dubious. But I'd say that we don't want to *prescribe* that the alternative parts must be different (based on any particular attributes) in case some implementation decides to *depend* on that rule, and we later discover a use case that makes the rule disadvantageous. A better statement is that repeated content-types are likely to be due to an error in design on the sender's part, but they are allowed. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 16:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsljV-0000ya-Oi; Mon, 28 May 2007 16:22:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsljU-0000yV-Cn for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 16:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsljU-0000yN-3B for sip@ietf.org; Mon, 28 May 2007 16:22:24 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsljT-0006EG-9p for sip@ietf.org; Mon, 28 May 2007 16:22:24 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B069220482; Mon, 28 May 2007 22:22:22 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-0d-465b39feaeea Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 995A7203EE; Mon, 28 May 2007 22:22:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 22:22:22 +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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Mon, 28 May 2007 22:22:21 +0200 Message-ID: <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> In-Reply-To: <200705281958.l4SJwNgD021470@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: AcehYqOhrTHpm2i2TQ6nPXdytB0cDwAAi/BA References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> From: "Christer Holmberg (JO/LMF)" To: , X-OriginalArrivalTime: 28 May 2007 20:22:22.0131 (UTC) FILETIME=[E5BA5030:01C7A165] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >=20 > I wonder whether we should define an option-tag for the support of > nested bodies. >=20 >I don't think there's a lot to be gained from defining such=20 >an option-tag. The sender should already be aware that there=20 >is a risk the recipient can't understand nested bodies, and=20 >have arranged for suitable fallbacks. Conversely, the=20 >recipient should (at least) be able to skip the nested=20 >multipart body part in the proper "I don't understand this=20 >body part" way. All an option-tag would do is allow the=20 >sender to not add a fallback. In that case we need some specific text saying that if the receiver does not support nested multiparts it MUST do-this-and-do-that. Because, as I said earlier, I don't think we will achieve what we want by saying that one MUST be able to parse nested multiparts. It can be rather tricky to implement (depending on how the parser is implemented, though), and since there aren't really any use-cases out there yet I am pretty sure some people will choose not to implement it (and saying that people are not compliant in that case will not really help from an interop perspective). So, because of that I think it would be good not to mandate the support of nested multiparts, but to mandate appropriate behavior if not supported - just like in any other case when a MIME body contains an unsupported but required content type. Regards, Christer > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 17:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsmOo-0005va-2q; Mon, 28 May 2007 17:05:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsmOl-0005um-BR for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 17:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsmOl-0005uX-14 for sip@ietf.org; Mon, 28 May 2007 17:05:03 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsmOk-0006NW-Lt for sip@ietf.org; Mon, 28 May 2007 17:05:03 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 May 2007 17:05:02 -0400 X-IronPort-AV: i="4.14,587,1170651600"; d="scan'208"; a="61349993:sNHT46425236" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4SL52AR029308; Mon, 28 May 2007 17:05:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4SL52Be016843; Mon, 28 May 2007 21:05:02 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.1830); Mon, 28 May 2007 17:05:02 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 17:05:01 -0400 Message-ID: <465B43FD.8040904@cisco.com> Date: Mon, 28 May 2007 17:05:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 May 2007 21:05:01.0838 (UTC) FILETIME=[DB6E9AE0:01C7A16B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2653; t=1180386302; x=1181250302; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=iwwJ8CvVogAL8LEZhOmh9r4BwEjTWNWB4LGntTHg7j0=; b=Qmx8XhMKSmnH36xDW1vdtngvFhdukKD2RI2AaDo9OW9oUnzxXiOeS3PUawsjOmkDTE/+oaFN w338dn2nrNargfUiStVPUuOWsy9jTYABTVwLPvKkCEjBhgAlzjE1Oa3B; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org More or less repeating what I said before: I expect we do have to account in some way for implementations that have already been deployed, in absence of a clarifying document. Exactly how we deal with that is still TBD. But as we define what is required to support this in the future, I think there is *no* benefit to defining two levels of support - full and partial. Anybody that sets out to provide support for this document should be expected to do it all - its not that much harder. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > >> I wonder whether we should define an option-tag for the support of >> nested bodies. >> >> I don't think there's a lot to be gained from defining such >> an option-tag. The sender should already be aware that there >> is a risk the recipient can't understand nested bodies, and >> have arranged for suitable fallbacks. Conversely, the >> recipient should (at least) be able to skip the nested >> multipart body part in the proper "I don't understand this >> body part" way. All an option-tag would do is allow the >> sender to not add a fallback. > > In that case we need some specific text saying that if the receiver does > not support nested multiparts it MUST do-this-and-do-that. > > Because, as I said earlier, I don't think we will achieve what we want > by saying that one MUST be able to parse nested multiparts. It can be > rather tricky to implement (depending on how the parser is implemented, > though), and since there aren't really any use-cases out there yet I am > pretty sure some people will choose not to implement it (and saying that > people are not compliant in that case will not really help from an > interop perspective). So, because of that I think it would be good not > to mandate the support of nested multiparts, but to mandate appropriate > behavior if not supported - just like in any other case when a MIME body > contains an unsupported but required content type. > > Regards, > > Christer > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon May 28 17:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsmfG-0003hD-3t; Mon, 28 May 2007 17:22:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsmfF-0003gt-7T for sip-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 17:22:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsmfE-0003gk-Tt for sip@ietf.org; Mon, 28 May 2007 17:22:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsmfD-000254-9L for sip@ietf.org; Mon, 28 May 2007 17:22:04 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4SLLxM08655; Mon, 28 May 2007 21:21:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Support for Multipart/MIME - order of bodies Date: Mon, 28 May 2007 16:17:33 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF06F68C02@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF942325670473A195@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - order of bodies Thread-Index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAOLNj2AAG/rtEA== References: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> <7374777208BDC7449D5620EF942325670473A195@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg (JO/LMF)" , "Dan Wing" , "Gonzalo Camarillo (JO/LMF)" X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Personally, I think we should treat parallel just like mixed when received. And continue to use mixed for sending, at least for things that exist already (like QSIG/ISUP). I would be surprised if parallel was really used in the wild... But I do agree we could say something about it.=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, May 28, 2007 00:58 > To: Dan Wing; Audet, Francois (SC100:3055); Gonzalo Camarillo (JO/LMF) > Cc: Paul Kyzivat; sip@ietf.org > Subject: RE: [Sip] Support for Multipart/MIME - order of bodies >=20 >=20 > Hi, >=20 > One question is when "parallel" should be used instead of "mixed". >=20 > When mixed is used, the order of the bodies is significant,=20 > which is not the case for parallel. And, for ISUP or QSIG, is=20 > there a difference in which order the ISUP/QSIG and SDP=20 > bodies are presented? >=20 > I know that support of ISUP/QSIG bodies are implemented using=20 > mixed, and I am not proposing to change that. But, I think=20 > the draft should maybe talk a little more about the=20 > differences between parallel and mixed. >=20 > In most cases I guess it doesn't matter which one would use.=20 > At least I can't think of any SIP use-case where the order of=20 > the bodies would be significant. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 23. toukokuuta 2007 22:53 > > To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF) > > Cc: 'Paul Kyzivat'; sip@ietf.org; Christer Holmberg (JO/LMF) > > Subject: RE: [Sip] Support for Multipart/MIME > >=20 > > Yes, I expect RFC3204's syntax and semantics work fine between two=20 > > implementations that implement RFC3204. > >=20 > > My question if it the choice of multipart/mixed in RFC3204=20 > was correct=20 > > or if multipart/related would have been more appropriate=20 > for RFC3204. =20 > > I have this question because the QSIG (and ISUP) are=20 > directly related=20 > > to the SDP, and the QSIG/ISUP data provides additional information=20 > > about that outgoing PSTN call leg that assists it in being set up. > >=20 > > My underlying question is what guidance we want to provide for=20 > > Gonzalo's document. If RFC3204's use of multipart/mixed is what we=20 > > want to do in SIP when there are bodyparts that have a relationship=20 > > with each other, then Gonzalo's document will need to=20 > discourage use=20 > > of multipart/related. > >=20 > > -d > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Wednesday, May 23, 2007 12:22 PM > > > To: Dan Wing; Gonzalo Camarillo > > > Cc: Paul Kyzivat; sip@ietf.org; Christer Holmberg (JO/LMF) > > > Subject: RE: [Sip] Support for Multipart/MIME > > >=20 > > >=20 > > > Hi Dan, > > >=20 > > > To answer your question about the Multipart usage for ISUP/QSIG=20 > > > tunnelling. > > >=20 > > > No, it does not set-up two calls. It sets-up ONE call. > > >=20 > > > The SDP is mandatory. > > >=20 > > > The QSIG or ISUP is optional. If supported it provides additional=20 > > > information for the softswitches for legacy PSTN interop or other=20 > > > features. > > > If not it should be safely ignored. > > >=20 > > > So 3204 operates exactly as it should. Works fine. Has=20 > been working=20 > > > fine for years (except for implementations that have=20 > problems with=20 > > > Multipart MIME, which has forced the use of B2BUA that > > strip off these > > > MIME bodies.) > > >=20 > > > > > -----Original Message----- > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > Sent: Wednesday, May 23, 2007 11:18 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > > Holmberg (JO/LMF) > > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > >=20 > > > > > This is great Gonzallo. Thanks for doing this. > > > > >=20 > > > > > Here are some comments: > > > > >=20 > > > > > - In section 4, another example that I think you should > > list for > > > > > Multipart/Mixed is RFC 3204 which actually has examples of=20 > > > > > INVITEs with Multipart/Mixed (one for SDP, the other for=20 > > > > > QSIG/ISUP tunnelling). That spec also illustrates=20 > the content- > > > > > disposition mechanism (i.e., "optional" for QSIG/ISUP). > > > >=20 > > > > I wasn't aware of that usage in RFC3204. In both=20 > section 4.1 and=20 > > > > its example, though, I don't think it's using multipart/mixed=20 > > > > correctly. Here is its example (section 4.1 is similar): > > > >=20 > > > > To illustrate the use of the 'application/QSIG' media > > type, below > > > > is > > > > an INVITE message which has the originating SDP > > > information and an > > > > encapsulated QSIG SETUP message. > > > >=20 > > > > Note that the two payloads are demarcated by the > > > boundary parameter > > > > (specified in RFC 2046 [4]) which in the example has=20 > the value > > > > "unique- boundary-1". This is part of the=20 > specification of MIME > > > > multipart and is not related to the 'application/QSIG'=20 > > > media type. > > > >=20 > > > > INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 > > > > Via: SIP/2.0/UDP sc10.nortelnetworks.com > > > > From: sip:14085655675@sc10.nortelnetworks.com > > > > To: sip:14084955072@sc1.nortelnetworks.com > > > > Call-ID: 1231999021712095500999@sc12.nortelnetworks.com > > > > CSeq: 1234 INVITE > > > > Contact: > > > > Content-Length: 358 > > > > Content-Type: multipart/mixed;=20 > boundary=3Dunique-boundary-1 > > > > MIME-Version: 1.0 > > > >=20 > > > > --unique-boundary-1 > > > > Content-Type: application/SDP; charset=3DISO-10646 > > > >=20 > > > > v=3D0 > > > > o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 > > > > s=3DSDP seminar > > > > c=3DIN IP4 MG141.nortelnetworks.com > > > > t=3D 2873397496 2873404696 > > > > m=3Daudio 9092 RTP/AVP 0 3 4 > > > >=20 > > > > --unique-boundary-1 > > > > Content-type:application/QSIG; version=3Diso > > > >=20 > > > > 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 > > > > 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 > > > > --unique-boundary-1-- > > > >=20 > > > > Per the semantics of multipart/mixed, both of those bodies are=20 > > > > interpreted by the recipient -- wouldn't that cause two > > calls to be > > > > set up? Or does the SDP describe the VoIP leg and the QSIG=20 > > > > describes the PSTN leg? If the latter, I do feel > > multipart/related > > > > would have been a better choice. > > > >=20 > > > > [[As MIME parsers are supposed to interpret unrecognized > > > > multipart/* as multipart/mixed, a MIME-compliant parser that=20 > > > > currently has the RFC3204-described behavior > > should > > > > work correctly if it received a multipart/related instead of=20 > > > > multipart/mixed.]] > > > >=20 > > > > > - I like your text on Multipart/Alternative. > > > >=20 > > > > Yes, that section is very well written and captures exactly the=20 > > > > problem with multipart/alternative. > > > >=20 > > > > ... > > > > > - I believe that the following text in section 4 is not > > > > strong enough: > > > > >=20 > > > > > If a UAS does not support multipart bodies and > > > receives one, the > > > > > UAS > > > > > SHOULD return a 415 (Unsupported Media Type) response. > > > > >=20 > > > > > Instead, it should read as follows: > > > > >=20 > > > > > If a UAS does not support multipart bodies and > > > receives one, the > > > > > UAS > > > > > MUST return a 415 (Unsupported Media Type) response, > > > and it MUST > > > > > return a list of acceptable formats as specificed in=20 > > > > > [RFC3261]/21.4.13. > > > > >=20 > > > > > I believe this is in line with RFC 3261/8.2.3. I will > > > > point out that > > > > > we have found in the field that if a UAS does NOT send a > > > > > 415 and just > > > > > "ignores" the Multipart body altogether, what happens > > > is that the > > > > > receiver of the > > > > > INVITE interprets the INVITE as having NO initial Offer, > > > > and sends > > > > > an an > > > > > Offer of it's own in the 200/18X. This is interpreted by > > > > the sender > > > > > of the > > > > > INVITE as an Answer, resulting in all hell breaking loose. > > > >=20 > > > > That's awful. You could detect this situation by requiring the=20 > > > > answerer to insert a reference to the Content-ID they're > > answering; > > > > if an ACK comes back without that Content-ID, you'll know you=20 > > > > encountered such a defective implementation. > > > >=20 > > > > -d > > > >=20 > > > >=20 > > > > =20 > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@ericsson.com] > > > > > > Sent: Wednesday, May 23, 2007 01:24 > > > > > > To: Audet, Francois (SC100:3055) > > > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > > > Holmberg (JO/LMF) > > > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > I have taken a stab at writing a quick draft about both > > > issues (I > > > > > > agree it makes sense to tackle them in a single > > > > document). Until it > > > > > > appears in the archives, you can fetch it from: > > > > > >=20 > > > > > >=20 > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > > > > > andling-00.txt > > > > > >=20 > > > > > > I have marked a few open issues so that we can continue > > > > discussions > > > > > > around those on the list (this is, of course, just=20 > an initial=20 > > > > > > draft). > > > > > >=20 > > > > > > Cheers, > > > > > >=20 > > > > > > Gonzalo > > > > > >=20 > > > > > >=20 > > > > > > Francois Audet wrote: > > > > > > > My preference is one document.=20 > > > > > > >=20 > > > > > > >> -----Original Message----- > > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > >> Sent: Wednesday, May 16, 2007 05:18 > > > > > > >> To: Gonzalo Camarillo > > > > > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > > > > > Wing; Christer > > > > > > >> Holmberg (JO/LMF) > > > > > > >> Subject: Re: [Sip] Support for Multipart/MIME > > > > > > >> > > > > > > >> Hi Gonzalo, > > > > > > >> > > > > > > >> I guess the question is whether we want to write a > > document > > > > > > >> specifically focused on Content-Disposition, or=20 > if we want > > > > > > to combine > > > > > > >> work on that with work on specifying use of multipart. > > > > > > >> > > > > > > >> They aren't the same thing, but content-disposition > > > > becomes more > > > > > > >> significant when there are multiple body parts, so > > > > there is some > > > > > > >> justification for combining the work. > > > > > > >> > > > > > > >> Paul > > > > > > >> > > > > > > >> Gonzalo Camarillo wrote: > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> yes, Paul and I talked about writing a draft to=20 > clarify a > > > > > > >> few issues > > > > > > >>> that relate to content dispositions in SIP a=20 > while ago. We > > > > > > >> were quite > > > > > > >>> busy at that point and did not have time to=20 > write it, but > > > > > > >> maybe it is > > > > > > >>> time to do it now. > > > > > > >>> > > > > > > >>> Cheers, > > > > > > >>> > > > > > > >>> Gonzalo > > > > > >=20 > > > > > >=20 > > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 03:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsvos-0006Zz-TZ; Tue, 29 May 2007 03:08:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsvoq-0006Zm-Ms for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 03:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsvon-0006ZJ-5i for sip@ietf.org; Tue, 29 May 2007 03:08:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsvom-0005n7-EM for sip@ietf.org; Tue, 29 May 2007 03:08:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 723C6206F3; Tue, 29 May 2007 09:08:29 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-45-465bd16d5091 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 53F9E206B1; Tue, 29 May 2007 09:08:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 09:08:28 +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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Tue, 29 May 2007 09:08:28 +0200 Message-ID: <7374777208BDC7449D5620EF94232567047C91F4@esealmw113.eemea.ericsson.se> In-Reply-To: <465B43FD.8040904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceha+X/j8faXRtvSnC0DhUvQaBkjgAU0pyQ References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com><7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 29 May 2007 07:08:28.0755 (UTC) FILETIME=[286FB230:01C7A1C0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >More or less repeating what I said before: >=20 >I expect we do have to account in some way for=20 >implementations that have already been deployed, in absence=20 >of a clarifying document. Exactly how we deal with that is still TBD. >=20 >But as we define what is required to support this in the=20 >future, I think there is *no* benefit to defining two levels=20 >of support - full and partial. Anybody that sets out to=20 >provide support for this document should be expected to do it=20 >all - its not that much harder. I also think we should take into consideration what is already out there, and not suddenly make all those implementations "wrong" just because we are now adding lots of new MUSTs. I am pretty sure that most implementations today supporting multipart only support mixed, and non-nested bodies (maybe Robert has more correct information based on his SIPit work). So, when we think about nested bodies, non-mixed multiparts etc etc etc, we really need to think whether it's a need for it in SIP in the first place - at least without an option tag. Because, again, making a huge document which mandates people to implements lots of things, just because it can be done, will not help. People will not implement it, unless they see any need for it. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > >> I wonder whether we should define an option-tag for the=20 > support of > >> nested bodies. > >> > >> I don't think there's a lot to be gained from defining such an=20 > >> option-tag. The sender should already be aware that there=20 > is a risk=20 > >> the recipient can't understand nested bodies, and have=20 > arranged for=20 > >> suitable fallbacks. Conversely, the recipient should (at=20 > least) be=20 > >> able to skip the nested multipart body part in the proper "I don't=20 > >> understand this body part" way. All an option-tag would=20 > do is allow=20 > >> the sender to not add a fallback. > >=20 > > In that case we need some specific text saying that if the receiver=20 > > does not support nested multiparts it MUST do-this-and-do-that. > >=20 > > Because, as I said earlier, I don't think we will achieve=20 > what we want=20 > > by saying that one MUST be able to parse nested multiparts.=20 > It can be=20 > > rather tricky to implement (depending on how the parser is=20 > > implemented, though), and since there aren't really any=20 > use-cases out=20 > > there yet I am pretty sure some people will choose not to=20 > implement it=20 > > (and saying that people are not compliant in that case will=20 > not really=20 > > help from an interop perspective). So, because of that I think it=20 > > would be good not to mandate the support of nested=20 > multiparts, but to=20 > > mandate appropriate behavior if not supported - just like=20 > in any other=20 > > case when a MIME body contains an unsupported but required=20 > content type. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 03:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsvqH-0007Yy-3n; Tue, 29 May 2007 03:10:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HsvqF-0007YN-Kg for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 03:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsvqF-0007Y3-8m for sip@ietf.org; Tue, 29 May 2007 03:10:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsvqD-00062Q-9y for sip@ietf.org; Tue, 29 May 2007 03:10:03 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5DFD320FDD; Tue, 29 May 2007 09:10:00 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-e7-465bd1c8cebc Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 444A720F9D; Tue, 29 May 2007 09:10:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 09:09: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 Subject: RE: [Sip] Support for Multipart/MIME - order of bodies Date: Tue, 29 May 2007 09:09:59 +0200 Message-ID: <7374777208BDC7449D5620EF94232567047C9206@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF06F68C02@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - order of bodies thread-index: AcedE7xDnn/4S1ijTdWu/Bynue9sgwATc2swAAIrF/AAAPUqIAABB/4AAOLNj2AAG/rtEAAUuUhw References: <1ECE0EB50388174790F9694F77522CCF10954F55@zrc2hxm0.corp.nortel.com> <0b4401c79d73$e6fa1f20$c6f0200a@amer.cisco.com> <7374777208BDC7449D5620EF942325670473A195@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF06F68C02@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg (JO/LMF)" To: "Francois Audet" , "Dan Wing" , "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 29 May 2007 07:09:59.0806 (UTC) FILETIME=[5EB4F9E0:01C7A1C0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: sip@ietf.org, Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >Personally, I think we should treat parallel just like mixed=20 >when received. I agree.=20 And, maybe forbid the usage of parallel with SIP, unless we really can come up with a valid use-case where it is needed. Regards, Christer >And continue to use mixed for sending, at least for things=20 >that exist already (like QSIG/ISUP). >=20 >I would be surprised if parallel was really used in the wild... >=20 > But I do agree we could say something about it.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, May 28, 2007 00:58 > > To: Dan Wing; Audet, Francois (SC100:3055); Gonzalo=20 > Camarillo (JO/LMF) > > Cc: Paul Kyzivat; sip@ietf.org > > Subject: RE: [Sip] Support for Multipart/MIME - order of bodies > >=20 > >=20 > > Hi, > >=20 > > One question is when "parallel" should be used instead of "mixed". > >=20 > > When mixed is used, the order of the bodies is significant,=20 > which is=20 > > not the case for parallel. And, for ISUP or QSIG, is there a=20 > > difference in which order the ISUP/QSIG and SDP bodies are=20 > presented? > >=20 > > I know that support of ISUP/QSIG bodies are implemented=20 > using mixed,=20 > > and I am not proposing to change that. But, I think the=20 > draft should=20 > > maybe talk a little more about the differences between parallel and=20 > > mixed. > >=20 > > In most cases I guess it doesn't matter which one would use.=20 > > At least I can't think of any SIP use-case where the order of the=20 > > bodies would be significant. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: 23. toukokuuta 2007 22:53 > > > To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF) > > > Cc: 'Paul Kyzivat'; sip@ietf.org; Christer Holmberg (JO/LMF) > > > Subject: RE: [Sip] Support for Multipart/MIME > > >=20 > > > Yes, I expect RFC3204's syntax and semantics work fine=20 > between two=20 > > > implementations that implement RFC3204. > > >=20 > > > My question if it the choice of multipart/mixed in RFC3204 > > was correct > > > or if multipart/related would have been more appropriate > > for RFC3204. =20 > > > I have this question because the QSIG (and ISUP) are > > directly related > > > to the SDP, and the QSIG/ISUP data provides additional=20 > information=20 > > > about that outgoing PSTN call leg that assists it in being set up. > > >=20 > > > My underlying question is what guidance we want to provide for=20 > > > Gonzalo's document. If RFC3204's use of multipart/mixed=20 > is what we=20 > > > want to do in SIP when there are bodyparts that have a=20 > relationship=20 > > > with each other, then Gonzalo's document will need to > > discourage use > > > of multipart/related. > > >=20 > > > -d > > >=20 > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: Wednesday, May 23, 2007 12:22 PM > > > > To: Dan Wing; Gonzalo Camarillo > > > > Cc: Paul Kyzivat; sip@ietf.org; Christer Holmberg (JO/LMF) > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > >=20 > > > >=20 > > > > Hi Dan, > > > >=20 > > > > To answer your question about the Multipart usage for ISUP/QSIG=20 > > > > tunnelling. > > > >=20 > > > > No, it does not set-up two calls. It sets-up ONE call. > > > >=20 > > > > The SDP is mandatory. > > > >=20 > > > > The QSIG or ISUP is optional. If supported it provides=20 > additional=20 > > > > information for the softswitches for legacy PSTN=20 > interop or other=20 > > > > features. > > > > If not it should be safely ignored. > > > >=20 > > > > So 3204 operates exactly as it should. Works fine. Has > > been working > > > > fine for years (except for implementations that have > > problems with > > > > Multipart MIME, which has forced the use of B2BUA that > > > strip off these > > > > MIME bodies.) > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > > Sent: Wednesday, May 23, 2007 11:18 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > > > Holmberg (JO/LMF) > > > > > > Subject: RE: [Sip] Support for Multipart/MIME > > > > > >=20 > > > > > > This is great Gonzallo. Thanks for doing this. > > > > > >=20 > > > > > > Here are some comments: > > > > > >=20 > > > > > > - In section 4, another example that I think you should > > > list for > > > > > > Multipart/Mixed is RFC 3204 which actually has=20 > examples of=20 > > > > > > INVITEs with Multipart/Mixed (one for SDP, the other for=20 > > > > > > QSIG/ISUP tunnelling). That spec also illustrates > > the content- > > > > > > disposition mechanism (i.e., "optional" for QSIG/ISUP). > > > > >=20 > > > > > I wasn't aware of that usage in RFC3204. In both > > section 4.1 and > > > > > its example, though, I don't think it's using multipart/mixed=20 > > > > > correctly. Here is its example (section 4.1 is similar): > > > > >=20 > > > > > To illustrate the use of the 'application/QSIG' media > > > type, below > > > > > is > > > > > an INVITE message which has the originating SDP > > > > information and an > > > > > encapsulated QSIG SETUP message. > > > > >=20 > > > > > Note that the two payloads are demarcated by the > > > > boundary parameter > > > > > (specified in RFC 2046 [4]) which in the example has > > the value > > > > > "unique- boundary-1". This is part of the > > specification of MIME > > > > > multipart and is not related to the 'application/QSIG'=20 > > > > media type. > > > > >=20 > > > > > INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 > > > > > Via: SIP/2.0/UDP sc10.nortelnetworks.com > > > > > From: sip:14085655675@sc10.nortelnetworks.com > > > > > To: sip:14084955072@sc1.nortelnetworks.com > > > > > Call-ID:=20 > 1231999021712095500999@sc12.nortelnetworks.com > > > > > CSeq: 1234 INVITE > > > > > Contact: > > > > > Content-Length: 358 > > > > > Content-Type: multipart/mixed; > > boundary=3Dunique-boundary-1 > > > > > MIME-Version: 1.0 > > > > >=20 > > > > > --unique-boundary-1 > > > > > Content-Type: application/SDP; charset=3DISO-10646 > > > > >=20 > > > > > v=3D0 > > > > > o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4 > > > > > s=3DSDP seminar > > > > > c=3DIN IP4 MG141.nortelnetworks.com > > > > > t=3D 2873397496 2873404696 > > > > > m=3Daudio 9092 RTP/AVP 0 3 4 > > > > >=20 > > > > > --unique-boundary-1 > > > > > Content-type:application/QSIG; version=3Diso > > > > >=20 > > > > > 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 > > > > > 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 > > > > > --unique-boundary-1-- > > > > >=20 > > > > > Per the semantics of multipart/mixed, both of those=20 > bodies are=20 > > > > > interpreted by the recipient -- wouldn't that cause two > > > calls to be > > > > > set up? Or does the SDP describe the VoIP leg and the QSIG=20 > > > > > describes the PSTN leg? If the latter, I do feel > > > multipart/related > > > > > would have been a better choice. > > > > >=20 > > > > > [[As MIME parsers are supposed to interpret unrecognized > > > > > multipart/* as multipart/mixed, a MIME-compliant parser that=20 > > > > > currently has the RFC3204-described behavior > > > should > > > > > work correctly if it received a multipart/related instead of=20 > > > > > multipart/mixed.]] > > > > >=20 > > > > > > - I like your text on Multipart/Alternative. > > > > >=20 > > > > > Yes, that section is very well written and captures=20 > exactly the=20 > > > > > problem with multipart/alternative. > > > > >=20 > > > > > ... > > > > > > - I believe that the following text in section 4 is not > > > > > strong enough: > > > > > >=20 > > > > > > If a UAS does not support multipart bodies and > > > > receives one, the > > > > > > UAS > > > > > > SHOULD return a 415 (Unsupported Media Type) response. > > > > > >=20 > > > > > > Instead, it should read as follows: > > > > > >=20 > > > > > > If a UAS does not support multipart bodies and > > > > receives one, the > > > > > > UAS > > > > > > MUST return a 415 (Unsupported Media Type) response, > > > > and it MUST > > > > > > return a list of acceptable formats as specificed in=20 > > > > > > [RFC3261]/21.4.13. > > > > > >=20 > > > > > > I believe this is in line with RFC 3261/8.2.3. I will > > > > > point out that > > > > > > we have found in the field that if a UAS does NOT send a > > > > > > 415 and just > > > > > > "ignores" the Multipart body altogether, what happens > > > > is that the > > > > > > receiver of the > > > > > > INVITE interprets the INVITE as having NO initial Offer, > > > > > and sends > > > > > > an an > > > > > > Offer of it's own in the 200/18X. This is interpreted by > > > > > the sender > > > > > > of the > > > > > > INVITE as an Answer, resulting in all hell breaking loose. > > > > >=20 > > > > > That's awful. You could detect this situation by=20 > requiring the=20 > > > > > answerer to insert a reference to the Content-ID they're > > > answering; > > > > > if an ACK comes back without that Content-ID, you'll know you=20 > > > > > encountered such a defective implementation. > > > > >=20 > > > > > -d > > > > >=20 > > > > >=20 > > > > > =20 > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@ericsson.com] > > > > > > > Sent: Wednesday, May 23, 2007 01:24 > > > > > > > To: Audet, Francois (SC100:3055) > > > > > > > Cc: Paul Kyzivat; sip@ietf.org; Dan Wing; Christer > > > > > Holmberg (JO/LMF) > > > > > > > Subject: Re: [Sip] Support for Multipart/MIME > > > > > > >=20 > > > > > > > Hi, > > > > > > >=20 > > > > > > > I have taken a stab at writing a quick draft about both > > > > issues (I > > > > > > > agree it makes sense to tackle them in a single > > > > > document). Until it > > > > > > > appears in the archives, you can fetch it from: > > > > > > >=20 > > > > > > >=20 > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h > > > > > > > andling-00.txt > > > > > > >=20 > > > > > > > I have marked a few open issues so that we can continue > > > > > discussions > > > > > > > around those on the list (this is, of course, just > > an initial > > > > > > > draft). > > > > > > >=20 > > > > > > > Cheers, > > > > > > >=20 > > > > > > > Gonzalo > > > > > > >=20 > > > > > > >=20 > > > > > > > Francois Audet wrote: > > > > > > > > My preference is one document.=20 > > > > > > > >=20 > > > > > > > >> -----Original Message----- > > > > > > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > > > > >> Sent: Wednesday, May 16, 2007 05:18 > > > > > > > >> To: Gonzalo Camarillo > > > > > > > >> Cc: Audet, Francois (SC100:3055); sip@ietf.org; Dan > > > > > > Wing; Christer > > > > > > > >> Holmberg (JO/LMF) > > > > > > > >> Subject: Re: [Sip] Support for Multipart/MIME > > > > > > > >> > > > > > > > >> Hi Gonzalo, > > > > > > > >> > > > > > > > >> I guess the question is whether we want to write a > > > document > > > > > > > >> specifically focused on Content-Disposition, or > > if we want > > > > > > > to combine > > > > > > > >> work on that with work on specifying use of multipart. > > > > > > > >> > > > > > > > >> They aren't the same thing, but content-disposition > > > > > becomes more > > > > > > > >> significant when there are multiple body parts, so > > > > > there is some > > > > > > > >> justification for combining the work. > > > > > > > >> > > > > > > > >> Paul > > > > > > > >> > > > > > > > >> Gonzalo Camarillo wrote: > > > > > > > >>> Hi, > > > > > > > >>> > > > > > > > >>> yes, Paul and I talked about writing a draft to > > clarify a > > > > > > > >> few issues > > > > > > > >>> that relate to content dispositions in SIP a > > while ago. We > > > > > > > >> were quite > > > > > > > >>> busy at that point and did not have time to > > write it, but > > > > > > > >> maybe it is > > > > > > > >>> time to do it now. > > > > > > > >>> > > > > > > > >>> Cheers, > > > > > > > >>> > > > > > > > >>> Gonzalo > > > > > > >=20 > > > > > > >=20 > > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 04:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsx90-0008BQ-5d; Tue, 29 May 2007 04:33:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hsx8y-0008BC-Kf for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 04:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsx8x-0008Ay-VF for sip@ietf.org; Tue, 29 May 2007 04:33:27 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsx8v-0006q3-NC for sip@ietf.org; Tue, 29 May 2007 04:33:27 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F364C204C2; Tue, 29 May 2007 10:33:24 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-ee-465be5544b68 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C718D204B4; Tue, 29 May 2007 10:33:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 10:33:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 10:33:23 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E184223F6; Tue, 29 May 2007 11:33:23 +0300 (EEST) Message-ID: <465BE553.4010500@ericsson.com> Date: Tue, 29 May 2007 11:33:23 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> In-Reply-To: <465A6313.4030304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 08:33:23.0834 (UTC) FILETIME=[05570DA0:01C7A1CC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, I have addressed your comments and include them in revision 01 before submitting it to the IETF. I will now go ahead submit it so that it appears in the official repository. Until then, you can fetch it from the same link as before (reload the page if you downloaded it before): http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt inline: > I've been thinking if there are other similar issues regarding > references to body parts. I think another is that it can be possible for > a reference to be present in a body part. (For example if one body part > is an application/sipfrag.) Potentially the reference could then be in > an optional part that is not understood by the recipient. Again, we > wouldn't want processing to depend on whether a reference was processed > or not. > > I'm not convinced there are any cases where this can be a real issue. It > wouldn't be if the referenced body part were "within" the body part > containing the reference. I think the sipfrag case would always fall > into this category. I don't have any other examples in mind, so maybe > this isn't really an issue. I'd just rather find any now rather than > later. Can anybody else think of anything in this category? (Or do I > have a monopoly on that job?) I wrote the text thinking of that possibility, but now I have rephrased it so that it is even more explicit about the fact that references can be found in body parts. I have added the following text pointing to an example of such a case: "In another example, the extension for file transfer in SDP [I-D.ietf-mmusic-file-transfer-mech] places a Content-ID URL in a 'file-icon' SDP attribute. This Content-ID URL points to a body part whose disposition type is supposed to be 'icon'." I have also added the following new open issue about the need to parse all body parts before being able to process any of them: "4.2. Body Processing UAs process message bodies and body parts in the following way. On receiving a SIP message, if a body part is not referenced in any way (e.g., there are no header fields or other body parts with a Content-ID URL pointing to it), the UA processes the body part as indicated by its disposition type and the context in which the body part was received. OPEN ISSUE 4: this means that a UA would need to parse all body parts to find references between them before being able to fully process them. If we are OK with this, we need to include text here explaining it." > > Re Issues: > >> OPEN ISSUE 1: do we need to say something about other types? Related >> (rfc2387), parallel, digest, external-body. > > I don't know much about these. I quickly scanned 2387 and see that it > has some special rules re processing Content-Disposition of the > contained (related) parts. I *think* those are consistent with what we > are doing. I have added the following text to Section 5: "This specification recommends support for 'multipart/mixed' and 'multipart/alternative'. At present, there are no SIP extensions that use different 'multipart' subtypes such as parallel [RFC2046], digest [RFC2046], or related [RFC2387]. If such extensions were to be defined in the future, their authors would need to make sure (e.g., by using an option-tag or by other means) that entities receiving those 'multipart' subtypes were able to process them. As stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/ mixed'." >> OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/ >> alternative', but is this valid generally with any content type? >> Would it be possible to provide two alternative body parts using the >> same format and, thus, the same content type but in, say, different >> languages? > > Its my understanding that the distinction is based on which can be > understood, relative to Content-Type. It isn't apparent to me that > making this decision based on other attributes is valid. For one thing > the parts are supposed to be ordered by increasing richness. If they > differed by language this wouldn't be true. > > So I think what you have is ok. I double check with an email expert to make sure we get this right. >> OPEN ISSUE 3: do we need to talk about encrypted body parts? > > ??? Christer brought this one up. What did you have in mind? > >> OPEN ISSUE 4: the handling parameter is a Content-Disposition >> parameter. Therefore, in order to set the handling parameter, it is >> necessary to provide the 'multipart' body with a disposition type. >> Otherwise, its disposition type would be, by default, render. Which >> disposition type shall we use for 'multipart/mixed' bodies? Shall we >> create a new disposition type for this purpose? > > I think we need a new disposition type. I also think we should specify > that this new one is the default for bodies of multipart/* content-type. > That should fix up most examples and prior use, which afaict have not > specified a content-disposition. This is probably something email people did not face. I think it makes sense to define the new disposition type. >> OPEN ISSUE 5: we could define a new response code (Content or >> Disposition Type not Supported in this Context) to report known >> content and disposition types appearing in an unsupported context in >> order to be more explicit than always using 415. It would avoid >> receiving a 415 response with an Accept header field containing all >> the content types used in the request. How useful would this really >> be? > > I'm inclined to say yes for completeness. But I don't expect to see any > implementations using this the change their behavior at runtime. yes, I am leaning towards defining it as well. > Another thing in Section 3: You have used SHOULD in this section. I > thought we wanted to change this to MUST. Did we? You refer to the following statement, right? "In particular, UAs SHOULD support the 'multipart/mixed' and 'multipart/alternative' MIME types." If people agree that this should be a MUST, I will be happy to change it. > There are also a couple of typos in Section 3: > > s/extensions relay on them/extensions rely on them/ Fixed. > > s/miltipart/multipart/ Fixed. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 08:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0bR-0001Zl-0c; Tue, 29 May 2007 08:15:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht0bO-0001ZX-QB for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 08:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0bO-0001ZP-G7 for sip@ietf.org; Tue, 29 May 2007 08:15:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0bO-0000QY-7F for sip@ietf.org; Tue, 29 May 2007 08:15:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2007 08:15:02 -0400 X-IronPort-AV: i="4.14,588,1170651600"; d="scan'208"; a="122227638:sNHT46505198" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4TCF1Jo013357; Tue, 29 May 2007 08:15:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4TCEXBw004685; Tue, 29 May 2007 12:15: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.1830); Tue, 29 May 2007 08:14:55 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 08:14:55 -0400 Message-ID: <465C193E.7090805@cisco.com> Date: Tue, 29 May 2007 08:14:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] Support for Multipart/MIME References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> In-Reply-To: <465BE553.4010500@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 12:14:55.0458 (UTC) FILETIME=[F7C3EC20:01C7A1EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2247; t=1180440902; x=1181304902; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=qIjpkRZT5zhTxzYT31NfTaklF+Gcok4chMKTmFGUbtQ=; b=qAJckjalk1dNZuFMskJi/XLuUjOAnN/gVl5SoAoQC1+evM/rKVIHbjRP/li1DjUxD9i6ormv xU+BwGqQmQ8nO/Oay9MBEuGpy+uc4sreIOSzoRLenC5QZ05MbvbgiO39; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org, Francois Audet , Dan Wing , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo, This all sounds good. I haven't read the new version yet, but based on your description below I have no problems with this, except possibly one area in which I am uncertain and which I would like to discuss: Gonzalo Camarillo wrote: > "4.2. Body Processing > > UAs process message bodies and body parts in the following way. On > receiving a SIP message, if a body part is not referenced in any way > (e.g., there are no header fields or other body parts with a > Content-ID URL pointing to it), the UA processes the body part as > indicated by its disposition type and the context in which the body > part was received. > > OPEN ISSUE 4: this means that a UA would need to parse all body parts > to find references between them before being able to fully process > them. If we are OK with this, we need to include text here > explaining it." I think there is at least ambiguity about what it means to "process" a body part. If one body part has a reference to another body part, then some amount of processing is required to detect such a reference. There seems to be an implication that two-pass (or more) processing, such as is typically done in compilers, is expected. But given the variety of body types I think it will be difficult to define what may be processed in a first pass and what must be postponed to a second pass. Also, often people will want to use off-the-shelf packages to support certain body types, and those may not be so cooperative with this requirement. Also, whether we like it or not, there will be systems that are only interested in a subset of what is there. (For instance proxies that are interested in SDP for purpose of enabling access.) These will want to parse the minimum necessary to find what they are interested in. It would be best if we can figure out a way for this to work. Maybe it is that a UA needs to parse everything that is supported, but other nodes it passes through can be more selective. >>> OPEN ISSUE 3: do we need to talk about encrypted body parts? >> >> ??? > > Christer brought this one up. What did you have in mind? Nothing. I just don't know. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 08:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0mS-0006BI-Gg; Tue, 29 May 2007 08:26:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht0mQ-0006B3-SW for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 08:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0mQ-0006Au-Ir for sip@ietf.org; Tue, 29 May 2007 08:26:26 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0mP-00036Z-1s for sip@ietf.org; Tue, 29 May 2007 08:26:26 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9FDFF207F1; Tue, 29 May 2007 14:26:00 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-d2-465c1bd86d9f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8E7AC205D0; Tue, 29 May 2007 14:26:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 14:26: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 Subject: RE: [Sip] Support for Multipart/MIME - S/MIME Date: Tue, 29 May 2007 14:25:59 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704805A4C@esealmw113.eemea.ericsson.se> In-Reply-To: <465BE553.4010500@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - S/MIME thread-index: AcehzAiRiy7CWLMUTmGgkcVjixcDLgAICqLw References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" , "Paul Kyzivat" X-OriginalArrivalTime: 29 May 2007 12:26:00.0293 (UTC) FILETIME=[8409B150:01C7A1EC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sip@ietf.org, Francois Audet , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >>>OPEN ISSUE 3: do we need to talk about encrypted body parts? >>=20 >>??? >=20 >Christer brought this one up. What did you have in mind? I think it's worth adding a few words describing the behavior when receiving en encrypted body part which the receiver is not able to de-encrypt. I guess the behavior would be the same as when receiving an unsupported content type, so it would mostly be a clarification. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 08:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0v5-0002NM-Nz; Tue, 29 May 2007 08:35:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht0v4-0002NF-2S for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 08:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0v3-0002N6-Ov for sip@ietf.org; Tue, 29 May 2007 08:35:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0v3-0004jd-AU for sip@ietf.org; Tue, 29 May 2007 08:35:21 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BC07C2050E; Tue, 29 May 2007 14:35:20 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-52-465c1e08d286 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A0A88200D8; Tue, 29 May 2007 14:35:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 14:35: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 Subject: RE: [Sip] Support for Multipart/MIME - support of alternative Date: Tue, 29 May 2007 14:35:19 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> In-Reply-To: <465BE553.4010500@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - support of alternative thread-index: AcehzAiRiy7CWLMUTmGgkcVjixcDLgAIMMig References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" , "Paul Kyzivat" X-OriginalArrivalTime: 29 May 2007 12:35:20.0376 (UTC) FILETIME=[D1DF9380:01C7A1ED] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: sip@ietf.org, Francois Audet , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, >>>OPEN ISSUE 1: do we need to say something about other types? Related >>>(rfc2387), parallel, digest, external-body. >>=20 >>I don't know much about these. I quickly scanned 2387 and see that it=20 >>has some special rules re processing Content-Disposition of the=20 >>contained (related) parts. I *think* those are consistent=20 >>with what we are doing. >=20 >I have added the following text to Section 5: >=20 > "This specification recommends support for 'multipart/mixed' and > 'multipart/alternative'. At present, there are no SIP extensions > that use different 'multipart' subtypes such as parallel=20 > [RFC2046], digest [RFC2046], or related [RFC2387]. If such=20 > extensions were to be defined in the future, their authors would need to make sure > (e.g., by using an option-tag or by other means) that entities > receiving those 'multipart' subtypes were able to process them. As > stated earlier, UAs treat unknown 'multipart' subtypes as=20 > 'multipart/mixed'." I think the text is good. But, I wonder whether we should alternative to the list of "different multipart subtypes". At present there are no SIP extensions using alternative either, so... =20 Or, at least we could leave support of alternative open for the moment, until we get more information about how it's supposed to be used in the first place (regarding identical content type values etc). >>>OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/ >>>alternative', but is this valid generally with any content type? >>>Would it be possible to provide two alternative body=20 >>>parts using the same format and, thus, the same content type but in,=20 >>>say, different languages? >>=20 >>Its my understanding that the distinction is based on which can be=20 >>understood, relative to Content-Type. It isn't apparent to me that=20 >>making this decision based on other attributes is valid.=20 >>For one thing the parts are supposed to be ordered by increasing=20 >>richness. If they differed by language this wouldn't be true. >>=20 >>So I think what you have is ok. >=20 >I double check with an email expert to make sure we get this right. >>Another thing in Section 3: You have used SHOULD in this section. I=20 >>thought we wanted to change this to MUST. Did we? >=20 >You refer to the following statement, right? >=20 > "In particular, UAs SHOULD support the 'multipart/mixed' > and 'multipart/alternative' MIME types." >=20 >If people agree that this should be a MUST, I will be happy=20 >to change it. Again, I think we should wait a little regarding alternative. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 08:43:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht12z-0006xp-MX; Tue, 29 May 2007 08:43:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht12y-0006xk-MZ for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 08:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht12y-0006xc-Cs for sip@ietf.org; Tue, 29 May 2007 08:43:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht12x-0005sQ-II for sip@ietf.org; Tue, 29 May 2007 08:43:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E95932102B; Tue, 29 May 2007 14:43:30 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-8c-465c1ff2671e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC3CD2105D; Tue, 29 May 2007 14:43:30 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 14:43:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 14:43:27 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C800623F6; Tue, 29 May 2007 15:43:27 +0300 (EEST) Message-ID: <465C1FEF.3030409@ericsson.com> Date: Tue, 29 May 2007 15:43:27 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME - support of alternative References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 12:43:27.0981 (UTC) FILETIME=[F48231D0:01C7A1EE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org, Paul Kyzivat , Francois Audet , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, we should be ready for a transition to a new session description protocol, which includes experimental networks using their own stuff, and people seem to agree that alternative is the way to go. That is why it would be great if we could mandate its support already now. The more we wait, the more trouble we could have in the future to use it. Cheers, Gonzalo Christer Holmberg (JO/LMF) wrote: > > Hi, > >>>> OPEN ISSUE 1: do we need to say something about other types? Related >>>> (rfc2387), parallel, digest, external-body. >>> I don't know much about these. I quickly scanned 2387 and see that it >>> has some special rules re processing Content-Disposition of the >>> contained (related) parts. I *think* those are consistent >>> with what we are doing. >> I have added the following text to Section 5: >> >> "This specification recommends support for 'multipart/mixed' and >> 'multipart/alternative'. At present, there are no SIP extensions >> that use different 'multipart' subtypes such as parallel >> [RFC2046], digest [RFC2046], or related [RFC2387]. If such >> extensions were to be defined in the future, their authors would > need to make sure >> (e.g., by using an option-tag or by other means) that entities >> receiving those 'multipart' subtypes were able to process them. As >> stated earlier, UAs treat unknown 'multipart' subtypes as >> 'multipart/mixed'." > > I think the text is good. > > But, I wonder whether we should alternative to the list of "different > multipart subtypes". At present there are no SIP extensions using > alternative either, so... > > Or, at least we could leave support of alternative open for the moment, > until we get more information about how it's supposed to be used in the > first place (regarding identical content type values etc). > > >>>> OPEN ISSUE 2: we know that we do not want two SDPs in a 'multipart/ >>>> alternative', but is this valid generally with any content type? >>>> Would it be possible to provide two alternative body >>>> parts using the same format and, thus, the same content type but in, >>>> say, different languages? >>> Its my understanding that the distinction is based on which can be >>> understood, relative to Content-Type. It isn't apparent to me that >>> making this decision based on other attributes is valid. >>> For one thing the parts are supposed to be ordered by increasing >>> richness. If they differed by language this wouldn't be true. >>> >>> So I think what you have is ok. >> I double check with an email expert to make sure we get this right. > > >>> Another thing in Section 3: You have used SHOULD in this section. I >>> thought we wanted to change this to MUST. Did we? >> You refer to the following statement, right? >> >> "In particular, UAs SHOULD support the 'multipart/mixed' >> and 'multipart/alternative' MIME types." >> >> If people agree that this should be a MUST, I will be happy >> to change it. > > Again, I think we should wait a little regarding alternative. > > Regards, > > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:06:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Oe-0001Uz-4b; Tue, 29 May 2007 09:05:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht1Oa-0001Ra-5P for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1OZ-0001RL-QT for sip@ietf.org; Tue, 29 May 2007 09:05:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1OY-0008Du-4x for sip@ietf.org; Tue, 29 May 2007 09:05:51 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7874C2045C; Tue, 29 May 2007 15:05:49 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-d2-465c252d63b9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 53C272015C; Tue, 29 May 2007 15:05:49 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 15:05:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 15:05:48 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7AAF526D5; Tue, 29 May 2007 16:05:48 +0300 (EEST) Message-ID: <465C252C.6030909@ericsson.com> Date: Tue, 29 May 2007 16:05:48 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> In-Reply-To: <465B43FD.8040904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 13:05:48.0515 (UTC) FILETIME=[13877330:01C7A1F2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, what I am hearing is that there are implementations out there that support multipart but not nested. Therefore, we need to decide two things: 1) do we want to have a MUST for multipart and a SHOULD for nested? I would say that we should have the same level (e.g., MUST, if we decided that MUST is appropriate) for both. 2) do we need a way for implementations that support multipart but not nested to be quickly updated to, at least, report that fact with an error response? This may make sense. Cheers, Gonzalo Paul Kyzivat wrote: > More or less repeating what I said before: > > I expect we do have to account in some way for implementations that have > already been deployed, in absence of a clarifying document. Exactly how > we deal with that is still TBD. > > But as we define what is required to support this in the future, I think > there is *no* benefit to defining two levels of support - full and > partial. Anybody that sets out to provide support for this document > should be expected to do it all - its not that much harder. > > Paul > > Christer Holmberg (JO/LMF) wrote: >> Hi, >>> I wonder whether we should define an option-tag for the support of >>> nested bodies. >>> >>> I don't think there's a lot to be gained from defining such an >>> option-tag. The sender should already be aware that there is a risk >>> the recipient can't understand nested bodies, and have arranged for >>> suitable fallbacks. Conversely, the recipient should (at least) be >>> able to skip the nested multipart body part in the proper "I don't >>> understand this body part" way. All an option-tag would do is allow >>> the sender to not add a fallback. >> >> In that case we need some specific text saying that if the receiver does >> not support nested multiparts it MUST do-this-and-do-that. >> >> Because, as I said earlier, I don't think we will achieve what we want >> by saying that one MUST be able to parse nested multiparts. It can be >> rather tricky to implement (depending on how the parser is implemented, >> though), and since there aren't really any use-cases out there yet I am >> pretty sure some people will choose not to implement it (and saying that >> people are not compliant in that case will not really help from an >> interop perspective). So, because of that I think it would be good not >> to mandate the support of nested multiparts, but to mandate appropriate >> behavior if not supported - just like in any other case when a MIME body >> contains an unsupported but required content type. >> >> Regards, >> >> Christer >> >> >> >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Qk-000422-Vf; Tue, 29 May 2007 09:08:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht1Qk-00041x-4t for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Qj-00041p-RH for sip@ietf.org; Tue, 29 May 2007 09:08:05 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1Qf-0000V9-7w for sip@ietf.org; Tue, 29 May 2007 09:08:05 -0400 Received: by an-out-0708.google.com with SMTP id c17so540868anc for ; Tue, 29 May 2007 06:07:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=d+TnAERpLAwbD0xefKiFhf1QoS4R5GXe9Ojy5oIaW9e68mAc7FJ6WDBDX/qNWetnlNB87rzAiPqhDKl478fW21exFs3uu80zG8iJS3wmKpd90DrHndRLfd2MlgGAVlyzCUoBfg2q9QvPNB/2L3Yo7+7nxpolOOtdB6g9dkFczUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=lSvb5ScdznQWrA1VzCLw+omTpq3ki+RSSGaMkaCG+5GtmLpMf4ATq53cd2H0MYU4tKOVh9r3pY4MixZrAMQSdolRTjYEduqOZpqXp/0HMvV4UOGgryNn2PSSVWXtvhHv2p1E2bLshNd6Xz1X28t/mRY8WNz4Amw5awRvMnKKHsQ= Received: by 10.101.1.13 with SMTP id d13mr5128046ani.1180444068494; Tue, 29 May 2007 06:07:48 -0700 (PDT) Received: by 10.100.154.16 with HTTP; Tue, 29 May 2007 06:07:48 -0700 (PDT) Message-ID: <3fe6b8640705290607w6d80ceabye0dcb9a329166403@mail.gmail.com> Date: Tue, 29 May 2007 18:37:48 +0530 From: "Malleswara Rao Ankem" To: "IETF SIP List" MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Sip] Deregistration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0417933023==" Errors-To: sip-bounces@ietf.org --===============0417933023== Content-Type: multipart/alternative; boundary="----=_Part_171622_10929840.1180444068395" ------=_Part_171622_10929840.1180444068395 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Section 10.2 of RFC 3261 indicates the following, "UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out." In Section 10.3, "REGISTER requests MUST be processed by a registrar in the order that they are received. REGISTER requests MUST also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. Each REGISTER message MUST be processed independently of any other registration or binding changes." In this scenario can the UA (which is operating on UDP transport) send a de-register request (to remove the binding) with the same call-id and Contact header but a incremented c-seq number, while a response for the "refresh" registration is still pending ? -Mallesh ------=_Part_171622_10929840.1180444068395 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
 Section 10.2 of RFC 3261 indicates the following,
"UAs MUST NOT send a new registration (that is, containing new Contact

header field values, as opposed to a retransmission) until they have

received a final response from the registrar for the previous one or

the previous REGISTER request has timed out."

In Section 10.3, "REGISTER requests MUST

be processed by a registrar in the order that they are received.

REGISTER requests MUST also be processed atomically, meaning that a

particular REGISTER request is either processed completely or not at

all. Each REGISTER message MUST be processed independently of any

other registration or binding changes."

In this scenario can the UA (which is operating on UDP transport) send a de-register request (to remove the binding) with the same call-id and Contact header but a incremented c-seq number, while a response for the "refresh" registration is still pending ?

-Mallesh

 

------=_Part_171622_10929840.1180444068395-- --===============0417933023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0417933023==-- From sip-bounces@ietf.org Tue May 29 09:42:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1y8-0004kp-31; Tue, 29 May 2007 09:42:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht1y6-0004kj-0F for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1y5-0004kb-L6 for sip@ietf.org; Tue, 29 May 2007 09:42:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1y4-0002LP-Up for sip@ietf.org; Tue, 29 May 2007 09:42:33 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 525E02075C; Tue, 29 May 2007 15:42:32 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-8e-465c2dc80e41 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 34E59203E7; Tue, 29 May 2007 15:42:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 15:42: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 Subject: RE: [Sip] Support for Multipart/MIME - support of alternative Date: Tue, 29 May 2007 15:42:31 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704805DD4@esealmw113.eemea.ericsson.se> In-Reply-To: <465C1FEF.3030409@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - support of alternative thread-index: Aceh7vTS+EAqx60uRBKw46SUlZJfsQAB2Wdg References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> <465C1FEF.3030409@ericsson.com> From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 29 May 2007 13:42:31.0768 (UTC) FILETIME=[34C52D80:01C7A1F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, Paul Kyzivat , Francois Audet , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >we should be ready for a transition to a new session=20 >description protocol, which includes experimental networks=20 >using their own stuff, and people seem to agree that=20 >alternative is the way to go. That is why it would be great=20 >if we could mandate its support already now. >=20 >The more we wait, the more trouble we could have in the=20 >future to use it. Yes. But, at the same time we need to try to be backward compatible, and take into consideration existing implementations which may support mixed but not alternative. If those implementations reject alternative I think our spec should not make them "not compliant". The same thing goes for nested bodies. The more we can "fit" the spec into what is already out there, the better. So, I don't mind to strongly recommend people to implement alternative, and give examples why it may be useful in the future, but at the same time I think we should also say that if the receiver does not support alternative a error response MUST be sent - in order to avoid cases e.g. described by Francois, where the receiver simply discard the multipart and continues the call setup. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > =20 > > Hi, > >=20 > >>>> OPEN ISSUE 1: do we need to say something about other types? =20 > >>>> Related (rfc2387), parallel, digest, external-body. > >>> I don't know much about these. I quickly scanned 2387 and=20 > see that=20 > >>> it has some special rules re processing=20 > Content-Disposition of the=20 > >>> contained (related) parts. I *think* those are consistent=20 > with what=20 > >>> we are doing. > >> I have added the following text to Section 5: > >> > >> "This specification recommends support for 'multipart/mixed' and > >> 'multipart/alternative'. At present, there are no SIP=20 > extensions > >> that use different 'multipart' subtypes such as parallel=20 > >> [RFC2046], digest [RFC2046], or related [RFC2387]. If such=20 > >> extensions were to be defined in the future, their authors would > > need to make sure > >> (e.g., by using an option-tag or by other means) that entities > >> receiving those 'multipart' subtypes were able to=20 > process them. As > >> stated earlier, UAs treat unknown 'multipart' subtypes as=20 > >> 'multipart/mixed'." > >=20 > > I think the text is good. > >=20 > > But, I wonder whether we should alternative to the list of=20 > "different=20 > > multipart subtypes". At present there are no SIP extensions using=20 > > alternative either, so... > > =20 > > Or, at least we could leave support of alternative open for the=20 > > moment, until we get more information about how it's supposed to be=20 > > used in the first place (regarding identical content type=20 > values etc). > >=20 > >=20 > >>>> OPEN ISSUE 2: we know that we do not want two SDPs in a=20 > 'multipart/=20 > >>>> alternative', but is this valid generally with any content type? > >>>> Would it be possible to provide two alternative body parts using=20 > >>>> the same format and, thus, the same content type but in, say,=20 > >>>> different languages? > >>> Its my understanding that the distinction is based on=20 > which can be=20 > >>> understood, relative to Content-Type. It isn't apparent=20 > to me that=20 > >>> making this decision based on other attributes is valid. > >>> For one thing the parts are supposed to be ordered by increasing=20 > >>> richness. If they differed by language this wouldn't be true. > >>> > >>> So I think what you have is ok. > >> I double check with an email expert to make sure we get this right. > >=20 > >=20 > >>> Another thing in Section 3: You have used SHOULD in this=20 > section. I=20 > >>> thought we wanted to change this to MUST. Did we? > >> You refer to the following statement, right? > >> > >> "In particular, UAs SHOULD support the 'multipart/mixed' > >> and 'multipart/alternative' MIME types." > >> > >> If people agree that this should be a MUST, I will be=20 > happy to change=20 > >> it. > >=20 > > Again, I think we should wait a little regarding alternative. > >=20 > > Regards, > >=20 > > Christer >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht20S-0006CL-K8; Tue, 29 May 2007 09:45:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht20Q-0006CG-OF for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht20Q-0006C8-EW for sip@ietf.org; Tue, 29 May 2007 09:44:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht20O-0002uK-0C for sip@ietf.org; Tue, 29 May 2007 09:44:58 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2007 09:44:56 -0400 X-IronPort-AV: i="4.14,588,1170651600"; d="scan'208"; a="122235157:sNHT50833058" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4TDit17029669; Tue, 29 May 2007 09:44:55 -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.12.10/8.12.6) with ESMTP id l4TDio5r021455; Tue, 29 May 2007 13:44:55 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.1830); Tue, 29 May 2007 09:44:43 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 09:44:43 -0400 Message-ID: <465C2E4A.2090208@cisco.com> Date: Tue, 29 May 2007 09:44:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> In-Reply-To: <465C252C.6030909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 13:44:43.0365 (UTC) FILETIME=[83354950:01C7A1F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5031; t=1180446295; x=1181310295; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=DTsf1ua1VAbjqfjrU/45Q3rVEvjZeDivFA+cnVORgCE=; b=rLOaVUPm/f1TjwHAxyBv4Is4kk0Kj9ZVhtSJ+PWlRyf0An71nMUyuAyovMbDkUHoIdc8wW2K S8kdAuU4U3/imZAv78RISvDqaNlQDRrJJQgg1suH1GsaOwTiLW+/g/vZ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gonzalo Camarillo wrote: > Hi, > > what I am hearing is that there are implementations out there that > support multipart but not nested. Therefore, we need to decide two things: > > 1) do we want to have a MUST for multipart and a SHOULD for nested? I > would say that we should have the same level (e.g., MUST, if we decided > that MUST is appropriate) for both. I think if we don't do this, we will simply be creating another problem such as the problem we have today with multipart. > 2) do we need a way for implementations that support multipart but not > nested to be quickly updated to, at least, report that fact with an > error response? This may make sense. This only makes sense if there is something that the sender can do about it. For instance today a 415 that indicates support for SDP but not for multipart tells a sender that used multipart with SDP and some optional parts to try again with just the SDP. So the question is: is there anything that the sender could do in this case. We already have a SHOULD strength requirement to not do gratuitous nesting. If that had been followed then the nesting must not be gratuitous, so what is the fallback strategy. Also, I think if we do a survey we are likely to find more restrictive limitations than just no nesting. For instance multipart may only work with certain contained body parts. I suspect it is a fools errand to attempt to describe the particular restrictions of a non-compliant implementation in the hopes that the sender will be able to craft an alternative form of request that is useful. For inadequate implementations I think we must focus on the installed base that must be coped with. In that regard, specifying something that the existing implementation must do, that it doesn't already do, makes little sense. Paul > Cheers, > > Gonzalo > > Paul Kyzivat wrote: >> More or less repeating what I said before: >> >> I expect we do have to account in some way for implementations that >> have already been deployed, in absence of a clarifying document. >> Exactly how we deal with that is still TBD. >> >> But as we define what is required to support this in the future, I >> think there is *no* benefit to defining two levels of support - full >> and partial. Anybody that sets out to provide support for this >> document should be expected to do it all - its not that much harder. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >>> Hi, >>>> I wonder whether we should define an option-tag for the support of >>>> nested bodies. >>>> >>>> I don't think there's a lot to be gained from defining such an >>>> option-tag. The sender should already be aware that there is a risk >>>> the recipient can't understand nested bodies, and have arranged for >>>> suitable fallbacks. Conversely, the recipient should (at least) be >>>> able to skip the nested multipart body part in the proper "I don't >>>> understand this body part" way. All an option-tag would do is allow >>>> the sender to not add a fallback. >>> >>> In that case we need some specific text saying that if the receiver does >>> not support nested multiparts it MUST do-this-and-do-that. >>> >>> Because, as I said earlier, I don't think we will achieve what we want >>> by saying that one MUST be able to parse nested multiparts. It can be >>> rather tricky to implement (depending on how the parser is implemented, >>> though), and since there aren't really any use-cases out there yet I am >>> pretty sure some people will choose not to implement it (and saying that >>> people are not compliant in that case will not really help from an >>> interop perspective). So, because of that I think it would be good not >>> to mandate the support of nested multiparts, but to mandate appropriate >>> behavior if not supported - just like in any other case when a MIME body >>> contains an unsupported but required content type. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht22O-0007xf-Dj; Tue, 29 May 2007 09:47:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht22N-0007xZ-1k for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht22M-0007xR-O9 for sip@ietf.org; Tue, 29 May 2007 09:46:58 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht22M-0003Tm-6a for sip@ietf.org; Tue, 29 May 2007 09:46:58 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 72D1F21185; Tue, 29 May 2007 15:46:57 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-b3-465c2ed16c22 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 52AF42024B; Tue, 29 May 2007 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.1830); Tue, 29 May 2007 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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Tue, 29 May 2007 15:46:56 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> In-Reply-To: <465C252C.6030909@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/Q References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" , "Paul Kyzivat" X-OriginalArrivalTime: 29 May 2007 13:46:56.0869 (UTC) FILETIME=[D2C86150:01C7A1F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, My main concern is not what wording (SHALL, MUST, etc) we use. The issue is that I think we need text saying what implementations that DO NOT support alternative and/or nested shall do. If we say that they shall reject the message I believe that many of the existing implementations will be compliant with the spec. And, if we give the possibility to simply reject the message, I believe it will be easier to get people to change their implementations, if they currently simply discard alternative and/or nested today. Regards, Christer =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 29. toukokuuta 2007 16:06 > To: Paul Kyzivat > Cc: Christer Holmberg (JO/LMF); sip@ietf.org > Subject: Re: [Sip] MIME: Nested bodies with option-tag? >=20 > Hi, >=20 > what I am hearing is that there are implementations out there=20 > that support multipart but not nested. Therefore, we need to=20 > decide two things: >=20 > 1) do we want to have a MUST for multipart and a SHOULD for=20 > nested? I would say that we should have the same level (e.g.,=20 > MUST, if we decided that MUST is appropriate) for both. >=20 > 2) do we need a way for implementations that support=20 > multipart but not nested to be quickly updated to, at least,=20 > report that fact with an error response? This may make sense. >=20 > Cheers, >=20 > Gonzalo >=20 > Paul Kyzivat wrote: > > More or less repeating what I said before: > >=20 > > I expect we do have to account in some way for implementations that=20 > > have already been deployed, in absence of a clarifying document.=20 > > Exactly how we deal with that is still TBD. > >=20 > > But as we define what is required to support this in the future, I=20 > > think there is *no* benefit to defining two levels of=20 > support - full=20 > > and partial. Anybody that sets out to provide support for this=20 > > document should be expected to do it all - its not that much harder. > >=20 > > Paul > >=20 > > Christer Holmberg (JO/LMF) wrote: > >> Hi, > >>> I wonder whether we should define an option-tag for the=20 > support of > >>> nested bodies. > >>> > >>> I don't think there's a lot to be gained from defining such an=20 > >>> option-tag. The sender should already be aware that=20 > there is a risk=20 > >>> the recipient can't understand nested bodies, and have=20 > arranged for=20 > >>> suitable fallbacks. Conversely, the recipient should (at=20 > least) be=20 > >>> able to skip the nested multipart body part in the proper=20 > "I don't=20 > >>> understand this body part" way. All an option-tag would=20 > do is allow=20 > >>> the sender to not add a fallback. > >> > >> In that case we need some specific text saying that if the=20 > receiver=20 > >> does not support nested multiparts it MUST do-this-and-do-that. > >> > >> Because, as I said earlier, I don't think we will achieve what we=20 > >> want by saying that one MUST be able to parse nested=20 > multiparts. It=20 > >> can be rather tricky to implement (depending on how the parser is=20 > >> implemented, though), and since there aren't really any=20 > use-cases out=20 > >> there yet I am pretty sure some people will choose not to=20 > implement=20 > >> it (and saying that people are not compliant in that case will not=20 > >> really help from an interop perspective). So, because of=20 > that I think=20 > >> it would be good not to mandate the support of nested=20 > multiparts, but=20 > >> to mandate appropriate behavior if not supported - just=20 > like in any=20 > >> other case when a MIME body contains an unsupported but=20 > required content type. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht26c-0001si-Dw; Tue, 29 May 2007 09:51:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht26a-0001sd-Mo for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:51:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht26a-0001sV-Bu for sip@ietf.org; Tue, 29 May 2007 09:51:20 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht26Y-00035a-Ds for sip@ietf.org; Tue, 29 May 2007 09:51:20 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D5F2B20829; Tue, 29 May 2007 15:51:16 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-80-465c2fd40263 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B9A5920628; Tue, 29 May 2007 15:51:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 15:51: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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Tue, 29 May 2007 15:51:15 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704805E4E@esealmw113.eemea.ericsson.se> In-Reply-To: <465C2E4A.2090208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceh948qoe+/o28VTHW6SBSsBhYvvgAAISMQ References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <465C2E4A.2090208@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" , "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 29 May 2007 13:51:16.0429 (UTC) FILETIME=[6D7E17D0:01C7A1F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, =20 >For inadequate implementations I think we must focus on the=20 >installed base that must be coped with. In that regard,=20 >specifying something that the existing implementation must=20 >do, that it doesn't already do, makes little sense. I guess there are people who know this better than me, but I do believe there are implementations which do reject nested bodies today. I agree that we can't do anything regarding implementations which simply discard anything they don't understand. Regards, Christer > > Paul Kyzivat wrote: > >> More or less repeating what I said before: > >> > >> I expect we do have to account in some way for=20 > implementations that=20 > >> have already been deployed, in absence of a clarifying document. > >> Exactly how we deal with that is still TBD. > >> > >> But as we define what is required to support this in the future, I=20 > >> think there is *no* benefit to defining two levels of=20 > support - full=20 > >> and partial. Anybody that sets out to provide support for this=20 > >> document should be expected to do it all - its not that=20 > much harder. > >> > >> Paul > >> > >> Christer Holmberg (JO/LMF) wrote: > >>> Hi, > >>>> I wonder whether we should define an option-tag for=20 > the support of > >>>> nested bodies. > >>>> > >>>> I don't think there's a lot to be gained from defining such an=20 > >>>> option-tag. The sender should already be aware that there is a=20 > >>>> risk the recipient can't understand nested bodies, and have=20 > >>>> arranged for suitable fallbacks. Conversely, the=20 > recipient should=20 > >>>> (at least) be able to skip the nested multipart body part in the=20 > >>>> proper "I don't understand this body part" way. All an=20 > option-tag=20 > >>>> would do is allow the sender to not add a fallback. > >>> > >>> In that case we need some specific text saying that if=20 > the receiver=20 > >>> does not support nested multiparts it MUST do-this-and-do-that. > >>> > >>> Because, as I said earlier, I don't think we will achieve what we=20 > >>> want by saying that one MUST be able to parse nested=20 > multiparts. It=20 > >>> can be rather tricky to implement (depending on how the parser is=20 > >>> implemented, though), and since there aren't really any use-cases=20 > >>> out there yet I am pretty sure some people will choose not to=20 > >>> implement it (and saying that people are not compliant in=20 > that case=20 > >>> will not really help from an interop perspective). So, because of=20 > >>> that I think it would be good not to mandate the support=20 > of nested=20 > >>> multiparts, but to mandate appropriate behavior if not=20 > supported -=20 > >>> just like in any other case when a MIME body contains an=20 > unsupported but required content type. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 09:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht297-0003IV-2Q; Tue, 29 May 2007 09:53:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht295-0003IJ-H5 for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 09:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht295-0003IB-7P for sip@ietf.org; Tue, 29 May 2007 09:53:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht294-0005yZ-S6 for sip@ietf.org; Tue, 29 May 2007 09:53:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2007 09:53:55 -0400 X-IronPort-AV: i="4.14,588,1170651600"; d="scan'208"; a="122235954:sNHT51960480" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4TDrsbX000846; Tue, 29 May 2007 09:53:54 -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.12.10/8.12.6) with ESMTP id l4TDre5x023677; Tue, 29 May 2007 13:53:54 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.1830); Tue, 29 May 2007 09:53:49 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 09:53:49 -0400 Message-ID: <465C306C.2020805@cisco.com> Date: Tue, 29 May 2007 09:53:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Support for Multipart/MIME - support of alternative References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> <465C1FEF.3030409@ericsson.com> <7374777208BDC7449D5620EF9423256704805DD4@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704805DD4@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 13:53:49.0110 (UTC) FILETIME=[C87F5D60:01C7A1F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5327; t=1180446834; x=1181310834; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME=20-=20support= 20of=20alternative |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=rAW6yRM5e5r3tgU3/pNQlPJFc9JpzH4uxp2TabDwKYw=; b=Sx9JUNF86BeY+fNUoPONx6pNm9kkMB2BwtLYL7gpwionI6dtiQ4Uayk2m3cVjwePGO+3oeCU vawsG5quX++txPeHOyuj6FMBPywth6mkN9F2koh3pAvmwheJCTErFTM+; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, Francois Audet , "Gonzalo Camarillo \(JO/LMF\)" , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > >> we should be ready for a transition to a new session >> description protocol, which includes experimental networks >> using their own stuff, and people seem to agree that >> alternative is the way to go. That is why it would be great >> if we could mandate its support already now. >> >> The more we wait, the more trouble we could have in the >> future to use it. > > Yes. > > But, at the same time we need to try to be backward compatible, and take > into consideration existing implementations which may support mixed but > not alternative. If those implementations reject alternative I think our > spec should not make them "not compliant". The MIME spec already says that if you don't understand multipart/X then you should treat it as if it were multipart/mixed. So at a minimum we should expect implementations to do that much with alternative. If we are going to make more accommodation than that based on what is in the wild then I suggest we should take a survey first to find out what we really need to cope with. We should be able to get some good data from SipIT. Maybe we should be trying to come up with a list of specific questions, or maybe we can have an essay question on the survey to get a description of exactly what is/isn't supported. I think we will have a pretty good chance of seeing support in the future if we can tell implementors what they must do. I did specifications for multipart support in a stack a few years ago (which is when I discovered all these open issues), and I had to make up what was done based on speculation about what would be used. Even hard things can be straightforward to implement if the requirements are clear. Paul > The same thing goes for > nested bodies. > > The more we can "fit" the spec into what is already out there, the > better. > > So, I don't mind to strongly recommend people to implement alternative, > and give examples why it may be useful in the future, but at the same > time I think we should also say that if the receiver does not support > alternative a error response MUST be sent - in order to avoid cases e.g. > described by Francois, where the receiver simply discard the multipart > and continues the call setup. > > Regards, > > Christer > > > > > >> Christer Holmberg (JO/LMF) wrote: >>> >>> Hi, >>> >>>>>> OPEN ISSUE 1: do we need to say something about other types? >>>>>> Related (rfc2387), parallel, digest, external-body. >>>>> I don't know much about these. I quickly scanned 2387 and >> see that >>>>> it has some special rules re processing >> Content-Disposition of the >>>>> contained (related) parts. I *think* those are consistent >> with what >>>>> we are doing. >>>> I have added the following text to Section 5: >>>> >>>> "This specification recommends support for 'multipart/mixed' and >>>> 'multipart/alternative'. At present, there are no SIP >> extensions >>>> that use different 'multipart' subtypes such as parallel >>>> [RFC2046], digest [RFC2046], or related [RFC2387]. If such >>>> extensions were to be defined in the future, their authors would >>> need to make sure >>>> (e.g., by using an option-tag or by other means) that entities >>>> receiving those 'multipart' subtypes were able to >> process them. As >>>> stated earlier, UAs treat unknown 'multipart' subtypes as >>>> 'multipart/mixed'." >>> I think the text is good. >>> >>> But, I wonder whether we should alternative to the list of >> "different >>> multipart subtypes". At present there are no SIP extensions using >>> alternative either, so... >>> >>> Or, at least we could leave support of alternative open for the >>> moment, until we get more information about how it's supposed to be >>> used in the first place (regarding identical content type >> values etc). >>> >>>>>> OPEN ISSUE 2: we know that we do not want two SDPs in a >> 'multipart/ >>>>>> alternative', but is this valid generally with any content type? >>>>>> Would it be possible to provide two alternative body parts using >>>>>> the same format and, thus, the same content type but in, say, >>>>>> different languages? >>>>> Its my understanding that the distinction is based on >> which can be >>>>> understood, relative to Content-Type. It isn't apparent >> to me that >>>>> making this decision based on other attributes is valid. >>>>> For one thing the parts are supposed to be ordered by increasing >>>>> richness. If they differed by language this wouldn't be true. >>>>> >>>>> So I think what you have is ok. >>>> I double check with an email expert to make sure we get this right. >>> >>>>> Another thing in Section 3: You have used SHOULD in this >> section. I >>>>> thought we wanted to change this to MUST. Did we? >>>> You refer to the following statement, right? >>>> >>>> "In particular, UAs SHOULD support the 'multipart/mixed' >>>> and 'multipart/alternative' MIME types." >>>> >>>> If people agree that this should be a MUST, I will be >> happy to change >>>> it. >>> Again, I think we should wait a little regarding alternative. >>> >>> Regards, >>> >>> Christer >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 10:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht2GQ-0006Di-1E; Tue, 29 May 2007 10:01:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht2GO-0006Cx-I6 for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 10:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht2GO-0006Cp-8M for sip@ietf.org; Tue, 29 May 2007 10:01:28 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht2GN-0000EY-Q9 for sip@ietf.org; Tue, 29 May 2007 10:01:28 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 May 2007 10:01:28 -0400 X-IronPort-AV: i="4.14,588,1170651600"; d="scan'208"; a="122236600:sNHT57571826" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4TE1Rsj003903; Tue, 29 May 2007 10:01:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4TE1O5p025814; Tue, 29 May 2007 14:01:25 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.1830); Tue, 29 May 2007 10:01:19 -0400 Received: from [10.86.240.79] ([10.86.240.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 10:01:18 -0400 Message-ID: <465C322D.20903@cisco.com> Date: Tue, 29 May 2007 10:01:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 14:01:18.0574 (UTC) FILETIME=[D46620E0:01C7A1F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5521; t=1180447287; x=1181311287; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=xMCWVdW16a62WSW1Cs8yZQOV0BSfOvY2ojjNhJqJUtE=; b=naKG7SSRLZpBZrrECThZKrFDFEgriJYbOD7VCnC3MUKJJp/ymlbx6rwGxGGfVvIFrAiLzqO9 KpM1UxVyGnuLuHV1FgjjV8rzMJ7dB4w8Hp2f90eJ7kfjGyOlTFe6YRVl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > My main concern is not what wording (SHALL, MUST, etc) we use. > > The issue is that I think we need text saying what implementations that > DO NOT support alternative and/or nested shall do. If we say that they > shall reject the message I believe that many of the existing > implementations will be compliant with the spec. > > And, if we give the possibility to simply reject the message, I believe > it will be easier to get people to change their implementations, if they > currently simply discard alternative and/or nested today. I agree that simply ignoring a body can cause huge problems. I believe we have addressed that by clarifying the use of Content-Disposition and its handling parameter. In the absence of handling=optional, the request must be rejected. This part must be of MUST strength. And the default of handling=required in the absence of a C-D header must also be of MUST strength. But there is little we can do about existing implementations that don't do that right. I guess I can see writing up somewhere that even if you aren't going to make your implementation compliant to this full draft you should at least do make sure you support Content-Disposition. Would it be helpful in that regard to make that part a separate draft??? Paul > Regards, > > Christer > > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: 29. toukokuuta 2007 16:06 >> To: Paul Kyzivat >> Cc: Christer Holmberg (JO/LMF); sip@ietf.org >> Subject: Re: [Sip] MIME: Nested bodies with option-tag? >> >> Hi, >> >> what I am hearing is that there are implementations out there >> that support multipart but not nested. Therefore, we need to >> decide two things: >> >> 1) do we want to have a MUST for multipart and a SHOULD for >> nested? I would say that we should have the same level (e.g., >> MUST, if we decided that MUST is appropriate) for both. >> >> 2) do we need a way for implementations that support >> multipart but not nested to be quickly updated to, at least, >> report that fact with an error response? This may make sense. >> >> Cheers, >> >> Gonzalo >> >> Paul Kyzivat wrote: >>> More or less repeating what I said before: >>> >>> I expect we do have to account in some way for implementations that >>> have already been deployed, in absence of a clarifying document. >>> Exactly how we deal with that is still TBD. >>> >>> But as we define what is required to support this in the future, I >>> think there is *no* benefit to defining two levels of >> support - full >>> and partial. Anybody that sets out to provide support for this >>> document should be expected to do it all - its not that much harder. >>> >>> Paul >>> >>> Christer Holmberg (JO/LMF) wrote: >>>> Hi, >>>>> I wonder whether we should define an option-tag for the >> support of >>>>> nested bodies. >>>>> >>>>> I don't think there's a lot to be gained from defining such an >>>>> option-tag. The sender should already be aware that >> there is a risk >>>>> the recipient can't understand nested bodies, and have >> arranged for >>>>> suitable fallbacks. Conversely, the recipient should (at >> least) be >>>>> able to skip the nested multipart body part in the proper >> "I don't >>>>> understand this body part" way. All an option-tag would >> do is allow >>>>> the sender to not add a fallback. >>>> In that case we need some specific text saying that if the >> receiver >>>> does not support nested multiparts it MUST do-this-and-do-that. >>>> >>>> Because, as I said earlier, I don't think we will achieve what we >>>> want by saying that one MUST be able to parse nested >> multiparts. It >>>> can be rather tricky to implement (depending on how the parser is >>>> implemented, though), and since there aren't really any >> use-cases out >>>> there yet I am pretty sure some people will choose not to >> implement >>>> it (and saying that people are not compliant in that case will not >>>> really help from an interop perspective). So, because of >> that I think >>>> it would be good not to mandate the support of nested >> multiparts, but >>>> to mandate appropriate behavior if not supported - just >> like in any >>>> other case when a MIME body contains an unsupported but >> required content type. >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 15:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7W9-0005rM-5U; Tue, 29 May 2007 15:38:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht7W7-0005rG-HO for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 15:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7W7-0005r8-7e for sip@ietf.org; Tue, 29 May 2007 15:38:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht7W5-0005al-Td for sip@ietf.org; Tue, 29 May 2007 15:38:03 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 May 2007 12:37:57 -0700 X-IronPort-AV: i="4.14,589,1170662400"; d="scan'208"; a="158546110:sNHT40456620" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4TJbveR030847; Tue, 29 May 2007 12:37:57 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4TJbuV1011572; Tue, 29 May 2007 19:37:56 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'Gonzalo Camarillo'" Subject: RE: [Sip] Support for Multipart/MIME Date: Tue, 29 May 2007 12:37:55 -0700 Message-ID: <093d01c7a228$db7a85e0$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <465A6313.4030304@cisco.com> Thread-Index: Aceg5c2Od5RC/CkdRaOLzE7s/msx7ABQmsaw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1108; t=1180467477; x=1181331477; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=6N1xbN5wSVSL5oFGUgC8G8KNbdmQNtOJwFgjwDZ5IeU=; b=sJaxISLIITzBIMPndIgk9tpA1fpp2744ogLSPJeYIHqBozucYKicgNnMbmauMQtF+Nyd8OQP NWchTTke13/RM8+r9rvgaimOadJ/i2Z6W0sYx+FpBHq9pL5wt93KL54o; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org, 'Francois Audet' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: ... > > OPEN ISSUE 2: we know that we do not want two SDPs in a > > 'multipart/ > > alternative', but is this valid generally with any content type? > > Would it be possible to provide two alternative body > > parts using the > > same format and, thus, the same content type but in, > > say, different > > languages? > > Its my understanding that the distinction is based on which can be > understood, relative to Content-Type. It isn't apparent to me that > making this decision based on other attributes is valid. For > one thing the parts are supposed to be ordered by increasing > richness. If they differed by language this wouldn't be true. Multipart/alternative is the best we have, though. And who is to say that image/jpeg is richer than image/gif, or that english is richer than latin? Anyway, the following RFCs standardize the use of Content-Language and refer to using multipart/alternative when providing support for multiple languages: http://tools.ietf.org/html/rfc3282 http://tools.ietf.org/html/rfc3066 -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue May 29 16:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7kX-00067k-TE; Tue, 29 May 2007 15:52:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ht7ik-00027W-H4 for sip-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 15:51:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7ih-00023o-In; Tue, 29 May 2007 15:51:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht7ih-0006vI-3N; Tue, 29 May 2007 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 036D61760B; Tue, 29 May 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ht7hi-0007Mn-DF; Tue, 29 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 29 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-saml-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org --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 Working Group of the IETF. Title : SIP SAML Profile and Binding Author(s) : H. Tschofenig, et al. Filename : draft-ietf-sip-saml-02.txt Pages : 46 Date : 2007-5-29 This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-saml-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-saml-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-29121035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-saml-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-saml-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-29121035.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed May 30 02:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHSz-0003qV-0Y; Wed, 30 May 2007 02:15:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtHSw-0003qQ-SF for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHSw-0003qI-EX for sip@ietf.org; Wed, 30 May 2007 02:15:26 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHSv-00085v-SI for sip@ietf.org; Wed, 30 May 2007 02:15:26 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4U6F7rU023291; Wed, 30 May 2007 01:15:12 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 01:15:11 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 01:04:58 -0500 Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:54:10 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:43:58 -0500 Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:33:00 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:33:00 -0500 Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:32:59 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:32:59 -0500 Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 00:32:59 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 07:32: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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Wed, 30 May 2007 07:32:50 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> In-Reply-To: <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? Thread-Index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DA= References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se><465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> From: "DRAGE, Keith \(Keith\)" To: "Christer Holmberg \(JO/LMF\)" , "Gonzalo Camarillo \(JO/LMF\)" , "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 05:32:56.0536 (UTC) FILETIME=[FA2E3D80:01C7A27B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Once we get down to a decision of supporting nested versus not supporting nesting, presumably we are then entirely in the realm of the multipart coding itself. Could I ask someone to elaborate on what generic requirements already exist within multipart/mime in this respect, before we start looking at defining SIP specific rules or indications? Regards Keith=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, May 29, 2007 2:47 PM > To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat > Cc: sip@ietf.org > Subject: RE: [Sip] MIME: Nested bodies with option-tag? >=20 >=20 > Hi, >=20 > My main concern is not what wording (SHALL, MUST, etc) we use. >=20 > The issue is that I think we need text saying what=20 > implementations that DO NOT support alternative and/or nested=20 > shall do. If we say that they shall reject the message I=20 > believe that many of the existing implementations will be=20 > compliant with the spec. >=20 > And, if we give the possibility to simply reject the message,=20 > I believe it will be easier to get people to change their=20 > implementations, if they currently simply discard alternative=20 > and/or nested today. >=20 > Regards, >=20 > Christer > =20 >=20 > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: 29. toukokuuta 2007 16:06 > > To: Paul Kyzivat > > Cc: Christer Holmberg (JO/LMF); sip@ietf.org > > Subject: Re: [Sip] MIME: Nested bodies with option-tag? > >=20 > > Hi, > >=20 > > what I am hearing is that there are implementations out there that=20 > > support multipart but not nested. Therefore, we need to decide two=20 > > things: > >=20 > > 1) do we want to have a MUST for multipart and a SHOULD for=20 > nested? I=20 > > would say that we should have the same level (e.g., MUST, if we=20 > > decided that MUST is appropriate) for both. > >=20 > > 2) do we need a way for implementations that support=20 > multipart but not=20 > > nested to be quickly updated to, at least, report that fact with an=20 > > error response? This may make sense. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > Paul Kyzivat wrote: > > > More or less repeating what I said before: > > >=20 > > > I expect we do have to account in some way for=20 > implementations that=20 > > > have already been deployed, in absence of a clarifying document. > > > Exactly how we deal with that is still TBD. > > >=20 > > > But as we define what is required to support this in the=20 > future, I=20 > > > think there is *no* benefit to defining two levels of > > support - full > > > and partial. Anybody that sets out to provide support for this=20 > > > document should be expected to do it all - its not that=20 > much harder. > > >=20 > > > Paul > > >=20 > > > Christer Holmberg (JO/LMF) wrote: > > >> Hi, > > >>> I wonder whether we should define an option-tag for the > > support of > > >>> nested bodies. > > >>> > > >>> I don't think there's a lot to be gained from defining such an=20 > > >>> option-tag. The sender should already be aware that > > there is a risk > > >>> the recipient can't understand nested bodies, and have > > arranged for > > >>> suitable fallbacks. Conversely, the recipient should (at > > least) be > > >>> able to skip the nested multipart body part in the proper > > "I don't > > >>> understand this body part" way. All an option-tag would > > do is allow > > >>> the sender to not add a fallback. > > >> > > >> In that case we need some specific text saying that if the > > receiver > > >> does not support nested multiparts it MUST do-this-and-do-that. > > >> > > >> Because, as I said earlier, I don't think we will=20 > achieve what we=20 > > >> want by saying that one MUST be able to parse nested > > multiparts. It > > >> can be rather tricky to implement (depending on how the=20 > parser is=20 > > >> implemented, though), and since there aren't really any > > use-cases out > > >> there yet I am pretty sure some people will choose not to > > implement > > >> it (and saying that people are not compliant in that=20 > case will not=20 > > >> really help from an interop perspective). So, because of > > that I think > > >> it would be good not to mandate the support of nested > > multiparts, but > > >> to mandate appropriate behavior if not supported - just > > like in any > > >> other case when a MIME body contains an unsupported but > > required content type. > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>> This list is for NEW development of the core SIP Protocol Use=20 > > >>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >>> sipping@ietf.org for new developments on the application of sip > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use=20 > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 03:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIps-0002Ph-N1; Wed, 30 May 2007 03:43:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtIps-0002Pc-5y for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 03:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIpr-0002PU-SG for sip@ietf.org; Wed, 30 May 2007 03:43:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtIpr-0005IN-5E for sip@ietf.org; Wed, 30 May 2007 03:43:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83C09200C5; Wed, 30 May 2007 09:43:10 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-b5-465d2b0e3cd4 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 63A092009A; Wed, 30 May 2007 09:43:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:43: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 Subject: RE: [Sip] MIME: Alternative and identical Content-Types Date: Wed, 30 May 2007 09:43:09 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C655@esealmw113.eemea.ericsson.se> In-Reply-To: <465AF53F.2050808@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Alternative and identical Content-Types thread-index: AcehPQSwkfX/YQjYT8SWMXhxUYT67QBULdZA References: <7374777208BDC7449D5620EF9423256704739F3C@esealmw113.eemea.ericsson.se> <465AF53F.2050808@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 07:43:10.0089 (UTC) FILETIME=[2B6BCF90:01C7A28E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Paul, >As best I understand, multipart/alternative assumes that you=20 >either do or don't "support" a particular alternative, and=20 >that the alternatives are arranged from least-preferred to=20 >most-preferred by the sender. The recipient is supposed to=20 >use the most-preferred (as defined by the >sender) that it "supports". >=20 >I guess we could allow different attributes, besides=20 >content-type to be used to decide if a part is "supported",=20 >*if* we can come up with a well defined meaning for "supported". > >I guess this could work for content-language. But I don't=20 >know about the text-friendly vs image-containing html. Maybe,=20 >but it needs better definition. Chapter 5.1.4 in RFC2046 says (and I think that describes my use-case): "Multipart/alternative" may be used, for example, to send a message in a fancy text format in such a way that it can easily be displayed anywhere: From: Nathaniel Borenstein To: Ned Freed Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3Dboundary42 --boundary42 Content-Type: text/plain; charset=3Dus-ascii ... plain text version of message goes here ... --boundary42 Content-Type: text/enriched ... RFC 1896 text/enriched version of same message goes here ... --boundary42 Content-Type: application/x-whatever ... fanciest version of same message goes here ... --boundary42-- In this example, users whose mail systems understood the "application/x-whatever" format would see only the fancy version, while other users would see only the enriched or plain text version, depending on the capabilities of their system." Regards, Christer >=20 > Paul >=20 > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > > Gonzalo's draft say that, when multipart/alternative is used,=20 > > different body parts can not have the same content type. > >=20 > > Below are a couple of use-cases where the same content type=20 > is used,=20 > > and which may still be feasible for alternative: > >=20 > > 1. > > =20 > > Let's assume I have two HTML bodies. They both contain the same=20 > > information, but one is "text friendly", while the other contains=20 > > pictures etc. Now, is that alternative or mixed(or parallel)? > > =20 > >=20 > > 2. > > =20 > > Let's assume I have the same information, but in different=20 > languages -=20 > > ie the Content-Language values are different. Is that=20 > alternative or=20 > > Mixed(or parallel)? > > =20 > >=20 > >=20 > > Now, we may not have the expertise to determine whether=20 > alternative is=20 > > allowed or not in these cases. But, if the think there=20 > could be cases=20 > > where the same content type would be used for alternative,=20 > we need to=20 > > allow it. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 03:51:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIyL-0007NB-9d; Wed, 30 May 2007 03:51:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtIyJ-0007N5-91 for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 03:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIyI-0007Mx-VS for sip@ietf.org; Wed, 30 May 2007 03:51:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtIyI-00071H-9K for sip@ietf.org; Wed, 30 May 2007 03:51:54 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE23420205; Wed, 30 May 2007 09:51:53 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-14-465d2d1999c7 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 995D520FD1; Wed, 30 May 2007 09:51:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:51: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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Wed, 30 May 2007 09:51:51 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> In-Reply-To: <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DAABMy8AA== References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se><465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "DRAGE, Keith (Keith)" , "Gonzalo Camarillo (JO/LMF)" , "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 07:51:53.0208 (UTC) FILETIME=[63396F80:01C7A28F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith,=20 >Once we get down to a decision of supporting nested versus=20 >not supporting nesting, presumably we are then entirely in=20 >the realm of the multipart coding itself. >=20 >Could I ask someone to elaborate on what generic requirements=20 >already exist within multipart/mime in this respect, before=20 >we start looking at defining SIP specific rules or indications? I am very sure that I have seen text related to the support of nested multiparts, and what nodes are expected to support, somewhere, but I yet have not found it. Regards, Christer >=20 > Regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, May 29, 2007 2:47 PM > > To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat > > Cc: sip@ietf.org > > Subject: RE: [Sip] MIME: Nested bodies with option-tag? > >=20 > >=20 > > Hi, > >=20 > > My main concern is not what wording (SHALL, MUST, etc) we use. > >=20 > > The issue is that I think we need text saying what implementations=20 > > that DO NOT support alternative and/or nested shall do. If=20 > we say that=20 > > they shall reject the message I believe that many of the existing=20 > > implementations will be compliant with the spec. > >=20 > > And, if we give the possibility to simply reject the message, I=20 > > believe it will be easier to get people to change their=20 > > implementations, if they currently simply discard=20 > alternative and/or=20 > > nested today. > >=20 > > Regards, > >=20 > > Christer > > =20 > >=20 > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > Sent: 29. toukokuuta 2007 16:06 > > > To: Paul Kyzivat > > > Cc: Christer Holmberg (JO/LMF); sip@ietf.org > > > Subject: Re: [Sip] MIME: Nested bodies with option-tag? > > >=20 > > > Hi, > > >=20 > > > what I am hearing is that there are implementations out=20 > there that=20 > > > support multipart but not nested. Therefore, we need to decide two > > > things: > > >=20 > > > 1) do we want to have a MUST for multipart and a SHOULD for > > nested? I > > > would say that we should have the same level (e.g., MUST, if we=20 > > > decided that MUST is appropriate) for both. > > >=20 > > > 2) do we need a way for implementations that support > > multipart but not > > > nested to be quickly updated to, at least, report that=20 > fact with an=20 > > > error response? This may make sense. > > >=20 > > > Cheers, > > >=20 > > > Gonzalo > > >=20 > > > Paul Kyzivat wrote: > > > > More or less repeating what I said before: > > > >=20 > > > > I expect we do have to account in some way for > > implementations that > > > > have already been deployed, in absence of a clarifying document. > > > > Exactly how we deal with that is still TBD. > > > >=20 > > > > But as we define what is required to support this in the > > future, I > > > > think there is *no* benefit to defining two levels of > > > support - full > > > > and partial. Anybody that sets out to provide support for this=20 > > > > document should be expected to do it all - its not that > > much harder. > > > >=20 > > > > Paul > > > >=20 > > > > Christer Holmberg (JO/LMF) wrote: > > > >> Hi, > > > >>> I wonder whether we should define an option-tag for the > > > support of > > > >>> nested bodies. > > > >>> > > > >>> I don't think there's a lot to be gained from=20 > defining such an=20 > > > >>> option-tag. The sender should already be aware that > > > there is a risk > > > >>> the recipient can't understand nested bodies, and have > > > arranged for > > > >>> suitable fallbacks. Conversely, the recipient should (at > > > least) be > > > >>> able to skip the nested multipart body part in the proper > > > "I don't > > > >>> understand this body part" way. All an option-tag would > > > do is allow > > > >>> the sender to not add a fallback. > > > >> > > > >> In that case we need some specific text saying that if the > > > receiver > > > >> does not support nested multiparts it MUST do-this-and-do-that. > > > >> > > > >> Because, as I said earlier, I don't think we will > > achieve what we > > > >> want by saying that one MUST be able to parse nested > > > multiparts. It > > > >> can be rather tricky to implement (depending on how the > > parser is > > > >> implemented, though), and since there aren't really any > > > use-cases out > > > >> there yet I am pretty sure some people will choose not to > > > implement > > > >> it (and saying that people are not compliant in that > > case will not > > > >> really help from an interop perspective). So, because of > > > that I think > > > >> it would be good not to mandate the support of nested > > > multiparts, but > > > >> to mandate appropriate behavior if not supported - just > > > like in any > > > >> other case when a MIME body contains an unsupported but > > > required content type. > > > >> > > > >> Regards, > > > >> > > > >> Christer > > > >> > > > >> > > > >> > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >>> This list is for NEW development of the core SIP Protocol Use=20 > > > >>> sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > >>> sipping@ietf.org for new developments on the=20 > application of sip > > > >>> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol Use=20 > > > >> sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > >> sipping@ietf.org for new developments on the application of sip > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:05:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJBc-0006se-4U; Wed, 30 May 2007 04:05:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJBa-0006sU-AK for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:05:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJBa-0006sM-0a for sip@ietf.org; Wed, 30 May 2007 04:05:38 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJBZ-0007Eo-Cv for sip@ietf.org; Wed, 30 May 2007 04:05:37 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U85BU7019407; Wed, 30 May 2007 11:05:35 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:05:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:05:13 +0300 Received: from [172.21.41.217] ([172.21.41.217]) by esebe105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:05:13 +0300 Message-ID: <465D3039.4040907@nokia.com> Date: Wed, 30 May 2007 11:05:13 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: "ext Anders Lindgren C (TN/EAB)" References: <6D34F0B7D5BCB246A42380744457CA36E508B4@esealmw107.eemea.ericsson.se> <464D516C.4010501@nokia.com> <6D34F0B7D5BCB246A42380744457CA36F766C2@esealmw107.eemea.ericsson.se> In-Reply-To: <6D34F0B7D5BCB246A42380744457CA36F766C2@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 08:05:13.0420 (UTC) FILETIME=[403018C0:01C7A291] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sip@ietf.org Subject: [Sip] Re: Your draft xcap-diff-event:Sending etag information in the Subscribe. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Anders Lindgren C (TN/EAB) wrote: > Hello Jari, > Thanks for your answers. > I'm try to do my best to understand how your I-D together with other > I-D's or RFC can be used to provide us with of methods to able to be use > in a number of scenarios. I do also think that we must let implementers > have a number of methods to select from in order to best solve found > issues. This is list of some scenarios I see. > > 1) The number of documents that a client want to monitor is huge. Number > of SIP sessions must be limited as it costs to refresh them over the > air. > > 2) The documents to monitor belong to a number of users. The number of > SIP sessions must be limited as it cost to refresh them over the air. ( > e.g. a user is a member of many groups and is allowed to see the content > of each group documents) > > 3) Fiber is used between a client and the network. Number of SIP > sessions or number of bytes sent is not an issue > > 4) It exist large documents. Changes are normally small ( e.g. a > resource list with 500 contacts and display name is changed or a contact > is added once a week) > > 5) The client has to need to be able to present the difference between > its cached version of a document and the latest document stored on the > server to the client user. > > 6) The monitored XML node is large. Changes are normally done only to > child element/attributes to the node ( e.g. a list element within a > resource-list document. A diplay name of one of the contact is changed). > Number of bytes sent between a server and a client is an issue. > > > Some more questions: > A) 1) is handle by your I-D as you can list a number of documents and > directories related to the R-URI. 2) is not handled. Do you think your > I-D can be combined with > http://tools.ietf.org/html/draft-ietf-sip-uri-list-subscribe-01 to be > able to use a exploder function in the network to have one Subscribe > sessions for all possible documents independent upon owner? As I see it > the parameter "path" is more or less replaced with the URI list in the > body therefore "path" needs to optional and not mandatory in this case? > I'm somewhat lost here. So you could request similar (or all) xcap docs on many different servers ? The "path" parameter is used as a deterministic way to describe the content what the client is interested in, so how with exploder you would select them ? I'd assume you would send the same parameter forward. > B) As I see it a limited patch history function in the XCAP server can > be useful to handle 4) and 5). As you did not like my idea to send the > version information upstream via SIP, I have another idea and that is to > make it possible for a XCAP client to via the XCAP send do a Conditional > GET and if the etags are different receive a diff document instead of a > full document if such patch history exists. My view is that it is better > to keep a patch history on the server than keeping a copy of every > version. I also know that in OMA it exists requirement to be able to > provide a history of who and want certain clients added to the document > and this is more or less a patch history plus an indication about who > and when the patch was done. What's your view? > Yes, this is what instance manipulation is about, i.e. rfc 3229. What you would need is a new mime-type for xml-diff based on patch-ops. Secondly, you would require versioning in xcap server and lastly, retrieval of versioned documents to cleanly solve this initial sync problem. And still, ;-) we could add yet many other interesting features, and I'm in general in favor of improving things, but scope of this i-d is imo right, i.e. all of these can (and should) be done in other documents. > C) 6) needs that it is possible also to send xml patches also when you > subscribe for a XML node. My understanding of your I-D is that that is > not supported. Is that true? > > Br > Anders > > > Right, I was initially hesitant about the requirement of xcap-component retrievals with sip. Although patching of xcap components (i.e. elements) is doable with some "magic" (it's not extremely complex), I'm inclined to think it's not a feature that you really need. So my preference is to keep this as simple as possible. thanks, jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJD7-0007Jj-VW; Wed, 30 May 2007 04:07:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJD5-0007Je-PO for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJD5-0007JW-FV for sip@ietf.org; Wed, 30 May 2007 04:07:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJD3-0007eB-Pc for sip@ietf.org; Wed, 30 May 2007 04:07:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 31718207F9; Wed, 30 May 2007 10:07:09 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-9d-465d30adf7a8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1D36F2049A; Wed, 30 May 2007 10:07:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:07:08 +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 Subject: RE: [Sip] Support for Multipart/MIME - when is it allowed to use alternative? Date: Wed, 30 May 2007 10:07:01 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C807@esealmw113.eemea.ericsson.se> In-Reply-To: <093d01c7a228$db7a85e0$c6f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - when is it allowed to use alternative? thread-index: Aceg5c2Od5RC/CkdRaOLzE7s/msx7ABQmsawABoQQDA= References: <465A6313.4030304@cisco.com> <093d01c7a228$db7a85e0$c6f0200a@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "Paul Kyzivat" , "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 30 May 2007 08:07:08.0781 (UTC) FILETIME=[84F2C9D0:01C7A291] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't think we should try to specify in detail when one is allowed to use alternative, and one is not allowed, but instead refer to other specifications for specific content types, and say that an implementation shall reject the message if alternative is used in a wrong way (based on those other specs). I think our main focus should be to describe the expected protocol level behavior of a SIP entity when receiving alternative. Do we have the same issue with mixed, btw? I assume there COULD be cases where the same content type can be used with mixed? Regards, Christer=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 29. toukokuuta 2007 22:38 > To: 'Paul Kyzivat'; Gonzalo Camarillo (JO/LMF) > Cc: 'Francois Audet'; sip@ietf.org; Christer Holmberg (JO/LMF) > Subject: RE: [Sip] Support for Multipart/MIME >=20 > Paul Kyzivat wrote:=20 > ... > > > OPEN ISSUE 2: we know that we do not want two SDPs in a=20 > > > 'multipart/ > > > alternative', but is this valid generally with any=20 > content type? > > > Would it be possible to provide two alternative body=20 > parts using=20 > > > the > > > same format and, thus, the same content type but in, say,=20 > > > different > > > languages? > >=20 > > Its my understanding that the distinction is based on which can be=20 > > understood, relative to Content-Type. It isn't apparent to me that=20 > > making this decision based on other attributes is valid.=20 > For one thing=20 > > the parts are supposed to be ordered by increasing=20 > richness. If they=20 > > differed by language this wouldn't be true. >=20 > Multipart/alternative is the best we have, though. And who=20 > is to say that image/jpeg is richer than image/gif, or that=20 > english is richer than latin? =20 >=20 > Anyway, the following RFCs standardize the use of=20 > Content-Language and refer to using multipart/alternative=20 > when providing support for multiple > languages: >=20 > http://tools.ietf.org/html/rfc3282 > http://tools.ietf.org/html/rfc3066 >=20 > -d >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJJs-0003zU-9u; Wed, 30 May 2007 04:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJJq-0003zH-Uz for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJJq-0003z9-G1 for sip@ietf.org; Wed, 30 May 2007 04:14:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJJn-00029F-Ph for sip@ietf.org; Wed, 30 May 2007 04:14:10 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B87E2075D; Wed, 30 May 2007 10:14:07 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-98-465d324fc9ee Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0EC962077E; Wed, 30 May 2007 10:14:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:14: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 Subject: RE: [Sip] Support for Multipart/MIME - support of alternative Date: Wed, 30 May 2007 10:14:03 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C86A@esealmw113.eemea.ericsson.se> In-Reply-To: <465C306C.2020805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Support for Multipart/MIME - support of alternative thread-index: Aceh+M4t1V4V0erpTbKwhNIEePymGgAKnLXQ References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <4659D9FA.70501@ericsson.com> <465A6313.4030304@cisco.com> <465BE553.4010500@ericsson.com> <7374777208BDC7449D5620EF9423256704805AC0@esealmw113.eemea.ericsson.se> <465C1FEF.3030409@ericsson.com> <7374777208BDC7449D5620EF9423256704805DD4@esealmw113.eemea.ericsson.se> <465C306C.2020805@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 08:14:06.0571 (UTC) FILETIME=[7DF87BB0:01C7A292] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: sip@ietf.org, Francois Audet , "Gonzalo Camarillo \(JO/LMF\)" , Dan Wing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 > >> we should be ready for a transition to a new session description=20 > >> protocol, which includes experimental networks using their=20 > own stuff,=20 > >> and people seem to agree that alternative is the way to=20 > go. That is=20 > >> why it would be great if we could mandate its support already now. > >> > >> The more we wait, the more trouble we could have in the=20 > future to use=20 > >> it. > >=20 > > Yes. > >=20 > > But, at the same time we need to try to be backward compatible, and=20 > > take into consideration existing implementations which may support=20 > > mixed but not alternative. If those implementations reject=20 > alternative=20 > > I think our spec should not make them "not compliant". >=20 >The MIME spec already says that if you don't understand=20 >multipart/X then you should treat it as if it were=20 >multipart/mixed. So at a minimum we should expect=20 >implementations to do that much with alternative. Well, assuming we don't think THAT could cause problems in the future... But, since that is generic specific MIME behavior I think we'll have to live with it. But, I STILL think it's good to give an implementation to option to reject alternative - at least if we find out that is what existing implementations are doing. =20 >If we are going to make more accommodation than that based on=20 >what is in the wild then I suggest we should take a survey=20 >first to find out what we really need to cope with. We should=20 >be able to get some good data from SipIT. Maybe we should be=20 >trying to come up with a list of specific questions, or maybe=20 >we can have an essay question on the survey to get a=20 >description of exactly what is/isn't supported. My understanding is based on my SIPit experience, and what I have implemented myself. But, I have to admit I haven't been to SIPit for a while, so someone else (Robert?) may have better information. >I think we will have a pretty good chance of seeing support=20 >in the future if we can tell implementors what they must do.=20 It's not always the implementors we have to tell - often it's the people paying the implementors :) >I did specifications for multipart support in a stack a few=20 >years ago (which is when I discovered all these open issues),=20 >and I had to make up what was done based on speculation about=20 >what would be used. Even hard things can be straightforward=20 >to implement if the requirements are clear. I am not saying that it is difficult to implement alternative, but I doubt many have done it. But, it would be interesting to know what implementations do:=20 1. do they treat alternative as mixed?=20 2. do they reject the request? 3. do they support alternative?=20 4. do they discard the message body? I think our spec should allow options 1, 2 and 3. Regards, Christer > >>> =20 > >>> Hi, > >>> > >>>>>> OPEN ISSUE 1: do we need to say something about other types? =20 > >>>>>> Related (rfc2387), parallel, digest, external-body. > >>>>> I don't know much about these. I quickly scanned 2387 and > >> see that > >>>>> it has some special rules re processing > >> Content-Disposition of the > >>>>> contained (related) parts. I *think* those are consistent > >> with what > >>>>> we are doing. > >>>> I have added the following text to Section 5: > >>>> > >>>> "This specification recommends support for=20 > 'multipart/mixed' and > >>>> 'multipart/alternative'. At present, there are no SIP > >> extensions > >>>> that use different 'multipart' subtypes such as parallel=20 > >>>> [RFC2046], digest [RFC2046], or related [RFC2387]. If such=20 > >>>> extensions were to be defined in the future, their=20 > authors would > >>> need to make sure > >>>> (e.g., by using an option-tag or by other means) that entities > >>>> receiving those 'multipart' subtypes were able to > >> process them. As > >>>> stated earlier, UAs treat unknown 'multipart' subtypes as=20 > >>>> 'multipart/mixed'." > >>> I think the text is good. > >>> > >>> But, I wonder whether we should alternative to the list of > >> "different > >>> multipart subtypes". At present there are no SIP extensions using=20 > >>> alternative either, so... > >>> =20 > >>> Or, at least we could leave support of alternative open for the=20 > >>> moment, until we get more information about how it's=20 > supposed to be=20 > >>> used in the first place (regarding identical content type > >> values etc). > >>> > >>>>>> OPEN ISSUE 2: we know that we do not want two SDPs in a > >> 'multipart/ > >>>>>> alternative', but is this valid generally with any=20 > content type? > >>>>>> Would it be possible to provide two alternative body=20 > parts using=20 > >>>>>> the same format and, thus, the same content type but in, say,=20 > >>>>>> different languages? > >>>>> Its my understanding that the distinction is based on > >> which can be > >>>>> understood, relative to Content-Type. It isn't apparent > >> to me that > >>>>> making this decision based on other attributes is valid. > >>>>> For one thing the parts are supposed to be ordered by=20 > increasing=20 > >>>>> richness. If they differed by language this wouldn't be true. > >>>>> > >>>>> So I think what you have is ok. > >>>> I double check with an email expert to make sure we get=20 > this right. > >>> > >>>>> Another thing in Section 3: You have used SHOULD in this > >> section. I > >>>>> thought we wanted to change this to MUST. Did we? > >>>> You refer to the following statement, right? > >>>> > >>>> "In particular, UAs SHOULD support the 'multipart/mixed' > >>>> and 'multipart/alternative' MIME types." > >>>> > >>>> If people agree that this should be a MUST, I will be > >> happy to change > >>>> it. > >>> Again, I think we should wait a little regarding alternative. > >>> > >>> Regards, > >>> > >>> Christer > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJML-0005QI-FD; Wed, 30 May 2007 04:16:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJMJ-0005QA-OU for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJMJ-0005Q2-EZ for sip@ietf.org; Wed, 30 May 2007 04:16:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJMI-0002bF-Cs for sip@ietf.org; Wed, 30 May 2007 04:16:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BFF8E21253; Wed, 30 May 2007 10:16:41 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-a1-465d32e9ff4f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A5BE2211FB; Wed, 30 May 2007 10:16:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:16:19 +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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Wed, 30 May 2007 10:16:17 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C891@esealmw113.eemea.ericsson.se> In-Reply-To: <465C322D.20903@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceh+du5bs4NqNu4R8e9DTzp0RCmEAAKtzDA References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se> <465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> <465C322D.20903@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 08:16:19.0036 (UTC) FILETIME=[CCED09C0:01C7A292] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>My main concern is not what wording (SHALL, MUST, etc) we use. >>=20 >>The issue is that I think we need text saying what implementations=20 >>that DO NOT support alternative and/or nested shall do. If we say that >>they shall reject the message I believe that many of the existing=20 >>implementations will be compliant with the spec. >>=20 >>And, if we give the possibility to simply reject the message, I=20 >>believe it will be easier to get people to change their=20 >>implementations, if they currently simply discard alternative and/or nested today. >=20 >I agree that simply ignoring a body can cause huge problems. >=20 >I believe we have addressed that by clarifying the use of=20 >Content-Disposition and its handling parameter. In the=20 >absence of handling=3Doptional, the request must be rejected.=20 >This part must be of MUST strength. And the default of=20 >handling=3Drequired in the absence of a C-D header must also be=20 >of MUST strength. I agree with that. But, if there are implementations that don't even look at the C-D headers, because they discard the whole message body because they don't support multipart/alternative, that does not solve the problem. So, it is important that implementations either treat alternative as mixed or, as I suggest, reject the request.=20 BTW, in the case of alternative, is the receiver required to support all body types if they have handling=3Drequired? Or, is it enough if they support at least one of the alternative body types? >But there is little we can do about existing implementations=20 >that don't do that right. I guess I can see writing up=20 >somewhere that even if you aren't going to make your=20 >implementation compliant to this full draft you should at=20 >least do make sure you support Content-Disposition. Would it=20 >be helpful in that regard to make that part a separate draft??? I absolutely agree that implementations MUST support C-D (including the default value if C-D is not present). Regards, Christer > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >> Sent: 29. toukokuuta 2007 16:06 > >> To: Paul Kyzivat > >> Cc: Christer Holmberg (JO/LMF); sip@ietf.org > >> Subject: Re: [Sip] MIME: Nested bodies with option-tag? > >> > >> Hi, > >> > >> what I am hearing is that there are implementations out there that=20 > >> support multipart but not nested. Therefore, we need to decide two=20 > >> things: > >> > >> 1) do we want to have a MUST for multipart and a SHOULD=20 > for nested? I=20 > >> would say that we should have the same level (e.g., MUST, if we=20 > >> decided that MUST is appropriate) for both. > >> > >> 2) do we need a way for implementations that support multipart but=20 > >> not nested to be quickly updated to, at least, report that=20 > fact with=20 > >> an error response? This may make sense. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> Paul Kyzivat wrote: > >>> More or less repeating what I said before: > >>> > >>> I expect we do have to account in some way for=20 > implementations that=20 > >>> have already been deployed, in absence of a clarifying document. > >>> Exactly how we deal with that is still TBD. > >>> > >>> But as we define what is required to support this in the=20 > future, I=20 > >>> think there is *no* benefit to defining two levels of > >> support - full > >>> and partial. Anybody that sets out to provide support for this=20 > >>> document should be expected to do it all - its not that=20 > much harder. > >>> > >>> Paul > >>> > >>> Christer Holmberg (JO/LMF) wrote: > >>>> Hi, > >>>>> I wonder whether we should define an option-tag for the > >> support of > >>>>> nested bodies. > >>>>> > >>>>> I don't think there's a lot to be gained from defining such an=20 > >>>>> option-tag. The sender should already be aware that > >> there is a risk > >>>>> the recipient can't understand nested bodies, and have > >> arranged for > >>>>> suitable fallbacks. Conversely, the recipient should (at > >> least) be > >>>>> able to skip the nested multipart body part in the proper > >> "I don't > >>>>> understand this body part" way. All an option-tag would > >> do is allow > >>>>> the sender to not add a fallback. > >>>> In that case we need some specific text saying that if the > >> receiver > >>>> does not support nested multiparts it MUST do-this-and-do-that. > >>>> > >>>> Because, as I said earlier, I don't think we will=20 > achieve what we=20 > >>>> want by saying that one MUST be able to parse nested > >> multiparts. It > >>>> can be rather tricky to implement (depending on how the=20 > parser is=20 > >>>> implemented, though), and since there aren't really any > >> use-cases out > >>>> there yet I am pretty sure some people will choose not to > >> implement > >>>> it (and saying that people are not compliant in that=20 > case will not=20 > >>>> really help from an interop perspective). So, because of > >> that I think > >>>> it would be good not to mandate the support of nested > >> multiparts, but > >>>> to mandate appropriate behavior if not supported - just > >> like in any > >>>> other case when a MIME body contains an unsupported but > >> required content type. > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>>> sipping@ietf.org for new developments on the application of sip > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol Use=20 > >>>> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > >>>> sipping@ietf.org for new developments on the application of sip > >>>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >>> > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:28:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJXw-0003B2-Nu; Wed, 30 May 2007 04:28:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJXv-0003Al-3G for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJXu-0003Ad-Oz for sip@ietf.org; Wed, 30 May 2007 04:28:42 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJXt-0006eX-FN for sip@ietf.org; Wed, 30 May 2007 04:28:42 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7AED2070F; Wed, 30 May 2007 10:28:40 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-11-465d35b8d1cf Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C7079203FC; Wed, 30 May 2007 10:28:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:28:40 +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 Subject: RE: [Sip] Contact header in 1xx responses/updates remote target ornot? Date: Wed, 30 May 2007 10:28:39 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483C959@esealmw113.eemea.ericsson.se> In-Reply-To: <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contact header in 1xx responses/updates remote target ornot? thread-index: AcefhCpmVJKRFSw5Qo+laL0PscGfSgDDxq/g References: <4656BDFE.7020006@zesium.com><200705260454.l4Q4sYOV027172@dragon.ariadne.com> <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> From: "Christer Holmberg (JO/LMF)" To: "Jeroen van Bemmel" , , X-OriginalArrivalTime: 30 May 2007 08:28:40.0340 (UTC) FILETIME=[86C70D40:01C7A294] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, At least in RELIABLE provisinal responses Contact is required, in order to be able to send PRACK. One of the issues we've been discussing before is whether an UAC is allowed to send a non-CANCEL mid-dialog request once it has received an UNRELIABLE provisional response. I think the conclusion has been that it IS allowed, and in that case a Contact of course would be needed. Whether we want to mandate Contact in unreliable provisional responses or not is one issue, but as part of the new fix-the-bugs-in-3261 work item it would give us an opportunity to clarify the issue. Another, related, question which comes up every now and then: IF I receive a provisonal response with a Contact, is it allowed to "update" that Contact in the 200 OK (or, another reliable resonse)? Whatever the answer is, I think some clarification text would be useful.=20 Regards, Christer =20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: 26. toukokuuta 2007 13:52 > To: sip@ietf.org; Dale.Worley@comcast.net > Subject: Re: [Sip] Contact header in 1xx responses/updates=20 > remote target ornot? >=20 > Dale, >=20 > Not sure if I read your comment right, but RFC3261 12.2.1.2 says >=20 > When a UAC receives a 2xx response to a target refresh request, it > MUST replace the dialog's remote target URI with the URI from the > Contact header field in that response, if present. > It does not say anything about 1xx responses here=20 > though...Regards,Jeroen Dale.Worley@comcast.net wrote: > > From: Nina Garaca > >=20 > > Q1: Should I expect that these responses have a Contact header? > >=20 > > As Paul says, if it didn't have a Contact header, it couldn't=20 > > establish a dialog. > >=20 > > Q2: If they do so, should the remote target of the dialog be > > refreshed by that Contact at the side that has received that 1xx > > response and should the remote target of the dialog be=20 > refreshed by > > the Contact in the INVITE request at the side that has=20 > received that=20 > > INVITE? > >=20 > > Responses are not "target refresh requests", so they don't=20 > change the=20 > > target address at their end of the dialog. But of course, the=20 > > responses to the dialog-initiating request establish the initial=20 > > target address. > >=20 > > Q3: If not, should the remote target of the dialog be refreshed by > > the Contact in the INVITE request > > at the side that has received that INVITE and has sent dialog > > establishing 1xx response? > >=20 > > RFC 3261 section 12.2: > >=20 > > INVITE, the only target refresh request defined is re-INVITE (see > > Section 14). Other extensions may define different target refresh > > requests for dialogs established in other ways. > >=20 > > Dale > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJnQ-0004qJ-Cb; Wed, 30 May 2007 04:44:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJnO-0004n2-M7 for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJnO-0004k7-6q for sip@ietf.org; Wed, 30 May 2007 04:44:42 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJnN-0003Dd-Mj for sip@ietf.org; Wed, 30 May 2007 04:44:42 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4U8iPwM027299; Wed, 30 May 2007 03:44:38 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 03:44:38 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:44: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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Wed, 30 May 2007 10:44:21 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800120FE83@DEEXC1U01.de.lucent.com> In-Reply-To: <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? Thread-Index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DAABMy8AAAB1FNg References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se><465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> From: "DRAGE, Keith \(Keith\)" To: "Christer Holmberg \(JO/LMF\)" , "Gonzalo Camarillo \(JO/LMF\)" , "Paul Kyzivat" X-OriginalArrivalTime: 30 May 2007 08:44:35.0345 (UTC) FILETIME=[C0014010:01C7A296] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, at the moment, what I am trying to do is get some understanding of what we should scope as valid SIP work. We need to be able to understand why something that is clearly a generic problem for specification of nested MIME bodies merits a SIP specific solution. So: - is a generic solution already documented elsewhere? - if a generic solution is not documented elsewhere, should one be documented, rather than a specific SIP solution? Regards Keith > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, May 30, 2007 8:52 AM > To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat > Cc: sip@ietf.org > Subject: RE: [Sip] MIME: Nested bodies with option-tag? >=20 >=20 > Hi Keith,=20 >=20 > >Once we get down to a decision of supporting nested versus not=20 > >supporting nesting, presumably we are then entirely in the=20 > realm of the=20 > >multipart coding itself. > >=20 > >Could I ask someone to elaborate on what generic=20 > requirements already=20 > >exist within multipart/mime in this respect, before we start=20 > looking at=20 > >defining SIP specific rules or indications? >=20 > I am very sure that I have seen text related to the support=20 > of nested multiparts, and what nodes are expected to support,=20 > somewhere, but I yet have not found it. >=20 > Regards, >=20 > Christer >=20 >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, May 29, 2007 2:47 PM > > > To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] MIME: Nested bodies with option-tag? > > >=20 > > >=20 > > > Hi, > > >=20 > > > My main concern is not what wording (SHALL, MUST, etc) we use. > > >=20 > > > The issue is that I think we need text saying what=20 > implementations=20 > > > that DO NOT support alternative and/or nested shall do. If > > we say that > > > they shall reject the message I believe that many of the existing=20 > > > implementations will be compliant with the spec. > > >=20 > > > And, if we give the possibility to simply reject the message, I=20 > > > believe it will be easier to get people to change their=20 > > > implementations, if they currently simply discard > > alternative and/or > > > nested today. > > >=20 > > > Regards, > > >=20 > > > Christer > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > > Sent: 29. toukokuuta 2007 16:06 > > > > To: Paul Kyzivat > > > > Cc: Christer Holmberg (JO/LMF); sip@ietf.org > > > > Subject: Re: [Sip] MIME: Nested bodies with option-tag? > > > >=20 > > > > Hi, > > > >=20 > > > > what I am hearing is that there are implementations out > > there that > > > > support multipart but not nested. Therefore, we need to=20 > decide two > > > > things: > > > >=20 > > > > 1) do we want to have a MUST for multipart and a SHOULD for > > > nested? I > > > > would say that we should have the same level (e.g., MUST, if we=20 > > > > decided that MUST is appropriate) for both. > > > >=20 > > > > 2) do we need a way for implementations that support > > > multipart but not > > > > nested to be quickly updated to, at least, report that > > fact with an > > > > error response? This may make sense. > > > >=20 > > > > Cheers, > > > >=20 > > > > Gonzalo > > > >=20 > > > > Paul Kyzivat wrote: > > > > > More or less repeating what I said before: > > > > >=20 > > > > > I expect we do have to account in some way for > > > implementations that > > > > > have already been deployed, in absence of a=20 > clarifying document. > > > > > Exactly how we deal with that is still TBD. > > > > >=20 > > > > > But as we define what is required to support this in the > > > future, I > > > > > think there is *no* benefit to defining two levels of > > > > support - full > > > > > and partial. Anybody that sets out to provide support=20 > for this=20 > > > > > document should be expected to do it all - its not that > > > much harder. > > > > >=20 > > > > > Paul > > > > >=20 > > > > > Christer Holmberg (JO/LMF) wrote: > > > > >> Hi, > > > > >>> I wonder whether we should define an option-tag for the > > > > support of > > > > >>> nested bodies. > > > > >>> > > > > >>> I don't think there's a lot to be gained from > > defining such an > > > > >>> option-tag. The sender should already be aware that > > > > there is a risk > > > > >>> the recipient can't understand nested bodies, and have > > > > arranged for > > > > >>> suitable fallbacks. Conversely, the recipient should (at > > > > least) be > > > > >>> able to skip the nested multipart body part in the proper > > > > "I don't > > > > >>> understand this body part" way. All an option-tag would > > > > do is allow > > > > >>> the sender to not add a fallback. > > > > >> > > > > >> In that case we need some specific text saying that if the > > > > receiver > > > > >> does not support nested multiparts it MUST=20 > do-this-and-do-that. > > > > >> > > > > >> Because, as I said earlier, I don't think we will > > > achieve what we > > > > >> want by saying that one MUST be able to parse nested > > > > multiparts. It > > > > >> can be rather tricky to implement (depending on how the > > > parser is > > > > >> implemented, though), and since there aren't really any > > > > use-cases out > > > > >> there yet I am pretty sure some people will choose not to > > > > implement > > > > >> it (and saying that people are not compliant in that > > > case will not > > > > >> really help from an interop perspective). So, because of > > > > that I think > > > > >> it would be good not to mandate the support of nested > > > > multiparts, but > > > > >> to mandate appropriate behavior if not supported - just > > > > like in any > > > > >> other case when a MIME body contains an unsupported but > > > > required content type. > > > > >> > > > > >> Regards, > > > > >> > > > > >> Christer > > > > >> > > > > >> > > > > >> > > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >>> This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > >>> sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > >>> sipping@ietf.org for new developments on the > > application of sip > > > > >>> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >> This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > >> sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > >> sipping@ietf.org for new developments on the=20 > application of sip > > > > >> > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:53:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJvd-0007xh-IA; Wed, 30 May 2007 04:53:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJvc-0007xc-Iw for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJvc-0007xR-6u for sip@ietf.org; Wed, 30 May 2007 04:53:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJvb-0004ZL-7T for sip@ietf.org; Wed, 30 May 2007 04:53:12 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9BD752121D; Wed, 30 May 2007 10:53:10 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-59-465d3b7664c8 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 82A1121253; Wed, 30 May 2007 10:53:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:53:10 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:53:10 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B827C23F6; Wed, 30 May 2007 11:53:09 +0300 (EEST) Message-ID: <465D3B74.8060200@ericsson.com> Date: Wed, 30 May 2007 11:53:08 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se><465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FE83@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800120FE83@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 08:53:10.0265 (UTC) FILETIME=[F2EBCE90:01C7A297] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, what Keith says makes sense. I believe mandating support for multipart in SIP is a SIP-specific problem. Mandating suppport for multipart/alternative is also a SIP-specific problem, since a SIP-specific problem such as the transition to new session description formats depends on that. However, specifying if an implementation that supports multipart should support nested body parts or not is something more general on which the email folks have a lot of experience. Cheers, Gonzalo DRAGE, Keith (Keith) wrote: > Well, at the moment, what I am trying to do is get some understanding of > what we should scope as valid SIP work. > > We need to be able to understand why something that is clearly a generic > problem for specification of nested MIME bodies merits a SIP specific > solution. > > So: > > - is a generic solution already documented elsewhere? > > - if a generic solution is not documented elsewhere, should one be > documented, rather than a specific SIP solution? > > Regards > > Keith > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, May 30, 2007 8:52 AM > > To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat > > Cc: sip@ietf.org > > Subject: RE: [Sip] MIME: Nested bodies with option-tag? > > > > > > Hi Keith, > > > > >Once we get down to a decision of supporting nested versus not > > >supporting nesting, presumably we are then entirely in the > > realm of the > > >multipart coding itself. > > > > > >Could I ask someone to elaborate on what generic > > requirements already > > >exist within multipart/mime in this respect, before we start > > looking at > > >defining SIP specific rules or indications? > > > > I am very sure that I have seen text related to the support > > of nested multiparts, and what nodes are expected to support, > > somewhere, but I yet have not found it. > > > > Regards, > > > > Christer > > > > > > > > > > Regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: Tuesday, May 29, 2007 2:47 PM > > > > To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat > > > > Cc: sip@ietf.org > > > > Subject: RE: [Sip] MIME: Nested bodies with option-tag? > > > > > > > > > > > > Hi, > > > > > > > > My main concern is not what wording (SHALL, MUST, etc) we use. > > > > > > > > The issue is that I think we need text saying what > > implementations > > > > that DO NOT support alternative and/or nested shall do. If > > > we say that > > > > they shall reject the message I believe that many of the existing > > > > implementations will be compliant with the spec. > > > > > > > > And, if we give the possibility to simply reject the message, I > > > > believe it will be easier to get people to change their > > > > implementations, if they currently simply discard > > > alternative and/or > > > > nested today. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > > > > Sent: 29. toukokuuta 2007 16:06 > > > > > To: Paul Kyzivat > > > > > Cc: Christer Holmberg (JO/LMF); sip@ietf.org > > > > > Subject: Re: [Sip] MIME: Nested bodies with option-tag? > > > > > > > > > > Hi, > > > > > > > > > > what I am hearing is that there are implementations out > > > there that > > > > > support multipart but not nested. Therefore, we need to > > decide two > > > > > things: > > > > > > > > > > 1) do we want to have a MUST for multipart and a SHOULD for > > > > nested? I > > > > > would say that we should have the same level (e.g., MUST, if we > > > > > decided that MUST is appropriate) for both. > > > > > > > > > > 2) do we need a way for implementations that support > > > > multipart but not > > > > > nested to be quickly updated to, at least, report that > > > fact with an > > > > > error response? This may make sense. > > > > > > > > > > Cheers, > > > > > > > > > > Gonzalo > > > > > > > > > > Paul Kyzivat wrote: > > > > > > More or less repeating what I said before: > > > > > > > > > > > > I expect we do have to account in some way for > > > > implementations that > > > > > > have already been deployed, in absence of a > > clarifying document. > > > > > > Exactly how we deal with that is still TBD. > > > > > > > > > > > > But as we define what is required to support this in the > > > > future, I > > > > > > think there is *no* benefit to defining two levels of > > > > > support - full > > > > > > and partial. Anybody that sets out to provide support > > for this > > > > > > document should be expected to do it all - its not that > > > > much harder. > > > > > > > > > > > > Paul > > > > > > > > > > > > Christer Holmberg (JO/LMF) wrote: > > > > > >> Hi, > > > > > >>> I wonder whether we should define an option-tag for the > > > > > support of > > > > > >>> nested bodies. > > > > > >>> > > > > > >>> I don't think there's a lot to be gained from > > > defining such an > > > > > >>> option-tag. The sender should already be aware that > > > > > there is a risk > > > > > >>> the recipient can't understand nested bodies, and have > > > > > arranged for > > > > > >>> suitable fallbacks. Conversely, the recipient should (at > > > > > least) be > > > > > >>> able to skip the nested multipart body part in the proper > > > > > "I don't > > > > > >>> understand this body part" way. All an option-tag would > > > > > do is allow > > > > > >>> the sender to not add a fallback. > > > > > >> > > > > > >> In that case we need some specific text saying that if the > > > > > receiver > > > > > >> does not support nested multiparts it MUST > > do-this-and-do-that. > > > > > >> > > > > > >> Because, as I said earlier, I don't think we will > > > > achieve what we > > > > > >> want by saying that one MUST be able to parse nested > > > > > multiparts. It > > > > > >> can be rather tricky to implement (depending on how the > > > > parser is > > > > > >> implemented, though), and since there aren't really any > > > > > use-cases out > > > > > >> there yet I am pretty sure some people will choose not to > > > > > implement > > > > > >> it (and saying that people are not compliant in that > > > > case will not > > > > > >> really help from an interop perspective). So, because of > > > > > that I think > > > > > >> it would be good not to mandate the support of nested > > > > > multiparts, but > > > > > >> to mandate appropriate behavior if not supported - just > > > > > like in any > > > > > >> other case when a MIME body contains an unsupported but > > > > > required content type. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Christer > > > > > >> > > > > > >> > > > > > >> > > > > > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > >>> This list is for NEW development of the core SIP > > Protocol Use > > > > > >>> sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > >>> sipping@ietf.org for new developments on the > > > application of sip > > > > > >>> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > >> This list is for NEW development of the core SIP > > Protocol Use > > > > > >> sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > >> sipping@ietf.org for new developments on the > > application of sip > > > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP Protocol Use > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use > > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 04:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJz3-0003OV-EG; Wed, 30 May 2007 04:56:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtJz1-0003Lj-I4 for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:56:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJz1-0003Lb-8O for sip@ietf.org; Wed, 30 May 2007 04:56:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJz0-00054s-IJ for sip@ietf.org; Wed, 30 May 2007 04:56:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E8FB020829; Wed, 30 May 2007 10:56:41 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-74-465d3c492b8d Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CDD9520419; Wed, 30 May 2007 10:56:41 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:56:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:56:37 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CAFDC23F6; Wed, 30 May 2007 11:56:36 +0300 (EEST) Message-ID: <465D3C43.2090806@ericsson.com> Date: Wed, 30 May 2007 11:56:35 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <093d01c7a228$db7a85e0$c6f0200a@amer.cisco.com> In-Reply-To: <093d01c7a228$db7a85e0$c6f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 08:56:37.0163 (UTC) FILETIME=[6E3DEFB0:01C7A298] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, 'Paul Kyzivat' , 'Francois Audet' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dan, thanks for the pointers. It seems that we want to specify that, for multipart/alternative bodies whose content disposition is "session" (or early session), the content-types of all body parts MUST be different. However, multipart/alternative bodies with a different disposition type should follow the general MIME rules. Cheers, Gonzalo Dan Wing wrote: > Paul Kyzivat wrote: > ... >>> OPEN ISSUE 2: we know that we do not want two SDPs in a >>> 'multipart/ >>> alternative', but is this valid generally with any content type? >>> Would it be possible to provide two alternative body >>> parts using the >>> same format and, thus, the same content type but in, >>> say, different >>> languages? >> Its my understanding that the distinction is based on which can be >> understood, relative to Content-Type. It isn't apparent to me that >> making this decision based on other attributes is valid. For >> one thing the parts are supposed to be ordered by increasing >> richness. If they differed by language this wouldn't be true. > > Multipart/alternative is the best we have, though. And who is to say that > image/jpeg is richer than image/gif, or that english is richer than latin? > > Anyway, the following RFCs standardize the use of Content-Language and refer > to using multipart/alternative when providing support for multiple > languages: > > http://tools.ietf.org/html/rfc3282 > http://tools.ietf.org/html/rfc3066 > > -d > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 05:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKAq-0002jQ-GM; Wed, 30 May 2007 05:08:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtKAo-0002jF-OW for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKAo-0002j7-Ea for sip@ietf.org; Wed, 30 May 2007 05:08:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKAm-00086d-Tw for sip@ietf.org; Wed, 30 May 2007 05:08:54 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 626622052F for ; Wed, 30 May 2007 11:08:52 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-78-465d3f2439c6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4FC8120884 for ; Wed, 30 May 2007 11:08:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:08:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 May 2007 11:08:51 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483CB37@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: Partial body types thread-index: AceimiQNrnKsEi3vQZy2VldcP4t+og== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 30 May 2007 09:08:51.0778 (UTC) FILETIME=[241B4A20:01C7A29A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: Partial body types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0083272154==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0083272154== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A29A.24278A09" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A29A.24278A09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think we should also mention 'partial' in the spec. I would propose that we group it with the types (parallel, digest, etc) that would require an option-tag. Regards, Christer ------_=_NextPart_001_01C7A29A.24278A09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME: Partial body types

Hi,

I think we should also mention = 'partial' in the spec. I would propose that we group it with the types = (parallel, digest, etc) that would require an option-tag.

Regards,

Christer

------_=_NextPart_001_01C7A29A.24278A09-- --===============0083272154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0083272154==-- From sip-bounces@ietf.org Wed May 30 05:15:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKGj-0005Bv-L9; Wed, 30 May 2007 05:15:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtKGh-0005A8-RR for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKGh-00059y-HZ for sip@ietf.org; Wed, 30 May 2007 05:14:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKGf-0001H8-WA for sip@ietf.org; Wed, 30 May 2007 05:14:59 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7B85720F22 for ; Wed, 30 May 2007 11:14:57 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-11-465d40910b29 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6C36B20141 for ; Wed, 30 May 2007 11: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.1830); Wed, 30 May 2007 11:14:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 May 2007 11:14:55 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483CB6C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: External-body body types thread-index: Aceimv0gf0r3ERiSRKOJea0WY6GRfA== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 30 May 2007 09:14:56.0077 (UTC) FILETIME=[FD3EE7D0:01C7A29A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: External-body body types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0647142555==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0647142555== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A29A.FD36B0C6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A29A.FD36B0C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One thing I think we should study a little more is the usage of 'external-body'. It can be used to indicate references to bodies located elsewhere then in the SIP message itself, so maybe there could be some potential usage for it.=20 We also have SIP headers (e.g. Alert-Info) which can be used for similar things, so... If we don't want to allow it, it would be good to also explicitly add it to the list of body types which would require an option-tag. Regards, Christer ------_=_NextPart_001_01C7A29A.FD36B0C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME: External-body body types

Hi,

One thing I think we should study a = little more is the usage of 'external-body'.

It can be used to indicate references = to bodies located elsewhere then in the SIP message itself, so maybe = there could be some potential usage for it.

We also have SIP headers (e.g. = Alert-Info) which can be used for similar things, so...

If we don't want to allow it, it would = be good to also explicitly add it to the list of body types which would = require an option-tag.

Regards,

Christer

------_=_NextPart_001_01C7A29A.FD36B0C6-- --===============0647142555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0647142555==-- From sip-bounces@ietf.org Wed May 30 05:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKIU-0006S2-Bg; Wed, 30 May 2007 05:16:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtKIS-0006Rk-CM for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKIS-0006RZ-1w for sip@ietf.org; Wed, 30 May 2007 05:16:48 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKIQ-0001gC-9t for sip@ietf.org; Wed, 30 May 2007 05:16:48 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB70F2006D for ; Wed, 30 May 2007 11:16:45 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-1c-465d40fd8d8d Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B64382022C for ; Wed, 30 May 2007 11:16:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:16:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:16:45 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 38E6F23F6; Wed, 30 May 2007 12:16:45 +0300 (EEST) Message-ID: <465D40FB.5000805@ericsson.com> Date: Wed, 30 May 2007 12:16:43 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" References: <7374777208BDC7449D5620EF942325670483CB6C@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670483CB6C@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 09:16:45.0138 (UTC) FILETIME=[3E404B20:01C7A29B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip@ietf.org Subject: [Sip] Re: MIME: External-body body types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, external body is not a multipart subtype. It it a message subtype. This draft deals with multipart subtypes. Cheers, Gonzalo Christer Holmberg (JO/LMF) wrote: > > Hi, > > One thing I think we should study a little more is the usage of > 'external-body'. > > It can be used to indicate references to bodies located elsewhere then > in the SIP message itself, so maybe there could be some potential usage > for it. > > We also have SIP headers (e.g. Alert-Info) which can be used for similar > things, so... > > If we don't want to allow it, it would be good to also explicitly add it > to the list of body types which would require an option-tag. > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 05:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKIh-0006eH-G5; Wed, 30 May 2007 05:17:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtKIf-0006dw-Ip for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKIf-0006do-8Q for sip@ietf.org; Wed, 30 May 2007 05:17:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKId-0001jb-R6 for sip@ietf.org; Wed, 30 May 2007 05:17:01 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4E2EC20254 for ; Wed, 30 May 2007 11:16:59 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-31-465d410b3bc8 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3E8652022C for ; Wed, 30 May 2007 11:16:59 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:16:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:16:58 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BAF66259C; Wed, 30 May 2007 12:16:58 +0300 (EEST) Message-ID: <465D410A.5050205@ericsson.com> Date: Wed, 30 May 2007 12:16:58 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" References: <7374777208BDC7449D5620EF942325670483CB37@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670483CB37@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 09:16:58.0763 (UTC) FILETIME=[465F4DB0:01C7A29B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org Subject: [Sip] Re: MIME: Partial body types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, partial is not a multipart subtype. It it a message subtype. This draft deals with multipart subtypes. Cheers, Gonzalo Christer Holmberg (JO/LMF) wrote: > > Hi, > > I think we should also mention 'partial' in the spec. I would propose > that we group it with the types (parallel, digest, etc) that would > require an option-tag. > > Regards, > > Christer > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 05:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKLf-00019G-FM; Wed, 30 May 2007 05:20:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtKLd-000192-JQ for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKLd-00018u-9Y for sip@ietf.org; Wed, 30 May 2007 05:20:05 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKLb-00030J-Rt for sip@ietf.org; Wed, 30 May 2007 05:20:05 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 565622057D for ; Wed, 30 May 2007 11:20:03 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-71-465d41c3c9b1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 489012088F for ; Wed, 30 May 2007 11:20:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 11:20: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, 30 May 2007 11:20:02 +0200 Message-ID: <7374777208BDC7449D5620EF942325670483CBAC@esealmw113.eemea.ericsson.se> In-Reply-To: <465D40FB.5000805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: External-body body types thread-index: Aceim0GlUYN7ojSSQnuTp/cH7Lqp8QAAEIqQ References: <7374777208BDC7449D5620EF942325670483CB6C@esealmw113.eemea.ericsson.se> <465D40FB.5000805@ericsson.com> From: "Christer Holmberg (JO/LMF)" To: "Gonzalo Camarillo (JO/LMF)" X-OriginalArrivalTime: 30 May 2007 09:20:02.0915 (UTC) FILETIME=[B422AB30:01C7A29B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org Subject: [Sip] RE: MIME: External-body body types X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correct. Sorry for that. I guess the same applies to my other mail regarding the partial subtype. The question is whether we also need to say something about message subtypes, but if we think it should be done in another document I won't argue against that. Regards, Christer=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 30. toukokuuta 2007 12:17 > To: Christer Holmberg (JO/LMF) > Cc: sip@ietf.org > Subject: Re: MIME: External-body body types >=20 > Hi Christer, >=20 > external body is not a multipart subtype. It it a message=20 > subtype. This draft deals with multipart subtypes. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 >=20 > Christer Holmberg (JO/LMF) wrote: > >=20 > > Hi, > >=20 > > One thing I think we should study a little more is the usage of=20 > > 'external-body'. > >=20 > > It can be used to indicate references to bodies located=20 > elsewhere then=20 > > in the SIP message itself, so maybe there could be some potential=20 > > usage for it. > >=20 > > We also have SIP headers (e.g. Alert-Info) which can be used for=20 > > similar things, so... > >=20 > > If we don't want to allow it, it would be good to also=20 > explicitly add=20 > > it to the list of body types which would require an option-tag. > >=20 > > Regards, > >=20 > > Christer > >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 07:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLxY-00088E-MU; Wed, 30 May 2007 07:03:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtLxX-000884-O5 for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 07:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLxX-00087w-Bs for sip@ietf.org; Wed, 30 May 2007 07:03:19 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtLxV-0003bj-R9 for sip@ietf.org; Wed, 30 May 2007 07:03:19 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 26A51210F1 for ; Wed, 30 May 2007 13:03:17 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-76-465d59f518df Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1901520222 for ; Wed, 30 May 2007 13:03:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:03:15 +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, 30 May 2007 13:03:15 +0200 Message-ID: <7374777208BDC7449D5620EF94232567048BC560@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: MIME when only one body type thread-index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEg== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 30 May 2007 11:03:16.0293 (UTC) FILETIME=[1FAD2750:01C7A2AA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: MIME when only one body type X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Chapter 3.2 of Gonzalo's draft says: "UAs should avoid unnecessarily nesting body parts. Therefore, UAs SHOULD NOT use a 'multipart' body when there is only one body part." However, chapter 5.1.1 of RFC2046 says: "NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types." So, I think we need to add some words saying that it can be useful in some cases. For example, I THINK I have seen INFO requests with encapsulated ISUP messages inside a MIME body, eventhough the message doesn't contain any other body types. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 07:10:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtM4Y-0003xV-SO; Wed, 30 May 2007 07:10:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtM4W-0003xO-OV for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 07:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtM4W-0003xG-Cq for sip@ietf.org; Wed, 30 May 2007 07:10:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtM4U-0004Qr-VD for sip@ietf.org; Wed, 30 May 2007 07:10:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6F660212EA for ; Wed, 30 May 2007 13:10:30 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-09-465d5ba66ca8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 62EDD2101C for ; Wed, 30 May 2007 13:10:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:10: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, 30 May 2007 13:10:29 +0200 Message-ID: <7374777208BDC7449D5620EF94232567048BC59C@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIME: binary data thread-index: AceiqyH1ZMfNmXwDQliwppKNoxJfvQ== From: "Christer Holmberg (JO/LMF)" To: X-OriginalArrivalTime: 30 May 2007 11:10:29.0929 (UTC) FILETIME=[2224C190:01C7A2AB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "Gonzalo Camarillo \(JO/LMF\)" Subject: [Sip] MIME: binary data X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, When I was looking at RFC3204 I found the following text in chapter 3 (note the 2 last sentences): "ISUP and QSIG messages are composed of arbitrary binary data that is transparent to SIP processing. The best way to encode these is to use binary encoding. This is in conformance with the restrictions imposed on the use of binary data for MIME (RFC 2045 [3]). It should be noted that the rules mentioned in the RFC 2045 apply to Internet mail messages and not to SIP messages. Binary has been preferred over Base64 encoding because the latter would only result in adding bulk to the encoded messages and possibly be more costly in terms of processing power." Now, if this text is not specific to ISUP and QSIG, but to binary data in general, I think it needs to be documented in Gonzalo's draft. Because, it seems to be one example of where we "override" the generic MIME rules (I haven't check, but the text says that some rules in RFC2045 does not apply to SIP...).=20 Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 14:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTOE-0000s8-Qy; Wed, 30 May 2007 14:59:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtTOD-0000ry-JV for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 14:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTOD-0000rj-9e for sip@ietf.org; Wed, 30 May 2007 14:59:21 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTOC-0000Ro-1J for sip@ietf.org; Wed, 30 May 2007 14:59:21 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070530185918m13000ca5qe>; Wed, 30 May 2007 18:59:19 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4UIxH8t000625 for ; Wed, 30 May 2007 14:59:17 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4UIxHVR000621; Wed, 30 May 2007 14:59:17 -0400 Date: Wed, 30 May 2007 14:59:17 -0400 Message-Id: <200705301859.l4UIxHVR000621@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <7374777208BDC7449D5620EF94232567048BC59C@esealmw113.eemea.ericsson.se> (christer.holmberg@ericsson.com) Subject: Re: [Sip] MIME: binary data References: <7374777208BDC7449D5620EF94232567048BC59C@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg (JO/LMF)" Now, if this text is not specific to ISUP and QSIG, but to binary data in general, I think it needs to be documented in Gonzalo's draft. Because, it seems to be one example of where we "override" the generic MIME rules (I haven't check, but the text says that some rules in RFC2045 does not apply to SIP...). Well, we probably should document it. But SIP is not an exception, *e-mail* is, as far as I can tell from scanning through 2045: Mail transport for unencoded 8bit data is defined in RFC 1652. As of the initial publication of this document, there are no standardized Internet mail transports for which it is legitimate to include unencoded binary data in mail bodies. Thus there are no circumstances in which the "binary" Content-Transfer-Encoding is actually valid in Internet mail. However, in the event that binary mail transport becomes a reality in Internet mail, or when MIME is used in conjunction with any other binary-capable mail transport mechanism, binary bodies must be labelled as such using this mechanism. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 15:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTuz-0001VQ-Kr; Wed, 30 May 2007 15:33:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtTux-0001Mo-RK for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTux-0001Lb-Gp for sip@ietf.org; Wed, 30 May 2007 15:33:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTux-0001PI-5F for sip@ietf.org; Wed, 30 May 2007 15:33:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 30 May 2007 12:33:12 -0700 X-IronPort-AV: i="4.14,594,1170662400"; d="scan'208"; a="376563145:sNHT46522426" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4UJXA8j030386; Wed, 30 May 2007 12:33:10 -0700 Received: from dwingwxp ([128.107.103.16]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4UJX920016898; Wed, 30 May 2007 19:33:10 GMT From: "Dan Wing" To: "'Gonzalo Camarillo'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 30 May 2007 12:33:11 -0700 Message-ID: <000001c7a2f1$5bd8ee70$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceimHOC9fbT/rgkSNK/u3xaWihX3gATJssg In-Reply-To: <465D3C43.2090806@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2745; t=1180553590; x=1181417590; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=afH02WEeW+zzWUmE3nZ3Y4eDy3JvsGLI5QH1Qk7ViHg=; b=Bkyl7RrQ0XUSgg9LAIUAl8F2vL9ZudeVzQ+49zVdpqqasD/auiKs8qS0ysvV4BSXFvzbpsXh Bi0a+AJJQUjbz//iRMTzwofIhg6iLzbeucPd66RpXY47+QPvllxOdPj6; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: sip@ietf.org, 'Paul Kyzivat' , 'Francois Audet' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Wednesday, May 30, 2007 1:57 AM > To: Dan Wing > Cc: 'Paul Kyzivat'; 'Francois Audet'; sip@ietf.org; 'Christer > Holmberg (JO/LMF)' > Subject: Re: [Sip] Support for Multipart/MIME > > Hi Dan, > > thanks for the pointers. It seems that we want to specify that, for > multipart/alternative bodies whose content disposition is > "session" (or > early session), the content-types of all body parts MUST be different. > > However, multipart/alternative bodies with a different > disposition type should follow the general MIME rules. Yes, I concur. You also brought up an interesting point with language. One Might Consider it reasonable to have multipart/alternative, with several application/sdp parts which differ in language (and probably different m/c lines). Your document should probably provide a pointer to SDP's a=lang and guidance towards its use in conjunction with SDP Capability Negotiation. Sortof a 'you might be tempted to use MIME constructs where SDP should be used instead'. That is, if there is agreement that a=lang and SDP Capability Negotiation is the right way to select language. (I'm thinking of situations where, for example, you want to send an offer for an English, German, or French announcement ("The dam broke, please evacuate to higher ground") or an IVR or a human telephone operator). -d > Cheers, > > Gonzalo > > > Dan Wing wrote: > > Paul Kyzivat wrote: > > ... > >>> OPEN ISSUE 2: we know that we do not want two SDPs in a > >>> 'multipart/ > >>> alternative', but is this valid generally with any > content type? > >>> Would it be possible to provide two alternative body > >>> parts using the > >>> same format and, thus, the same content type but in, > >>> say, different > >>> languages? > >> Its my understanding that the distinction is based on which can be > >> understood, relative to Content-Type. It isn't apparent to me that > >> making this decision based on other attributes is valid. For > >> one thing the parts are supposed to be ordered by increasing > >> richness. If they differed by language this wouldn't be true. > > > > Multipart/alternative is the best we have, though. And who > is to say that > > image/jpeg is richer than image/gif, or that english is > richer than latin? > > > > Anyway, the following RFCs standardize the use of > Content-Language and refer > > to using multipart/alternative when providing support for multiple > > languages: > > > > http://tools.ietf.org/html/rfc3282 > > http://tools.ietf.org/html/rfc3066 > > > > -d > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 15:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTxK-0002Al-Dg; Wed, 30 May 2007 15:35:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtTxI-0002Ag-KE for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTxI-0002AY-Ab for sip@ietf.org; Wed, 30 May 2007 15:35:36 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTxH-000293-1M for sip@ietf.org; Wed, 30 May 2007 15:35:36 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 May 2007 12:35:34 -0700 X-IronPort-AV: i="4.14,594,1170662400"; d="scan'208"; a="1307938:sNHT20224908" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4UJZY6Z028824; Wed, 30 May 2007 12:35:34 -0700 Received: from dwingwxp ([128.107.103.16]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4UJZX20019076; Wed, 30 May 2007 19:35:33 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'DRAGE, Keith \(Keith\)'" , "'Gonzalo Camarillo \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Wed, 30 May 2007 12:35:35 -0700 Message-ID: <000201c7a2f1$b18240b0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DAABMy8AAAWbkUQ In-Reply-To: <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1439; t=1180553734; x=1181417734; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20; bh=ivgO4lS3xLKKBANAJH/LRUp8ZizcUGeKpPeVmnwBDTQ=; b=s3CbmhDfqlhiOe7r9Hz0i9VelrX1MvWY578CBjslv7FAyG25g+4l4vk17QHhWbd60N3uxu+I RJh3EDtUillBo/heOq4qRx4PIIyGUn84KEIlcg7Ed7W2+bYJSk1mV/g82rEKVor0Oq3kT8tGuN FCfU2ulNj4OrEaNl5yf2wIhAQ=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >Once we get down to a decision of supporting nested versus > >not supporting nesting, presumably we are then entirely in > >the realm of the multipart coding itself. > > > >Could I ask someone to elaborate on what generic requirements > >already exist within multipart/mime in this respect, before > >we start looking at defining SIP specific rules or indications? > > I am very sure that I have seen text related to the support of nested > multiparts, and what nodes are expected to support, > somewhere, but I yet have not found it. message/rfc822 [RFC2046], which is used when you forward a message, routinely has nested multiparts when the message you're forwarding itself had multiple parts. It looks something like this: From: dwing@cisco.com To: bill@example.com Content-Type: multipart/mixed; boundary=A --A Content-Type: text/plain here is that email I mentioned during lunch. --A Content-Type: message/rfc822 From: Sammy Sammython Content-Type: multipart/mixed; boundary=B Subject: Pictures from our recent trip --B Content-Type: text/plain Here are the pictures from the island! Enjoy! --B Content-Type: image/jpg Content-Transfer-Encoding: base64 EKFEJKFIEUJKEJKEJFF ... --B Content-Type: image/jpg Content-Transfer-Encoding: base64 EKFEJKFIEUJKEJKEJFF ... --B-- --A-- -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 15:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU7N-0007TY-1n; Wed, 30 May 2007 15:46:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtU7L-0007TT-L4 for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU7L-0007TL-BK for sip@ietf.org; Wed, 30 May 2007 15:45:59 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtU7J-0005H5-9t for sip@ietf.org; Wed, 30 May 2007 15:45:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 May 2007 12:45:35 -0700 X-IronPort-AV: i="4.14,594,1170662400"; d="scan'208"; a="489422745:sNHT2465143552" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4UJjZIs015501; Wed, 30 May 2007 12:45:35 -0700 Received: from dwingwxp ([128.107.103.16]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4UJjZtV028323; Wed, 30 May 2007 19:45:35 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] MIME: MIME when only one body type Date: Wed, 30 May 2007 12:45:36 -0700 Message-ID: <000301c7a2f3$17ff7a00$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3g In-Reply-To: <7374777208BDC7449D5620EF94232567048BC560@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1228; t=1180554335; x=1181418335; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20MIME=3A=20MIME=20when=20only=20one=20body=20t ype |Sender:=20; bh=4q8S7YdvgR3wtVD4s5mh11pSeJFqy+S27Ndu3GIxBbU=; b=FKv1OBWdYpGM2cvfEXn9Lr30FIoqJv1gCM278CPITLEI8wY8HcnRz0KSMKmJ6EDf9AyQG8NP K7mFKlZVW5D3MRsuNPoSD3+o9AwFN9XkHPC8Y/3QWWJzfIARXnYulJ4T; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "'Gonzalo Camarillo \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Hi, > > Chapter 3.2 of Gonzalo's draft says: > > "UAs should avoid unnecessarily nesting body parts. Therefore, UAs > SHOULD NOT use a 'multipart' body when there is only one body part." > > However, chapter 5.1.1 of RFC2046 says: > > "NOTE: Experience has shown that a "multipart" media type with a > single body part is useful for sending non-text media types." The only reason I could see it being useful for email was when you're sending the message to a non-MIME-aware mail user agent, and you included a MIME prologue: From: dwing@cisco.com Content-Type: multipart/mixed; boundary=A You are reading this message with a mailer that doesn't understand MIME. To review the attached content, use 'metamail'. --A Content-Type: image/jpg Content-Transfer-Encoding: base64 EJKF3849efjkej... --A-- > So, I think we need to add some words saying that it can be useful in > some cases. Unless there is another case that it's useful for SIP, I think it could only harm interoperability. > For example, I THINK I have seen INFO requests with encapsulated ISUP > messages inside a MIME body, eventhough the message doesn't > contain any other body types. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 18:10:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWMu-0000VV-KE; Wed, 30 May 2007 18:10:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtWMt-0000SU-6U for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 18:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWMs-0000SM-Se for sip@ietf.org; Wed, 30 May 2007 18:10:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtWMq-0007Wx-G1 for sip@ietf.org; Wed, 30 May 2007 18:10:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2007 18:10:08 -0400 X-IronPort-AV: i="4.14,595,1170651600"; d="scan'208"; a="61552212:sNHT46832958" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4UMA8LC031132; Wed, 30 May 2007 18:10:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4UMA45f024831; Wed, 30 May 2007 22:10:08 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.1830); Wed, 30 May 2007 18:10:04 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 18:10:03 -0400 Message-ID: <465DF63A.4040307@cisco.com> Date: Wed, 30 May 2007 18:10:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [Sip] Support for Multipart/MIME References: <000001c7a2f1$5bd8ee70$10676b80@amer.cisco.com> In-Reply-To: <000001c7a2f1$5bd8ee70$10676b80@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 22:10:03.0547 (UTC) FILETIME=[45DBA6B0:01C7A307] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3092; t=1180563008; x=1181427008; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Support=20for=20Multipart/MIME |Sender:=20 |To:=20Dan=20Wing=20; bh=9t8KjJQFGkbZxQcOZp2rdykj8C+5U7r+UMTxj7vhn0g=; b=H5E06bDDTy905GZiMkyKMvi2JKlYN+PteS17mHxDitVDBUMfZiHXbfyt5l3pfltThm3sRdek VhLNKUOEXKr5DlCVn7UKA4zlOvU2WChAiB71fqFn5rlgqCCsFSIJW8os; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org, 'Francois Audet' , 'Gonzalo Camarillo' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dan, If I follow what you are saying then I disagree with the use case. I believe the Content-Language specifies the language of the text in the body part, not the language that might be conveyed in a media stream that is negotiated by the SDP in the body part. Paul Dan Wing wrote: > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Wednesday, May 30, 2007 1:57 AM >> To: Dan Wing >> Cc: 'Paul Kyzivat'; 'Francois Audet'; sip@ietf.org; 'Christer >> Holmberg (JO/LMF)' >> Subject: Re: [Sip] Support for Multipart/MIME >> >> Hi Dan, >> >> thanks for the pointers. It seems that we want to specify that, for >> multipart/alternative bodies whose content disposition is >> "session" (or >> early session), the content-types of all body parts MUST be different. >> >> However, multipart/alternative bodies with a different >> disposition type should follow the general MIME rules. > > Yes, I concur. > > You also brought up an interesting point with language. One Might Consider > it reasonable to have multipart/alternative, with several application/sdp > parts which differ in language (and probably different m/c lines). Your > document should probably provide a pointer to SDP's a=lang and guidance > towards its use in conjunction with SDP Capability Negotiation. Sortof a > 'you might be tempted to use MIME constructs where SDP should be used > instead'. That is, if there is agreement that a=lang and SDP Capability > Negotiation is the right way to select language. > > (I'm thinking of situations where, for example, you want to send an offer > for an English, German, or French announcement ("The dam broke, please > evacuate to higher ground") or an IVR or a human telephone operator). > > -d > >> Cheers, >> >> Gonzalo >> >> >> Dan Wing wrote: >>> Paul Kyzivat wrote: >>> ... >>>>> OPEN ISSUE 2: we know that we do not want two SDPs in a >>>>> 'multipart/ >>>>> alternative', but is this valid generally with any >> content type? >>>>> Would it be possible to provide two alternative body >>>>> parts using the >>>>> same format and, thus, the same content type but in, >>>>> say, different >>>>> languages? >>>> Its my understanding that the distinction is based on which can be >>>> understood, relative to Content-Type. It isn't apparent to me that >>>> making this decision based on other attributes is valid. For >>>> one thing the parts are supposed to be ordered by increasing >>>> richness. If they differed by language this wouldn't be true. >>> Multipart/alternative is the best we have, though. And who >> is to say that >>> image/jpeg is richer than image/gif, or that english is >> richer than latin? >>> Anyway, the following RFCs standardize the use of >> Content-Language and refer >>> to using multipart/alternative when providing support for multiple >>> languages: >>> >>> http://tools.ietf.org/html/rfc3282 >>> http://tools.ietf.org/html/rfc3066 >>> >>> -d >>> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 20:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtY87-0003EW-Ac; Wed, 30 May 2007 20:03:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtY86-0003ER-DP for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 20:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtY86-0003EH-3Y for sip@ietf.org; Wed, 30 May 2007 20:03:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtY85-0005sO-Nj for sip@ietf.org; Wed, 30 May 2007 20:03:02 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 May 2007 17:03:01 -0700 X-IronPort-AV: i="4.14,595,1170662400"; d="scan'208"; a="159161759:sNHT46061442" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4V031Ag030624; Wed, 30 May 2007 17:03:01 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4V02tV1024672; Thu, 31 May 2007 00:02:56 GMT From: "Dan Wing" To: "'Paul Kyzivat'" Subject: RE: [Sip] Support for Multipart/MIME Date: Wed, 30 May 2007 17:02:55 -0700 Message-ID: <02aa01c7a317$0d8a4810$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcejB0YgCjtKo1KSSW2Zxp6VMRa26AAD7EYA In-Reply-To: <465DF63A.4040307@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3761; t=1180569781; x=1181433781; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=h+Aao1lKXkzzU5xo0VEjPiP2RBGOX/807BhKxQjQXw8=; b=MpdjZE3hnmjCY/ZSGLbFFzaTl+LA9Ys64ERvA+E3hn4agXQcUcemJuzqOS+Hq0TTmwXjOVTR ElmSgGVqJfCRtsw4ReE2g0Mpkp2gzYE5u5Sum4N3d8u2niC+Gx7Q93AF; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sip@ietf.org, 'Francois Audet' , 'Gonzalo Camarillo' , "'Christer Holmberg \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm fine with that interpretation, too, because it keeps us away from using MIME to negotiate and we keep negotiation in SDP (and SDP Cap Neg). -d > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, May 30, 2007 3:10 PM > To: Dan Wing > Cc: 'Gonzalo Camarillo'; 'Francois Audet'; sip@ietf.org; > 'Christer Holmberg (JO/LMF)' > Subject: Re: [Sip] Support for Multipart/MIME > > Dan, > > If I follow what you are saying then I disagree with the use case. > > I believe the Content-Language specifies the language of the > text in the > body part, not the language that might be conveyed in a media stream > that is negotiated by the SDP in the body part. > > Paul > > Dan Wing wrote: > > > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >> Sent: Wednesday, May 30, 2007 1:57 AM > >> To: Dan Wing > >> Cc: 'Paul Kyzivat'; 'Francois Audet'; sip@ietf.org; 'Christer > >> Holmberg (JO/LMF)' > >> Subject: Re: [Sip] Support for Multipart/MIME > >> > >> Hi Dan, > >> > >> thanks for the pointers. It seems that we want to specify > that, for > >> multipart/alternative bodies whose content disposition is > >> "session" (or > >> early session), the content-types of all body parts MUST > be different. > >> > >> However, multipart/alternative bodies with a different > >> disposition type should follow the general MIME rules. > > > > Yes, I concur. > > > > You also brought up an interesting point with language. > One Might Consider > > it reasonable to have multipart/alternative, with several > application/sdp > > parts which differ in language (and probably different m/c > lines). Your > > document should probably provide a pointer to SDP's a=lang > and guidance > > towards its use in conjunction with SDP Capability > Negotiation. Sortof a > > 'you might be tempted to use MIME constructs where SDP > should be used > > instead'. That is, if there is agreement that a=lang and > SDP Capability > > Negotiation is the right way to select language. > > > > (I'm thinking of situations where, for example, you want to > send an offer > > for an English, German, or French announcement ("The dam > broke, please > > evacuate to higher ground") or an IVR or a human telephone > operator). > > > > -d > > > >> Cheers, > >> > >> Gonzalo > >> > >> > >> Dan Wing wrote: > >>> Paul Kyzivat wrote: > >>> ... > >>>>> OPEN ISSUE 2: we know that we do not want two SDPs in a > >>>>> 'multipart/ > >>>>> alternative', but is this valid generally with any > >> content type? > >>>>> Would it be possible to provide two alternative body > >>>>> parts using the > >>>>> same format and, thus, the same content type but in, > >>>>> say, different > >>>>> languages? > >>>> Its my understanding that the distinction is based on > which can be > >>>> understood, relative to Content-Type. It isn't apparent > to me that > >>>> making this decision based on other attributes is valid. For > >>>> one thing the parts are supposed to be ordered by increasing > >>>> richness. If they differed by language this wouldn't be true. > >>> Multipart/alternative is the best we have, though. And who > >> is to say that > >>> image/jpeg is richer than image/gif, or that english is > >> richer than latin? > >>> Anyway, the following RFCs standardize the use of > >> Content-Language and refer > >>> to using multipart/alternative when providing support for multiple > >>> languages: > >>> > >>> http://tools.ietf.org/html/rfc3282 > >>> http://tools.ietf.org/html/rfc3066 > >>> > >>> -d > >>> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 20:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYQ1-000742-72; Wed, 30 May 2007 20:21:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtYPz-00073x-Tj for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 20:21:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYPz-00073p-Jm for sip@ietf.org; Wed, 30 May 2007 20:21:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtYPy-0004aR-9K for sip@ietf.org; Wed, 30 May 2007 20:21:31 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4UNTEMW021023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2007 18:29:15 -0500 In-Reply-To: <200705301859.l4UIxHVR000621@dragon.ariadne.com> References: <7374777208BDC7449D5620EF94232567048BC59C@esealmw113.eemea.ericsson.se> <200705301859.l4UIxHVR000621@dragon.ariadne.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] MIME: binary data Date: Wed, 30 May 2007 19:21:27 -0500 To: Dale.Worley@comcast.net X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 30, 2007, at 1:59 PM, Dale.Worley@comcast.net wrote: > From: "Christer Holmberg (JO/LMF)" > > Now, if this text is not specific to ISUP and QSIG, but to > binary data > in general, I think it needs to be documented in Gonzalo's draft. > Because, it seems to be one example of where we "override" the > generic > MIME rules (I haven't check, but the text says that some rules in > RFC2045 does not apply to SIP...). > > Well, we probably should document it. But SIP is not an exception, > *e-mail* is, as far as I can tell from scanning through 2045: > > See RFC 3030 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed May 30 22:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtaTy-00019C-5N; Wed, 30 May 2007 22:33:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtaTw-000197-9k for sip-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 22:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtaTv-00018z-Vw for sip@ietf.org; Wed, 30 May 2007 22:33:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtaTu-0005df-KH for sip@ietf.org; Wed, 30 May 2007 22:33:43 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 May 2007 19:33:42 -0700 X-IronPort-AV: i="4.14,596,1170662400"; d="scan'208"; a="159208773:sNHT45401112" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4V2XfOX011441; Wed, 30 May 2007 19:33:41 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l4V2XZ07019905; Thu, 31 May 2007 02:33:35 GMT In-Reply-To: <4659DA93.9040702@ericsson.com> References: <7374777208BDC7449D5620EF9423256703F85957@esealmw113.eemea.ericsson.se> <0ee901c7931e$dd43f9b0$c4a36b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF106564B4@zrc2hxm0.corp.nortel.com> <4643B58A.3060407@cisco.com> <464ABDD6.9000503@ericsson.com> <464AF68A.4010105@cisco.com> <1ECE0EB50388174790F9694F77522CCF10788B8C@zrc2hxm0.corp.nortel.com> <4653FA1F.7050008@ericsson.com> <46545100.5040707@cisco.com> <46545DA4.7070108@cisco.com> <4659DA93.9040702@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6388DC14-06F1-4CC5-85D0-33949D0B23D5@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Sip] Support for Multipart/MIME Date: Wed, 30 May 2007 19:32:49 -0700 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2697; t=1180578821; x=1181442821; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Sip]=20Support=20for=20Multipart/MIME |Sender:=20; bh=0iqDZQsjoGhP+ncm3EpMh64koAq2VXBiqey/4XI6qMU=; b=XgqEOeDXwBbBWJg0A3cPMqvDuCZmAkNtnIphZ2kzcg6+FuH/6xIkthLPWiaUMh4DBg9tdOle k0D9E3LbZQqCfx51L6lwkSDlWDhhsMx1RFmVtHncLTldiESMY9g3hhYa; Authentication-Results: sj-dkim-7; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like the draft - this looks like exactly they type of think I was hoping someone would write. Thank you, Cullen On May 27, 2007, at 12:22 PM, Gonzalo Camarillo wrote: > Hi Paul, > > I have added a few guidelines about this in Section 5 of the new > version of the draft: > > http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body- > handling-01.txt > > With those guidelines and the behavior defined in other sections, > we should be OK. Let me know if you agree or want to add further > clarifications or behavior. > > Thanks, > > Gonzalo > > > Paul Kyzivat wrote: >> Revising one point: >> Paul Kyzivat wrote: >>> - What "handling" value should be used for multipart bodies and >>> the contained body parts? >>> >>> If a body part is referenced by a cid: url in a header (or in >>> another body part I suppose), then the handling of the body part >>> should be required. >> On reflection, this is tricky. >> If the header containing the reference is optional (as most are), >> then recipients that don't understand the header will have no need >> for the referenced part. If it were required and they don't >> support the type, then they would fail the request. This is bad. >> So if processing of the header is optional, then the referenced >> body part should have optional handling. >> But then there could be a problem if the recipient does understand >> and process the header, but doesn't understand the body part, and >> so because it is optional doesn't process it. In that case, the >> cid reference will be unsatisfied. This could also result in an >> inappropriate error. >> I think the solution here is that if a header contains a cid url, >> and if that url cannot be resolved to a body part that is >> supported, then the UA should treat it the same as if the header >> itself was not understood - typically ignoring it unless there is >> a Require in effect that demands failing the request. >> An alternative is to require that Content-ID be remembered even >> for parts that are not understood, so that references can be >> resolved even if they can't be processed. This would allow more >> precise errors to be generated. This wouldn't be so hard at an >> outer level, but it might be troublesome in conjunction with nesting. >> Paul > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 03:03:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hteh9-0004YX-Mu; Thu, 31 May 2007 03:03:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hq44H-0002aH-Uv for sip-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq44F-0002Zo-Oi; Mon, 21 May 2007 05:20:39 -0400 Received: from mail.spanservices.com ([202.177.174.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq44C-0004Lb-So; Mon, 21 May 2007 05:20:39 -0400 Received: from mail2.spanservices.com ([10.10.10.34]) by mail.spanservices.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 May 2007 14:52:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 May 2007 14:52:49 +0530 Message-ID: <46290C498CFE7D409A02931CADABB3FA31A83E@mail2.spanservices.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] 3pcc controller requirements Thread-Index: AcebiLS16GOiwefLSKGrz/qQ+onPAgAAKQPA From: "SUNIL J. KUMAR" To: "Avasarala Ranjit-A20990" , X-OriginalArrivalTime: 21 May 2007 09:22:47.0685 (UTC) FILETIME=[98A0D350:01C79B89] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e X-Mailman-Approved-At: Thu, 31 May 2007 03:03:38 -0400 Cc: sipping@ietf.org Subject: [Sip] RE: [Sipping] 3pcc controller requirements X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881948378==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0881948378== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79B89.98613A08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79B89.98613A08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This can be handled by SIP B2BUA. Please refer Camrillo draft on SIP Border Controller for this/ =20 /Sunil =20 ________________________________ From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]=20 Sent: Monday, May 21, 2007 2:46 PM To: sip@ietf.org Cc: sipping@ietf.org Subject: [Sipping] 3pcc controller requirements Importance: High =20 Hi=20 Is there any doc or link where I can find the general requirements of a SIP based 3rd party call controller?=20 Thanks In Advance=20 Regards=20 Ranjit=20 ------_=_NextPart_001_01C79B89.98613A08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3pcc controller requirements

This can be handled by SIP B2BUA. = Please refer Camrillo draft on SIP Border Controller for = this/

 

/Sunil

 

From: = Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com]
Sent: Monday, May 21, = 2007 2:46 PM
To: sip@ietf.org
Cc: sipping@ietf.org
Subject: [Sipping] 3pcc = controller requirements
Importance: = High

 

Hi

Is there any doc or link where I can find the general = requirements of a SIP based 3rd party call controller?

Thanks In Advance

Regards
Ranjit

------_=_NextPart_001_01C79B89.98613A08-- --===============0881948378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0881948378==-- From sip-bounces@ietf.org Thu May 31 05:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htgp2-0006ZN-MX; Thu, 31 May 2007 05:19:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htgp0-0006Yv-4q for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 05:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htgow-0006WQ-IN for sip@ietf.org; Thu, 31 May 2007 05:19:50 -0400 Received: from mo-p00-ob.rzone.de ([81.169.146.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htgov-00020O-2z for sip@ietf.org; Thu, 31 May 2007 05:19:50 -0400 Received: from [192.168.223.125] (cable-89-216-177-142.dynamic.sbb.co.yu [89.216.177.142]) by post.webmailer.de (fruni mo36) (RZmta 6.8) with ESMTP id F04bbcj4V9Cg36 for ; Thu, 31 May 2007 11:19:46 +0200 (MEST) Message-ID: <465E9331.8070909@zesium.com> Date: Thu, 31 May 2007 11:19:45 +0200 From: Nina Garaca User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RZG-AUTH: jOJcr21HrPtUiRe9YmcRL+xtCcHiEk+2Cyz0y9h7zgP4m305c2pJpepT4Heis7LEQrg= X-RZG-CLASS-ID: mo00 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] INFO message belongs only to INVITE dialog usage? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all, I have read rfc2976 - The SIP INFO Method, but I haven't really understood that INFO message belongs only to INVITE dialog usage, which however draft-ietf-sipping-dialogusage-04 claims in its part 5.3: 5.3. Matching requests to usages For many mid-dialog requests, identifying the usage they belong to is obvious. A dialog can have at most one invite usage, so any INVITE, UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. So my, question is: Can INFO message belong to other usages, besides INVITE, such are SUBSCRIBE or REFER? Thanks in advance, Nina. -- Nina Garaca Software Development & Testing --- "ZESIUM mobile" d.o.o. Valentina Vodnika 8/9 21000 Novi Sad Serbia Tel: +381 (0)21 472 15 48 Fax: +381 (0)21 472 15 49 Mob: +381 (0)63 16 15 891 E-mail: nina.garaca@zesium.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 08:27:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htjkm-0002of-1d; Thu, 31 May 2007 08:27:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htjkl-0002oa-C6 for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htjkl-0002oS-2X for sip@ietf.org; Thu, 31 May 2007 08:27:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htjkj-0007zp-DQ for sip@ietf.org; Thu, 31 May 2007 08:27:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B7F79209F0; Thu, 31 May 2007 14:27:40 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-25-465ebf3caa4b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A2A02209CA; Thu, 31 May 2007 14:27:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 14:27:40 +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 Subject: RE: [Sip] MIME: MIME when only one body type Date: Thu, 31 May 2007 14:27:39 +0200 Message-ID: <7374777208BDC7449D5620EF94232567049413DD@esealmw113.eemea.ericsson.se> In-Reply-To: <000301c7a2f3$17ff7a00$10676b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: MIME when only one body type thread-index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZA= References: <7374777208BDC7449D5620EF94232567048BC560@esealmw113.eemea.ericsson.se> <000301c7a2f3$17ff7a00$10676b80@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , X-OriginalArrivalTime: 31 May 2007 12:27:40.0159 (UTC) FILETIME=[146388F0:01C7A37F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Francois Audet , "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Chapter 3.2 of Gonzalo's draft says: >>=20 >>"UAs should avoid unnecessarily nesting body parts. Therefore, UAs=20 >>SHOULD NOT use a 'multipart' body when there is only one body part." >>=20 >>However, chapter 5.1.1 of RFC2046 says: >>=20 >>"NOTE: Experience has shown that a "multipart" media type with a=20 >>single body part is useful for sending non-text media types." >=20 >The only reason I could see it being useful for email was=20 >when you're sending the message to a non-MIME-aware mail user=20 >agent, and you included a MIME prologue: >=20 > From: dwing@cisco.com > Content-Type: multipart/mixed; boundary=3DA > > You are reading this message with a mailer that doesn't understand > MIME. To review the attached content, use 'metamail'. > > --A > Content-Type: image/jpg > Content-Transfer-Encoding: base64 > > EJKF3849efjkej... > > --A-- >=20 >>So, I think we need to add some words saying that it can be useful in=20 >>some cases. >=20 >Unless there is another case that it's useful for SIP, I think it could only harm interoperability. Like I said, it may be used for transporting ISUP information. Maybe Francois has more information? Also, if a client is going to support multipart anyway, I don't see how it would harm interoperability. I would be very surprised if a client supports MIME with multiple bodies, but not with a single body... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 11:09:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmGw-0000nx-Nh; Thu, 31 May 2007 11:09:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtmGv-0000is-7E for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmGu-0000ik-Tg for sip@ietf.org; Thu, 31 May 2007 11:09:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtmGu-0003m0-Ey for sip@ietf.org; Thu, 31 May 2007 11:09:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2007 11:09:04 -0400 X-IronPort-AV: i="4.14,599,1170651600"; d="scan'208"; a="122461445:sNHT53409148" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VF94Xf023989; Thu, 31 May 2007 11:09:04 -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.12.10/8.12.6) with ESMTP id l4VF935l003217; Thu, 31 May 2007 15:09:03 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.1830); Thu, 31 May 2007 11:08:53 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 11:08:53 -0400 Message-ID: <465EE503.3090702@cisco.com> Date: Thu, 31 May 2007 11:08:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Contact header in 1xx responses/updates remote target ornot? References: <4656BDFE.7020006@zesium.com><200705260454.l4Q4sYOV027172@dragon.ariadne.com> <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> <7374777208BDC7449D5620EF942325670483C959@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670483C959@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2007 15:08:53.0397 (UTC) FILETIME=[9A168450:01C7A395] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4578; t=1180624144; x=1181488144; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20Contact=20header=20in=201xx=20responses/updat es=20remote=20target=20ornot? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=B20aaKlisZHJ1g9B+BFbSiByYZp7SuDC3CW6GkEzkXU=; b=gynCV0B+Z16oGJdV2pWl/EUwTRyS/jF4kyzK3LC91ePTOXEplLGURGFn9Okt5jCulzQKGwS5 IcC6tRJopbjwPJoHRh3ysk7s9EYNoTFvx+HRqNuvPnYOcZa/sWSKZ/8r; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org IMO a Contact is required in all provisional responses except for 100. 3261 definitely has the notion of early dialog which is established by receipt of non-100 provisional response. (This would be an unreliable provisional based on 3261, possibly reliable based on extensions.) The early dialog of course cannot be established without a Contact. So either the establishment of the early dialog is conditional on whether the provisional has the Contact or not, or else the provisionals must always have the contact. I don't recall any mention of this being conditional, so I think the contact is always required. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > At least in RELIABLE provisinal responses Contact is required, in order > to be able to send PRACK. > > One of the issues we've been discussing before is whether an UAC is > allowed to send a non-CANCEL mid-dialog request once it has received an > UNRELIABLE provisional response. I think the conclusion has been that it > IS allowed, and in that case a Contact of course would be needed. > > Whether we want to mandate Contact in unreliable provisional responses > or not is one issue, but as part of the new fix-the-bugs-in-3261 work > item it would give us an opportunity to clarify the issue. > > Another, related, question which comes up every now and then: IF I > receive a provisonal response with a Contact, is it allowed to "update" > that Contact in the 200 OK (or, another reliable resonse)? Whatever the > answer is, I think some clarification text would be useful. > > Regards, > > Christer > > > > > >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >> Sent: 26. toukokuuta 2007 13:52 >> To: sip@ietf.org; Dale.Worley@comcast.net >> Subject: Re: [Sip] Contact header in 1xx responses/updates >> remote target ornot? >> >> Dale, >> >> Not sure if I read your comment right, but RFC3261 12.2.1.2 says >> >> When a UAC receives a 2xx response to a target refresh request, it >> MUST replace the dialog's remote target URI with the URI from the >> Contact header field in that response, if present. >> It does not say anything about 1xx responses here >> though...Regards,Jeroen Dale.Worley@comcast.net wrote: >>> From: Nina Garaca >>> >>> Q1: Should I expect that these responses have a Contact header? >>> >>> As Paul says, if it didn't have a Contact header, it couldn't >>> establish a dialog. >>> >>> Q2: If they do so, should the remote target of the dialog be >>> refreshed by that Contact at the side that has received that 1xx >>> response and should the remote target of the dialog be >> refreshed by >>> the Contact in the INVITE request at the side that has >> received that >>> INVITE? >>> >>> Responses are not "target refresh requests", so they don't >> change the >>> target address at their end of the dialog. But of course, the >>> responses to the dialog-initiating request establish the initial >>> target address. >>> >>> Q3: If not, should the remote target of the dialog be refreshed by >>> the Contact in the INVITE request >>> at the side that has received that INVITE and has sent dialog >>> establishing 1xx response? >>> >>> RFC 3261 section 12.2: >>> >>> INVITE, the only target refresh request defined is re-INVITE (see >>> Section 14). Other extensions may define different target refresh >>> requests for dialogs established in other ways. >>> >>> Dale >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 11:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmPA-00071R-As; Thu, 31 May 2007 11:17:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtmP8-00071J-Pt for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:17:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmP8-00071B-GB for sip@ietf.org; Thu, 31 May 2007 11:17:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtmP8-0006M6-4S for sip@ietf.org; Thu, 31 May 2007 11:17:34 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 May 2007 08:17:33 -0700 X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="159463157:sNHT44125398" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4VFHXdd013790; Thu, 31 May 2007 08:17:33 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4VFGdVR001868; Thu, 31 May 2007 15:17:33 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.1830); Thu, 31 May 2007 11:17:32 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 11:17:32 -0400 Message-ID: <465EE70A.9070202@cisco.com> Date: Thu, 31 May 2007 11:17:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] MIME: MIME when only one body type References: <7374777208BDC7449D5620EF94232567048BC560@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567048BC560@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2007 15:17:32.0310 (UTC) FILETIME=[CF625B60:01C7A396] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1540; t=1180624653; x=1181488653; c=relaxed/simple; s=sjdkim8002; 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[Sip]=20MIME=3A=20MIME=20when=20only=20one=20body=20t ype |Sender:=20; bh=Z4MWsMGND8HP9/7CEqwBZ17bvf4IG0ms0XvDmGkB/AI=; b=XxgnBrsWckpIssc92X6sefbe+ABqaiy6cIg1Ms8E4cbuR/wh9hYmFZZO7YYK733O32Y1KCtp SDwK4i7rZTvytJECbpXbgQ8EiRpa6gwp70rIMeMat3QDjRPlxloR2Wmv; Authentication-Results: sj-dkim-8; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I was the one who originally raised this issue. I don't have a strong opinion on which way it should go, but I think what Gonzalo wrote (SHOULD NOT) is about right. The issue is that if there can be one level of gratuitous nesting, then what about two, or a hundred levels of gratuitous nesting? I'm inclined to think that people SHOULDN'T do it, but that a recipient should deal with it, at least within reason. (Perhaps its ok not to support 100 levels of nesting.) Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > Chapter 3.2 of Gonzalo's draft says: > > "UAs should avoid unnecessarily nesting body parts. Therefore, UAs > SHOULD NOT use a 'multipart' body when there is only one body part." > > However, chapter 5.1.1 of RFC2046 says: > > "NOTE: Experience has shown that a "multipart" media type with a > single body part is useful for sending non-text media types." > > So, I think we need to add some words saying that it can be useful in > some cases. > > For example, I THINK I have seen INFO requests with encapsulated ISUP > messages inside a MIME body, eventhough the message doesn't contain any > other body types. > > Regards, > > Christer > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 11:21:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmSW-00007H-1L; Thu, 31 May 2007 11:21:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtmSU-0008Ru-D7 for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmSU-0008RD-2q for sip@ietf.org; Thu, 31 May 2007 11:21:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtmSS-0007Yr-Qo for sip@ietf.org; Thu, 31 May 2007 11:21:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2007 11:21:00 -0400 X-IronPort-AV: i="4.14,599,1170651600"; d="scan'208"; a="61616000:sNHT42496894" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VFL07Q029965; Thu, 31 May 2007 11:21:00 -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.12.10/8.12.6) with ESMTP id l4VFKP69006680; Thu, 31 May 2007 15:21:00 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.1830); Thu, 31 May 2007 11:20:49 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 11:20:49 -0400 Message-ID: <465EE7CF.4010705@cisco.com> Date: Thu, 31 May 2007 11:20:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Nina Garaca Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <465E9331.8070909@zesium.com> In-Reply-To: <465E9331.8070909@zesium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2007 15:20:49.0329 (UTC) FILETIME=[44D11210:01C7A397] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=880; t=1180624860; x=1181488860; c=relaxed/simple; s=rtpdkim1001; 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[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20Nina=20Garaca=20; bh=oiEwZT+/wMtrxO0Jmb5o8o2v2uR7CjwgKWO+0zJK9sw=; b=mAQtHRo+w46mB9IeRAMi+QaeiLA+mcEvAHiQXEE+gm9Lz1H7eyLPoxVdS2k8fnqbHN12mzrc xDFFFIRlbR90Y/3SdoNweb7ByIaOAlzcnzXleOdqj6I7IKND3JsbaNF/; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My understanding is consistent with what dialogusage says - INFO is specific to the INVITE dialog usage. But off the top of my head I can't recall where that is specified. Paul Nina Garaca wrote: > Hi all, > > I have read rfc2976 - The SIP INFO Method, but I haven't really > understood that INFO message belongs only to INVITE dialog usage, which > however draft-ietf-sipping-dialogusage-04 claims in its part 5.3: > > > 5.3. Matching requests to usages > > > > For many mid-dialog requests, identifying the usage they belong to is > obvious. A dialog can have at most one invite usage, so any INVITE, > UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. > > So my, question is: > Can INFO message belong to other usages, besides INVITE, such are > SUBSCRIBE or REFER? > > Thanks in advance, > Nina. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 11:21:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmSb-0000Pe-9P; Thu, 31 May 2007 11:21:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtmSZ-0000Im-I4 for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtmSZ-0000IY-5r for sip@ietf.org; Thu, 31 May 2007 11:21:07 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtmSY-0007mZ-Si for sip@ietf.org; Thu, 31 May 2007 11:21:07 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 31 May 2007 08:21:06 -0700 X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="11831473:sNHT42577224" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 16:21:05 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 31 May 2007 16:21:03 +0100 Message-ID: <0E48B768805E4D44A70709C8AE0920908B83EC@EMAILEMEA3.jnpr.net> In-Reply-To: <465E9331.8070909@zesium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcejZO/gClCPMGnZSCiEqK60OhPKawALzh/w References: <465E9331.8070909@zesium.com> From: "Gilad Shaham" To: "Nina Garaca" X-OriginalArrivalTime: 31 May 2007 15:21:05.0341 (UTC) FILETIME=[4E5C4ED0:01C7A397] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Typically an INFO method would be part of an INVITE usage. As far as I know the Event header is not defined for INFO. I wouldn't count on the other end to associate the INFO request to the subscription even if you were to include the Event header. Basically there is no need to have INFO on a subscription usage because all information could be passed via SUBSCRIBE and NOTIFY. Furthermore, I have rarely seen INFO used in practice, usually used just to pass some proprietary information. -----Original Message----- From: Nina Garaca [mailto:nina.garaca@zesium.com]=20 Sent: Thursday, May 31, 2007 12:20 PM To: sip@ietf.org Subject: [Sip] INFO message belongs only to INVITE dialog usage? Hi all, I have read rfc2976 - The SIP INFO Method, but I haven't really=20 understood that INFO message belongs only to INVITE dialog usage, which=20 however draft-ietf-sipping-dialogusage-04 claims in its part 5.3: 5.3. Matching requests to usages For many mid-dialog requests, identifying the usage they belong to is obvious. A dialog can have at most one invite usage, so any INVITE, UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. So my, question is: Can INFO message belong to other usages, besides INVITE, such are =20 SUBSCRIBE or REFER? Thanks in advance, Nina. --=20 Nina Garaca Software Development & Testing --- "ZESIUM mobile" d.o.o. Valentina Vodnika 8/9 21000 Novi Sad Serbia Tel: +381 (0)21 472 15 48 Fax: +381 (0)21 472 15 49 Mob: +381 (0)63 16 15 891 E-mail: nina.garaca@zesium.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 11:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn37-000408-SI; Thu, 31 May 2007 11:58:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htn36-0003z1-DT for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 11:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn36-0003yt-3q for sip@ietf.org; Thu, 31 May 2007 11:58:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htn34-0006KC-Na for sip@ietf.org; Thu, 31 May 2007 11:58:52 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4VF6asw024786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 31 May 2007 10:06:36 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Thu, 31 May 2007 10:58:48 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new version of the SIPS draft has been posted: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt The author thinks this is ready for last call. I think that, given the below discussion, it probably is too. But there is one issue I'm worried about. We know it doesn't fix everything, we're not sure it is possible to fix everything with SIPS, but we are committed to fixing what we can. So please don't bother to say it isn't worth the effort since it doesn't make SIPS perfect -- you might be right, but that alone is insufficient reason to block things. One step at a time. I'm sure we'll be taking further steps in this space. Now, for te issue I'm worried about: I have received some personal feedback from more than one credible source that the draft's direction on transport=tls is inconsistent with the real world and possibly not optimal. But so far, Juha has been the only one I've noticed trying to explain this issue "on the record", and one voice does not overbalance a quiet consensus. So I'd like to ask the rest of you (if any) who actually feel this way to step up to the plate and explain what you're talking about, because I don't get it and it looks like a bunch of the WG doesn't get it. Please! If you don't step up now, I'm probably going to make rude "raspberry" noises if you bring it up someplace like Chicago. -- Dean (chair hat stapled to head so it doesn't blow off in the coming storm) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 12:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn9U-0001EP-MC; Thu, 31 May 2007 12:05:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htn9T-0001EK-TV for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 12:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn9T-0001EC-Ju for sip@ietf.org; Thu, 31 May 2007 12:05:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htn9T-0000fO-7x for sip@ietf.org; Thu, 31 May 2007 12:05:27 -0400 Received: from [206.176.144.212] (206-176-144-212.waymark.net [206.176.144.212]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l4VFDBEk024839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 May 2007 10:13:12 -0500 In-Reply-To: <465E9331.8070909@zesium.com> References: <465E9331.8070909@zesium.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 31 May 2007 11:05:23 -0500 To: Nina Garaca X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 31, 2007, at 4:19 AM, Nina Garaca wrote: > Hi all, > > I have read rfc2976 - The SIP INFO Method, but I haven't really > understood that INFO message belongs only to INVITE dialog usage, > which however draft-ietf-sipping-dialogusage-04 claims in its part > 5.3: > > > 5.3. Matching requests to usages > > > > For many mid-dialog requests, identifying the usage they belong > to is > obvious. A dialog can have at most one invite usage, so any INVITE, > UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. > > So my, question is: > Can INFO message belong to other usages, besides INVITE, such > are SUBSCRIBE or REFER? > There was IIRC no intent in the writing of RFC 2976 to restrict INFO to occurring within an INVITE dialog usage. So it could technically be used outside of one, including in non-dialog cases. However, RFC 2976 is considered to be somewhat underspecified, and so far the only place we've further specified its usage is in the context of transporting binary data for telephony protocol tunelling. We have a standing consensus to NOT use it for arbitrary data at this time. If we were to start using it, we'd need to do something like the event-packages model for INFO. So don't use it, and you won't have to deal with this . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 13:38:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htob5-0004TS-N6; Thu, 31 May 2007 13:38:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htob3-0004TI-Ud for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 13:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htob3-0004T7-Km for sip@ietf.org; Thu, 31 May 2007 13:38:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htob1-0002lS-Tw for sip@ietf.org; Thu, 31 May 2007 13:38:01 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 May 2007 10:37:58 -0700 X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="159565161:sNHT907649910" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4VHbwoh017693; Thu, 31 May 2007 10:37:58 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4VHbr06028110; Thu, 31 May 2007 17:37:58 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , Subject: RE: [Sip] MIME: MIME when only one body type Date: Thu, 31 May 2007 10:37:53 -0700 Message-ID: <044701c7a3aa$6debdb90$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZAACvSqkA== In-Reply-To: <7374777208BDC7449D5620EF94232567049413DD@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=950; t=1180633078; x=1181497078; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20MIME=3A=20MIME=20when=20only=20one=20body=20t ype |Sender:=20; bh=4vRhj8UpRRPnyu81PurQDGVMmkUJnRvhlHgqBU8mK88=; b=tpYtaYtyvPlno3wiUtj4Vdk1NzdcsqaQYbGOw8c5HWBR+me0//VSJlsaKbxNYfGuwluB+1QN ztqO+3lyJd8fkS7D+WfGxBRT7qLG9QrkIr50is87nll75wbVi9JYoVJL; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Francois Audet' , "'Gonzalo Camarillo \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > >Unless there is another case that it's useful for SIP, I > >think it could only harm interoperability. > > Like I said, it may be used for transporting ISUP information. Maybe > Francois has more information? Implementations may well be doing multipart/mixed and including only one bodypart. I completely agree that might be happening. > Also, if a client is going to support multipart anyway, I > don't see how it would harm interoperability. By doing that, you are teasing fate, and you aren't "being conservative in what you send". Afterall, it's the receiver (not the sender) of the MIME that may have difficulties. > I would be very surprised if a client > supports MIME with multiple bodies, but not with a single body... Yep, but it isn't the client that I'm so worried about. I expect if you sent a multipart containing one part (application/sdp), you would find disasterous interoperability. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 14:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtpDw-0001BO-HZ; Thu, 31 May 2007 14:18:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtpDv-0001BJ-7c for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 14:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtpDu-0001BB-UH for sip@ietf.org; Thu, 31 May 2007 14:18:10 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtpDt-0007gJ-LI for sip@ietf.org; Thu, 31 May 2007 14:18:10 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4VII5V22013; Thu, 31 May 2007 18:18:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] MIME: MIME when only one body type Date: Thu, 31 May 2007 13:18:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10AE8699@zrc2hxm0.corp.nortel.com> In-Reply-To: <044701c7a3aa$6debdb90$10676b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: MIME when only one body type Thread-Index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZAACvSqkAABXcag References: <7374777208BDC7449D5620EF94232567049413DD@esealmw113.eemea.ericsson.se> <044701c7a3aa$6debdb90$10676b80@amer.cisco.com> From: "Francois Audet" To: "Dan Wing" , "Christer Holmberg (JO/LMF)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree with Dan. I don't understand the use case in SIP of sending a Multipart with only one body. The mail example makes sense for really dumb implementations that don't support MIME whatsoever, but for SIP, there is no such thing since MIME has been in SIP since day one. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Thursday, May 31, 2007 10:38 > To: 'Christer Holmberg (JO/LMF)'; sip@ietf.org > Cc: 'Gonzalo Camarillo (JO/LMF)'; Audet, Francois (SC100:3055) > Subject: RE: [Sip] MIME: MIME when only one body type >=20 > =20 > > >Unless there is another case that it's useful for SIP, I think it=20 > > >could only harm interoperability. > >=20 > > Like I said, it may be used for transporting ISUP=20 > information. Maybe=20 > > Francois has more information? >=20 > Implementations may well be doing multipart/mixed and=20 > including only one bodypart. I completely agree that might=20 > be happening. =20 >=20 > > Also, if a client is going to support multipart anyway, I don't see=20 > > how it would harm interoperability. >=20 > By doing that, you are teasing fate, and you aren't "being=20 > conservative in what you send". Afterall, it's the receiver=20 > (not the sender) of the MIME that may have difficulties. =20 >=20 > > I would be very surprised if a client > > supports MIME with multiple bodies, but not with a single body... >=20 > Yep, but it isn't the client that I'm so worried about. I=20 > expect if you sent a multipart containing one part=20 > (application/sdp), you would find disasterous interoperability. >=20 > -d >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 14:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htpep-0006fv-Rw; Thu, 31 May 2007 14:45:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htpen-0006fq-WA for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 14:45:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htpen-0006fi-Mm for sip@ietf.org; Thu, 31 May 2007 14:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoxH-0000Vn-RI for sip@ietf.org; Thu, 31 May 2007 14:00:59 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtoxE-0001a8-F9 for sip@ietf.org; Thu, 31 May 2007 14:00:59 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l4VI0hOd013418 for ; Thu, 31 May 2007 13:00:55 -0500 (CDT) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 13:00:42 -0500 Received: from INEXC1U02.in.lucent.com ([135.254.223.26]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 23:30:37 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 31 May 2007 23:30:36 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Treatment of ACK for 2xx final response Thread-Index: AcejrZdUuf2War+yTuqRbybgvw+6Hw== From: "Kadirvelu, Kannan \(Kanna\)" To: X-OriginalArrivalTime: 31 May 2007 18:00:37.0759 (UTC) FILETIME=[97F760F0:01C7A3AD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-TMDA-Confirmed: Thu, 31 May 2007 14:45:57 -0400 Subject: [Sip] Treatment of ACK for 2xx final response X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi All, We require some clarity on ACK processing on the UA server side.=20 Consider the following scenario :=20 A -- INVITE ----> B A <-- 200 OK ---- B A -- ACK -------> B A, B are SIP UAs.=20 In the above example, the SIP server A sent the ACK with same branch ID as that of INVITE. We know clearly A is in error. However we are not clear on what should be the behavior of B. Should the transaction layer of B absorb this ACK or send it to TU ?=20 Please help. Regards, Kannan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 15:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqbp-0005OD-52; Thu, 31 May 2007 15:46:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htqbo-0005O8-Fz for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 15:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqbo-0005O0-6E for sip@ietf.org; Thu, 31 May 2007 15:46:56 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htqbn-0003cq-L6 for sip@ietf.org; Thu, 31 May 2007 15:46:56 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E15B3200EE; Thu, 31 May 2007 21:46:54 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-b9-465f262e29a5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBAFE200EA; Thu, 31 May 2007 21:46:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 21:46:54 +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 Subject: RE: [Sip] MIME: MIME when only one body type Date: Thu, 31 May 2007 21:46:51 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704941F26@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10AE8699@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: MIME when only one body type thread-index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZAACvSqkAABXcagAAL/vjA= References: <7374777208BDC7449D5620EF94232567049413DD@esealmw113.eemea.ericsson.se> <044701c7a3aa$6debdb90$10676b80@amer.cisco.com> <1ECE0EB50388174790F9694F77522CCF10AE8699@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg (JO/LMF)" To: "Francois Audet" , "Dan Wing" , X-OriginalArrivalTime: 31 May 2007 19:46:54.0384 (UTC) FILETIME=[70BB2300:01C7A3BC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "Gonzalo Camarillo \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I agree with Dan. >=20 >I don't understand the use case in SIP of sending a Multipart=20 >with only one body. Again, I think I've seen INFOs and/or BYEs carrying ISUP informatio in multipart, without any other body (unfortunately I have to use the word "think", because I don't have any real examples in front of me :) But, I have nothing against saying that one SHOULD NOT (or even MUST NOT) SEND it. But, I do think one should be prepared to RECEIVE such messages, in order to be backward compatible with existing implementations which may not be fully compliant the draft. And, regarding Dan's example: if a client is not able to handle multipart carrying only SDP, I don't think it will be able to handle a multipart carrying SDP and something else either - and we will have the problem Francois presented earlier (the multipart, and the SDP innit, is thrown away). Regards, Christer > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Thursday, May 31, 2007 10:38 > > To: 'Christer Holmberg (JO/LMF)'; sip@ietf.org > > Cc: 'Gonzalo Camarillo (JO/LMF)'; Audet, Francois (SC100:3055) > > Subject: RE: [Sip] MIME: MIME when only one body type > >=20 > > =20 > > > >Unless there is another case that it's useful for SIP, I=20 > think it=20 > > > >could only harm interoperability. > > >=20 > > > Like I said, it may be used for transporting ISUP > > information. Maybe > > > Francois has more information? > >=20 > > Implementations may well be doing multipart/mixed and=20 > including only=20 > > one bodypart. I completely agree that might be happening. > >=20 > > > Also, if a client is going to support multipart anyway, I=20 > don't see=20 > > > how it would harm interoperability. > >=20 > > By doing that, you are teasing fate, and you aren't "being=20 > > conservative in what you send". Afterall, it's the=20 > receiver (not the=20 > > sender) of the MIME that may have difficulties. > >=20 > > > I would be very surprised if a client supports MIME with multiple=20 > > > bodies, but not with a single body... > >=20 > > Yep, but it isn't the client that I'm so worried about. I=20 > expect if=20 > > you sent a multipart containing one part (application/sdp),=20 > you would=20 > > find disasterous interoperability. > >=20 > > -d > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 15:53:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqi3-0007Lr-OV; Thu, 31 May 2007 15:53:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htqi1-0007Ll-MN for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 15:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqi1-0007Ld-Cd for sip@ietf.org; Thu, 31 May 2007 15:53:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htqi0-0005Zx-3k for sip@ietf.org; Thu, 31 May 2007 15:53:21 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 May 2007 12:53:19 -0700 X-IronPort-AV: i="4.16,370,1175497200"; d="scan'208"; a="159630280:sNHT43193412" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4VJrJ0x027163; Thu, 31 May 2007 12:53:19 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4VJrI06020597; Thu, 31 May 2007 19:53:19 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'Francois Audet'" , Subject: RE: [Sip] MIME: MIME when only one body type Date: Thu, 31 May 2007 12:53:18 -0700 Message-ID: <04fa01c7a3bd$564e31a0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZAACvSqkAABXcagAAL/vjAAAHHfoA== In-Reply-To: <7374777208BDC7449D5620EF9423256704941F26@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1381; t=1180641199; x=1181505199; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20MIME=3A=20MIME=20when=20only=20one=20body=20t ype |Sender:=20; bh=one1OerM73PKmQZCT93lGtAnztohoJZbY80HqXngfEc=; b=pHw7Se9vNrSVP4V2DzaQ7+3qJNPl3RRmNztfTJitsLBWopPENbxXD3zyfA971Z6tY8+RWdsN jvnkaFYa/VZaNvTQHhdY0Vsk4p2jq/pTiAEdUaCreyHf47dX/Ip5jOaB; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "'Gonzalo Camarillo \(JO/LMF\)'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, May 31, 2007 12:47 PM > To: Francois Audet; Dan Wing; sip@ietf.org > Cc: Gonzalo Camarillo (JO/LMF) > Subject: RE: [Sip] MIME: MIME when only one body type > > > Hi, > > >I agree with Dan. > > > >I don't understand the use case in SIP of sending a Multipart > >with only one body. > > Again, I think I've seen INFOs and/or BYEs carrying ISUP informatio in > multipart, without any other body (unfortunately I have to > use the word > "think", because I don't have any real examples in front of me :) > > But, I have nothing against saying that one SHOULD NOT (or even MUST > NOT) SEND it. But, I do think one should be prepared to RECEIVE such > messages, in order to be backward compatible with existing > implementations which may not be fully compliant the draft. I agree. > And, regarding Dan's example: if a client is not able to handle > multipart carrying only SDP, I don't think it will be able to handle a > multipart carrying SDP and something else either - and we > will have the > problem Francois presented earlier (the multipart, and the > SDP innit, is thrown away). Yep. But that's exactly why I don't think we should encourage unnecessary use of MIME -- it only tempts fate. -d _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 16:00:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqof-00040z-9p; Thu, 31 May 2007 16:00:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htqod-0003yz-M5 for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 16:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htqod-0003yn-7s for sip@ietf.org; Thu, 31 May 2007 16:00:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htqoc-00071Z-Ho for sip@ietf.org; Thu, 31 May 2007 16:00:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E81B22057F; Thu, 31 May 2007 22:00:09 +0200 (CEST) X-AuditID: c1b4fb3c-a7ce9bb0000073d5-ff-465f29494eb5 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B71B420407; Thu, 31 May 2007 22:00:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 22:00:09 +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 Subject: RE: [Sip] Contact header in 1xx responses/updates remote target ornot? Date: Thu, 31 May 2007 22:00:08 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704941F4F@esealmw113.eemea.ericsson.se> In-Reply-To: <465EE503.3090702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contact header in 1xx responses/updates remote target ornot? thread-index: AcejlaOImdpOOo7PTxepRSQoM/tO/wAJuIAw References: <4656BDFE.7020006@zesium.com><200705260454.l4Q4sYOV027172@dragon.ariadne.com> <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> <7374777208BDC7449D5620EF942325670483C959@esealmw113.eemea.ericsson.se> <465EE503.3090702@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 31 May 2007 20:00:09.0421 (UTC) FILETIME=[4A9C27D0:01C7A3BE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >IMO a Contact is required in all provisional responses except=20 >for 100.=20 >3261 definitely has the notion of early dialog which is=20 >established by receipt of non-100 provisional response. (This=20 >would be an unreliable provisional based on 3261, possibly=20 >reliable based on extensions.) >=20 >The early dialog of course cannot be established without a=20 >Contact. So either the establishment of the early dialog is=20 >conditional on whether the provisional has the Contact or=20 >not, or else the provisionals must always have the contact. I=20 >don't recall any mention of this being conditional, so I=20 >think the contact is always required. In the "Summary of header fields" table of RFC3261 Contact is indicated as "o" for 1xx responses. Whether that is because 1xx also covers 100 Trying, or because of some other reason, is unclear. So, whatever option - mandating Contact in non-100, or allowing non-100 without Contact (which I assume means the early dialog will not be established) - we choose, I think it needs clarification. Maybe the easiest thing would be to say something like: "If the provisional response is intented to establish an early dialog, it MUST contain a Contact header." Also, as I mentioned earlier, I think we need to clarify whether it's allowed or not to "update" a previously sent Contact in a new 1xx or 2xx. <---- 180 Contact=3DB <---- 183 Contact=3DC <---- 200 Contact=3DD (the To tag has the same value in all 3 messages) Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > > At least in RELIABLE provisinal responses Contact is required, in=20 > > order to be able to send PRACK. > >=20 > > One of the issues we've been discussing before is whether an UAC is=20 > > allowed to send a non-CANCEL mid-dialog request once it has=20 > received=20 > > an UNRELIABLE provisional response. I think the conclusion has been=20 > > that it IS allowed, and in that case a Contact of course=20 > would be needed. > >=20 > > Whether we want to mandate Contact in unreliable=20 > provisional responses=20 > > or not is one issue, but as part of the new=20 > fix-the-bugs-in-3261 work=20 > > item it would give us an opportunity to clarify the issue. > >=20 > > Another, related, question which comes up every now and then: IF I=20 > > receive a provisonal response with a Contact, is it allowed=20 > to "update" > > that Contact in the 200 OK (or, another reliable resonse)? Whatever=20 > > the answer is, I think some clarification text would be useful. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > >> Sent: 26. toukokuuta 2007 13:52 > >> To: sip@ietf.org; Dale.Worley@comcast.net > >> Subject: Re: [Sip] Contact header in 1xx responses/updates remote=20 > >> target ornot? > >> > >> Dale, > >> > >> Not sure if I read your comment right, but RFC3261 12.2.1.2 says > >> > >> When a UAC receives a 2xx response to a target refresh request, it > >> MUST replace the dialog's remote target URI with the=20 > URI from the > >> Contact header field in that response, if present. > >> It does not say anything about 1xx responses here=20 > >> though...Regards,Jeroen Dale.Worley@comcast.net wrote: > >>> From: Nina Garaca > >>> > >>> Q1: Should I expect that these responses have a Contact header? > >>> > >>> As Paul says, if it didn't have a Contact header, it couldn't=20 > >>> establish a dialog. > >>> > >>> Q2: If they do so, should the remote target of the dialog be > >>> refreshed by that Contact at the side that has received that 1xx > >>> response and should the remote target of the dialog be > >> refreshed by > >>> the Contact in the INVITE request at the side that has > >> received that > >>> INVITE? > >>> > >>> Responses are not "target refresh requests", so they don't > >> change the > >>> target address at their end of the dialog. But of course, the=20 > >>> responses to the dialog-initiating request establish the initial=20 > >>> target address. > >>> > >>> Q3: If not, should the remote target of the dialog be=20 > refreshed by > >>> the Contact in the INVITE request > >>> at the side that has received that INVITE and has=20 > sent dialog > >>> establishing 1xx response? > >>> > >>> RFC 3261 section 12.2: > >>> > >>> INVITE, the only target refresh request defined is=20 > re-INVITE (see > >>> Section 14). Other extensions may define different=20 > target refresh > >>> requests for dialogs established in other ways. > >>> > >>> Dale > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol Use=20 > >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >>> sipping@ietf.org for new developments on the application of sip > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 16:27:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrFM-0004QZ-Ed; Thu, 31 May 2007 16:27:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtrFK-0004QP-RV for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 16:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrFK-0004QH-Hn for sip@ietf.org; Thu, 31 May 2007 16:27:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtrFK-0002fK-2N for sip@ietf.org; Thu, 31 May 2007 16:27:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 31 May 2007 16:27:46 -0400 X-IronPort-AV: i="4.16,370,1175486400"; d="scan'208"; a="122500351:sNHT126171224" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4VKRjwf022164; Thu, 31 May 2007 16:27:45 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VKRjBe022502; Thu, 31 May 2007 20:27:45 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.1830); Thu, 31 May 2007 16:27:45 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 16:27:45 -0400 Message-ID: <465F2FBE.9090501@cisco.com> Date: Thu, 31 May 2007 16:27:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] Contact header in 1xx responses/updates remote target ornot? References: <4656BDFE.7020006@zesium.com><200705260454.l4Q4sYOV027172@dragon.ariadne.com> <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> <7374777208BDC7449D5620EF942325670483C959@esealmw113.eemea.ericsson.se> <465EE503.3090702@cisco.com> <7374777208BDC7449D5620EF9423256704941F4F@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704941F4F@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2007 20:27:45.0315 (UTC) FILETIME=[25998730:01C7A3C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6174; t=1180643265; x=1181507265; c=relaxed/simple; s=rtpdkim2001; 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[Sip]=20Contact=20header=20in=201xx=20responses/updat es=20remote=20target=20ornot? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=TlP/T/LLKXid+B7v5Ne5BaXY9Te2TAEUVjm4eSeja7I=; b=iZAexEQEzga11OE5Iv0phkYg5eJ7bAH2RS/clAXZQLz7i8aKzrMWDro/e/RBnAw7vHmBnanF 4bzjS8qtCHA8d77Im6K3F3sTHJ2NS8uhrrJ2SnP0fZjRN2Tv2mSYeeB9; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > >> IMO a Contact is required in all provisional responses except >> for 100. >> 3261 definitely has the notion of early dialog which is >> established by receipt of non-100 provisional response. (This >> would be an unreliable provisional based on 3261, possibly >> reliable based on extensions.) >> >> The early dialog of course cannot be established without a >> Contact. So either the establishment of the early dialog is >> conditional on whether the provisional has the Contact or >> not, or else the provisionals must always have the contact. I >> don't recall any mention of this being conditional, so I >> think the contact is always required. > > In the "Summary of header fields" table of RFC3261 Contact is indicated > as "o" for 1xx responses. Whether that is because 1xx also covers 100 > Trying, or because of some other reason, is unclear. > > So, whatever option - mandating Contact in non-100, or allowing non-100 > without Contact (which I assume means the early dialog will not be > established) - we choose, I think it needs clarification. > > Maybe the easiest thing would be to say something like: "If the > provisional response is intented to establish an early dialog, it MUST > contain a Contact header." > > Also, as I mentioned earlier, I think we need to clarify whether it's > allowed or not to "update" a previously sent Contact in a new 1xx or > 2xx. > > <---- 180 Contact=B > <---- 183 Contact=C > <---- 200 Contact=D > > (the To tag has the same value in all 3 messages) > > Regards, > > Christer > > > > > > > > >> Christer Holmberg (JO/LMF) wrote: >>> Hi, >>> >>> At least in RELIABLE provisinal responses Contact is required, in >>> order to be able to send PRACK. >>> >>> One of the issues we've been discussing before is whether an UAC is >>> allowed to send a non-CANCEL mid-dialog request once it has >> received >>> an UNRELIABLE provisional response. I think the conclusion has been >>> that it IS allowed, and in that case a Contact of course >> would be needed. >>> Whether we want to mandate Contact in unreliable >> provisional responses >>> or not is one issue, but as part of the new >> fix-the-bugs-in-3261 work >>> item it would give us an opportunity to clarify the issue. >>> >>> Another, related, question which comes up every now and then: IF I >>> receive a provisonal response with a Contact, is it allowed >> to "update" >>> that Contact in the 200 OK (or, another reliable resonse)? Whatever >>> the answer is, I think some clarification text would be useful. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] >>>> Sent: 26. toukokuuta 2007 13:52 >>>> To: sip@ietf.org; Dale.Worley@comcast.net >>>> Subject: Re: [Sip] Contact header in 1xx responses/updates remote >>>> target ornot? >>>> >>>> Dale, >>>> >>>> Not sure if I read your comment right, but RFC3261 12.2.1.2 says >>>> >>>> When a UAC receives a 2xx response to a target refresh request, it >>>> MUST replace the dialog's remote target URI with the >> URI from the >>>> Contact header field in that response, if present. >>>> It does not say anything about 1xx responses here >>>> though...Regards,Jeroen Dale.Worley@comcast.net wrote: >>>>> From: Nina Garaca >>>>> >>>>> Q1: Should I expect that these responses have a Contact header? >>>>> >>>>> As Paul says, if it didn't have a Contact header, it couldn't >>>>> establish a dialog. >>>>> >>>>> Q2: If they do so, should the remote target of the dialog be >>>>> refreshed by that Contact at the side that has received that 1xx >>>>> response and should the remote target of the dialog be >>>> refreshed by >>>>> the Contact in the INVITE request at the side that has >>>> received that >>>>> INVITE? >>>>> >>>>> Responses are not "target refresh requests", so they don't >>>> change the >>>>> target address at their end of the dialog. But of course, the >>>>> responses to the dialog-initiating request establish the initial >>>>> target address. >>>>> >>>>> Q3: If not, should the remote target of the dialog be >> refreshed by >>>>> the Contact in the INVITE request >>>>> at the side that has received that INVITE and has >> sent dialog >>>>> establishing 1xx response? >>>>> >>>>> RFC 3261 section 12.2: >>>>> >>>>> INVITE, the only target refresh request defined is >> re-INVITE (see >>>>> Section 14). Other extensions may define different >> target refresh >>>>> requests for dialogs established in other ways. >>>>> >>>>> Dale >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 16:44:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrVX-00073h-Q6; Thu, 31 May 2007 16:44:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtrVV-00073J-Iy for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 16:44:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrVV-00072m-7x for sip@ietf.org; Thu, 31 May 2007 16:44:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtrVU-0004hO-JP for sip@ietf.org; Thu, 31 May 2007 16:44:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 08E71201F3; Thu, 31 May 2007 22:44:28 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-d7-465f33abf753 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EB0E020018; Thu, 31 May 2007 22:44:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 31 May 2007 22:44:26 +0200 Message-ID: <7374777208BDC7449D5620EF94232567049910DA@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcejnY8yn2h1ODZpT+CeklJzvvJdsQAJWS0g References: <465E9331.8070909@zesium.com> From: "Christer Holmberg (JO/LMF)" To: "Dean Willis" , "Nina Garaca" X-OriginalArrivalTime: 31 May 2007 20:44:27.0620 (UTC) FILETIME=[7B052240:01C7A3C4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I have read rfc2976 - The SIP INFO Method, but I haven't really=20 >>understood that INFO message belongs only to INVITE dialog usage,=20 >>which however draft-ietf-sipping-dialogusage-04 claims in its part >>5.3: >> >> >> 5.3. Matching requests to usages >> >> >> >> For many mid-dialog requests, identifying the usage they belong to >> is obvious. A dialog can have at most one invite usage, so=20 >> any INVITE, UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. >> >> So my, question is: >> Can INFO message belong to other usages, besides INVITE, such are SUBSCRIBE or REFER? > > >=20 >=20 >There was IIRC no intent in the writing of RFC 2976 to restrict INFO =20 >to occurring within an INVITE dialog usage. So it could technically =20 >be used outside of one, including in non-dialog cases. Chapter 2 of 2976 says: "The INFO method is used for communicating mid-session signaling information along the signaling path for the call." I think "mid-session" rules out the non-dialog cases, doesn't it? On the other hand, chapter 4 says: "There is potential that INFO messages could be forked by a SIP Proxy Server." That should not happen in a mid-dialo case, should it? >However, RFC 2976 is considered to be somewhat underspecified, and so =20 >far the only place we've further specified its usage is in the =20 >context of transporting binary data for telephony protocol tunelling. =20 >We have a standing consensus to NOT use it for arbitrary data=20 >at this time. If we were to start using it, we'd need to do something like =20 >the event-packages model for INFO. So don't use it, and you won't =20 >have to deal with this . . . Eventhough not specified, in real life it IS used for sending DTMFs (which is also listed in 2976 as an example usage, eventhough we may have standing consensus on something else) and "non-telephony protocol" information. I would even use the word "de facto standard" in some cases. However, I am not aware of any non-INVITE dialog usage. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 16:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrW1-0007N7-KM; Thu, 31 May 2007 16:45:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HtrW0-0007Mw-9P for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 16:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtrVz-0007Mo-Vu for sip@ietf.org; Thu, 31 May 2007 16:44:59 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtrVy-0004if-Lt for sip@ietf.org; Thu, 31 May 2007 16:44:59 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l4VKiqDF018042; Thu, 31 May 2007 16:44:52 -0400 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 Subject: RE: [Sip] Treatment of ACK for 2xx final response Date: Thu, 31 May 2007 16:44:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Treatment of ACK for 2xx final response Thread-Index: AcejrZdUuf2War+yTuqRbybgvw+6HwAFushQ From: "Nayak, Subhransu S" To: "Kadirvelu, Kannan (Kanna)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The Invite Server transaction is completed as soon as the server on B = sends 200 OK to the original INVITE. ACK to 2XX response is considered a = separate transaction and in this case should be forwarded to TU by the = transaction layer.=20 Now if your question is whether the TU should honor this ACK and stop = re-transmitting 200 response, RFC 3261 is not clear about this. based on = your implementation the TU may choose to ignore this ACK with incorrect = branch and continue to retransmit 200 OK until an ACK with valid branch = is received or, there is a timeout ( 64 * T1 ). -----Original Message----- From: Kadirvelu, Kannan (Kanna) [mailto:kkannan@alcatel-lucent.com] Sent: Thursday, May 31, 2007 2:01 PM To: sip@ietf.org Subject: [Sip] Treatment of ACK for 2xx final response Hi All, We require some clarity on ACK processing on the UA server side.=20 Consider the following scenario :=20 A -- INVITE ----> B A <-- 200 OK ---- B A -- ACK -------> B A, B are SIP UAs.=20 In the above example, the SIP server A sent the ACK with same branch ID as that of INVITE. We know clearly A is in error. However we are not clear on what should be the behavior of B. Should the transaction layer of B absorb this ACK or send it to TU ?=20 Please help. Regards, Kannan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 16:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htrck-0003Sj-DE; Thu, 31 May 2007 16:51:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Htrci-0003Sd-TJ for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 16:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htrci-0003SV-Jc for sip@ietf.org; Thu, 31 May 2007 16:51:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htrch-0005Zk-0N for sip@ietf.org; Thu, 31 May 2007 16:51:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 60D58207F8; Thu, 31 May 2007 22:51:54 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-d8-465f356ade69 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 376A0203E3; Thu, 31 May 2007 22:51:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 22:51: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 Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Thu, 31 May 2007 22:51:52 +0200 Message-ID: <7374777208BDC7449D5620EF94232567049910F8@esealmw113.eemea.ericsson.se> In-Reply-To: <000201c7a2f1$b18240b0$10676b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? thread-index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DAABMy8AAAWbkUQADcdGcA= References: <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> <000201c7a2f1$b18240b0$10676b80@amer.cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dan Wing" , "DRAGE, Keith (Keith)" , "Gonzalo Camarillo (JO/LMF)" , "Paul Kyzivat" X-OriginalArrivalTime: 31 May 2007 20:51:53.0759 (UTC) FILETIME=[84F08AF0:01C7A3C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't object to your example, but wasn't message outside the scope of the document (it only deals with multipart)? So, a "valid" example would be a multipart containing another multipart. In any case, the text I was thinking about was not an example, but more generic text on what support is expected regarding nested body types. Regards, Christer=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: 30. toukokuuta 2007 22:36 > To: Christer Holmberg (JO/LMF); 'DRAGE, Keith (Keith)';=20 > Gonzalo Camarillo (JO/LMF); 'Paul Kyzivat' > Cc: sip@ietf.org > Subject: RE: [Sip] MIME: Nested bodies with option-tag? >=20 > > >Once we get down to a decision of supporting nested versus not=20 > > >supporting nesting, presumably we are then entirely in the=20 > realm of=20 > > >the multipart coding itself. > > >=20 > > >Could I ask someone to elaborate on what generic=20 > requirements already=20 > > >exist within multipart/mime in this respect, before we=20 > start looking=20 > > >at defining SIP specific rules or indications? > >=20 > > I am very sure that I have seen text related to the support=20 > of nested=20 > > multiparts, and what nodes are expected to support,=20 > somewhere, but I=20 > > yet have not found it. >=20 > message/rfc822 [RFC2046], which is used when you forward a=20 > message, routinely has nested multiparts when the message=20 > you're forwarding itself had multiple parts. It looks=20 > something like this: >=20 > From: dwing@cisco.com > To: bill@example.com > Content-Type: multipart/mixed; boundary=3DA > =20 > --A > Content-Type: text/plain > =20 > here is that email I mentioned during lunch. >=20 > --A > Content-Type: message/rfc822 >=20 > From: Sammy Sammython > Content-Type: multipart/mixed; boundary=3DB > Subject: Pictures from our recent trip > =20 > --B > Content-Type: text/plain > =20 > Here are the pictures from the island! Enjoy! >=20 > --B > Content-Type: image/jpg > Content-Transfer-Encoding: base64 >=20 > EKFEJKFIEUJKEJKEJFF ... >=20 > --B > Content-Type: image/jpg > Content-Transfer-Encoding: base64 >=20 > EKFEJKFIEUJKEJKEJFF ... >=20 > --B-- > --A-- >=20 > -d >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu May 31 19:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Httzp-0000B5-1n; Thu, 31 May 2007 19:23:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Httzn-0000B0-Ls for sip-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 19:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Httzn-0000As-CB for sip@ietf.org; Thu, 31 May 2007 19:23:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Httzn-0001u4-15 for sip@ietf.org; Thu, 31 May 2007 19:23:55 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 May 2007 16:23:54 -0700 X-IronPort-AV: i="4.16,371,1175497200"; d="scan'208"; a="157204008:sNHT46906695" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4VNNsWi027736; Thu, 31 May 2007 16:23:54 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VNNr20018170; Thu, 31 May 2007 23:23:53 GMT From: "Dan Wing" To: "'Christer Holmberg \(JO/LMF\)'" , "'DRAGE, Keith \(Keith\)'" , "'Gonzalo Camarillo \(JO/LMF\)'" , "'Paul Kyzivat'" Subject: RE: [Sip] MIME: Nested bodies with option-tag? Date: Thu, 31 May 2007 16:23:53 -0700 Message-ID: <068501c7a3da$c116bf80$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceh8ha/fHgBeC0BTfKQR3+Jzs2SpAABSq/QACEa4DAABMy8AAAWbkUQADcdGcAABV1/8A== In-Reply-To: <7374777208BDC7449D5620EF94232567049910F8@esealmw113.eemea.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3026; t=1180653834; x=1181517834; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20; bh=2r5lXDxNTT9dQuEFuFVyhfJVEjt/o6pacT0V3V3xr7k=; b=UkvOnbf97A+siAR4XChjnB44QqEAq8R3sqD/KwlnOZbJJ0AcIDlLKW0v/itwH/rUkBxZPe62 i8b+yzT5Auw6LQXgQJimhnMahWkD33wdTlqIjE4sBhdjJrcmwtOt6pwp; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I don't object to your example, but wasn't message outside > the scope of the document (it only deals with multipart)? So, > a "valid" example would be a multipart containing another > multipart. True. But that occurs when you forward a message containing two parts itself. > In any case, the text I was thinking about was not an > example, but more > generic text on what support is expected regarding nested body types. I'm thinking MUST be supported; otherwise, we'll be back here in another 5 years trying to noodle over adding nested multipart support because we tried to over-simplify things in 2007. -d > Regards, > > Christer > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: 30. toukokuuta 2007 22:36 > > To: Christer Holmberg (JO/LMF); 'DRAGE, Keith (Keith)'; > > Gonzalo Camarillo (JO/LMF); 'Paul Kyzivat' > > Cc: sip@ietf.org > > Subject: RE: [Sip] MIME: Nested bodies with option-tag? > > > > > >Once we get down to a decision of supporting nested versus not > > > >supporting nesting, presumably we are then entirely in the > > realm of > > > >the multipart coding itself. > > > > > > > >Could I ask someone to elaborate on what generic > > requirements already > > > >exist within multipart/mime in this respect, before we > > start looking > > > >at defining SIP specific rules or indications? > > > > > > I am very sure that I have seen text related to the support > > of nested > > > multiparts, and what nodes are expected to support, > > somewhere, but I > > > yet have not found it. > > > > message/rfc822 [RFC2046], which is used when you forward a > > message, routinely has nested multiparts when the message > > you're forwarding itself had multiple parts. It looks > > something like this: > > > > From: dwing@cisco.com > > To: bill@example.com > > Content-Type: multipart/mixed; boundary=A > > > > --A > > Content-Type: text/plain > > > > here is that email I mentioned during lunch. > > > > --A > > Content-Type: message/rfc822 > > > > From: Sammy Sammython > > Content-Type: multipart/mixed; boundary=B > > Subject: Pictures from our recent trip > > > > --B > > Content-Type: text/plain > > > > Here are the pictures from the island! Enjoy! > > > > --B > > Content-Type: image/jpg > > Content-Transfer-Encoding: base64 > > > > EKFEJKFIEUJKEJKEJFF ... > > > > --B > > Content-Type: image/jpg > > Content-Transfer-Encoding: base64 > > > > EKFEJKFIEUJKEJKEJFF ... > > > > --B-- > > --A-- > > > > -d > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip