[Sip] Multipart/related body handling

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 28 July 2008 12:59 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CEC3A68FA; Mon, 28 Jul 2008 05:59:21 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C7F3A68FA for <sip@core3.amsl.com>; Mon, 28 Jul 2008 05:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G0U1FZ7vq5d for <sip@core3.amsl.com>; Mon, 28 Jul 2008 05:59:18 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6DA063A6964 for <sip@ietf.org>; Mon, 28 Jul 2008 05:59:18 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EB2DA20592 for <sip@ietf.org>; Mon, 28 Jul 2008 14:59:26 +0200 (CEST)
X-AuditID: c1b4fb3c-ab095bb00000193b-c9-488dc2ae6e2e
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CC023204EB for <sip@ietf.org>; Mon, 28 Jul 2008 14:59:26 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 14:59:26 +0200
Received: from [164.48.29.42] ([164.48.29.42]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 14:59:26 +0200
Message-ID: <488DC2AC.4040705@ericsson.com>
Date: Mon, 28 Jul 2008 15:59:24 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: sip <sip@ietf.org>
X-OriginalArrivalTime: 28 Jul 2008 12:59:26.0740 (UTC) FILETIME=[C3F2B540:01C8F0B1]
X-Brightmail-Tracker: AAAAAA==
Subject: [Sip] Multipart/related body handling
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

Hi,

an open issue in the following draft is how to handle multipart/related:

http://www.ietf.org/internet-drafts/draft-ietf-sip-body-handling-02.txt

The draft currently recommends to follow the original multipart/related 
spec [RFC 2387]:

    Per [RFC2387], a
    UA processing a 'multipart/related' body processes it as a compound
    object ignoring the disposition types of the body parts within it.

http://www.ietf.org/rfc/rfc2387.txt

However, there have been some discussions about SIP needing to take into 
account the disposition types of the body parts. The following draft 
illustrates why you need to take into account the body parts' 
disposition types to distinguish between XCAP diff and a resource list:

http://www.ietf.org/internet-drafts/draft-roach-sip-list-subscribe-bodies-00.txt

An example of a SIP extension that already uses multipart/related is:

http://www.ietf.org/rfc/rfc4662.txt

The current proposal is to specify that, in SIP, the content disposition 
of the body parts within a multipart/related need to be considered. The 
difference between multipart/mixed and multipart/related would be that 
multipart/related would be used when the different body parts are 
related to each other through a root body, as opposed to unrelated body 
parts.

If nobody has a problem with this, we will be updating the draft 
accordingly. We will probably moving the multipart/related stuff to a 
different section, since now it appears in the guidelines section.

Cheers,

Gonzalo
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip