Re: [Ecrit] Content-ID: Way forward without SIPCORE impact

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 06 October 2016 15:40 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE701296D8 for <ecrit@ietfa.amsl.com>; Thu, 6 Oct 2016 08:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMgml7KIK274 for <ecrit@ietfa.amsl.com>; Thu, 6 Oct 2016 08:40:21 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642611296CE for <ecrit@ietf.org>; Thu, 6 Oct 2016 08:40:20 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-10v.sys.comcast.net with SMTP id sAm0bsgpmRingsAmRbPyG6; Thu, 06 Oct 2016 15:40:19 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-02v.sys.comcast.net with SMTP id sAmRbRdO7ervfsAmRbOHO6; Thu, 06 Oct 2016 15:40:19 +0000
To: ecrit@ietf.org
References: <D41C26AC.10977%christer.holmberg@ericsson.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <f8d9fb49-0e46-ac95-1464-a1607dad5486@alum.mit.edu>
Date: Thu, 06 Oct 2016 11:40:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <D41C26AC.10977%christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfH9/YJEJFaEyceMXgwm1h6PWIvIhYCN/TMFW/28z9NBFsMA4K1C01oglueShbdauTpQt1ICNcp2e+70dBL/qhRFXSnhYdISKQhqZtKHsWJSONws+vOBz sy1Re81O9NrqMa77vKLH6YKK+2TghTY/DsOZIyGHC8q1/17iIVrlIB7C
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/HIN6kJhHF5MwNPGpYUku1jLNn3o>
Subject: Re: [Ecrit] Content-ID: Way forward without SIPCORE impact
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2016 15:40:22 -0000

On 10/6/16 8:58 AM, Christer Holmberg wrote:
> Hi,
>
> One way to solve the Content-ID issue would be to ALWAYS use a multipart
> MIME, even if we only carry one body part. See example in section
> 12.2.2.3 of RFC 6086.

This is certainly a possibility

	Thanks,
	Paul

> Another advantage would be that we would always the same
> Content-Disposition header field value for the MSD/control body parts.
> Currently the value is dependent on whether there are other body parts
> in the message or not, which is a little strange. So, the multipart/MIME
> would have C-D:info-package and the MSD/control body part would have
> C-D:by-reference.
>
> Comments?
>
> Regards,
>
> Christer
>
> (It may still be a good idea to define usage of Content-ID for SIP, but
> then the ECRIT specs would not be held up due to that work)
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>