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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 06 October 2016 12:59 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 42F49129647 for <ecrit@ietfa.amsl.com>; Thu, 6 Oct 2016 05:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 medF9XbJL8eW for <ecrit@ietfa.amsl.com>; Thu, 6 Oct 2016 05:59:24 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A7548129644 for <ecrit@ietf.org>; Thu, 6 Oct 2016 05:59:23 -0700 (PDT)
X-AuditID: c1b4fb3a-e95069800000099a-9b-57f64aa92eb3
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 05.20.02458.9AA46F75; Thu, 6 Oct 2016 14:59:22 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Thu, 6 Oct 2016 14:58:42 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: Content-ID: Way forward without SIPCORE impact
Thread-Index: AQHSH9FdW92vWNIey0OuUNcxPMNfjQ==
Date: Thu, 06 Oct 2016 12:58:42 +0000
Message-ID: <D41C26AC.10977%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_D41C26AC10977christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7h+4qr2/hBpMcLBoXPWV1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG3nfXmAsWC1W0blzN3MC4iL+LkZNDQsBE4sO5ncxdjFwcQgLr GSWWrt7JBJIQEljEKHGpMbaLkYODTcBCovufNkhYREBVYsOZlYwgtrCAucSfbzeYIeI2ElO/ 3WEGKRcR0JPY/yMAJMwioCLR+OIrO4jNK2At8bH7K1gro4CYxPdTa8A2MQuIS9x6Mp8J4hwB iSV7zjND2KISLx//YwWxRYFGfv86GyquKLHzbDszRG+CxNe3E9kg5gtKnJz5hGUCo9AsJGNn ISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPgXo5gGxriX2LY5CVLGDkWMUoWpxaXJybbmSk l1qUmVxcnJ+nl5dasokRGCMHt/y22sF48LnjIUYBDkYlHt4F9l/DhVgTy4orcw8xSnAwK4nw /nP/Fi7Em5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QDY6Gy feyMm4f4XukKrTSQSHqbe1RzqzuP/oLgo2ks21Mv7FV1XKJ7scl//uNF+ZKSsZvvRfQHuSdW Zy1u7FlZ/qumY27TFKZjO5Y53bUJMFnDstWlcXuKwP5JJ6V3qposmXhjT9+TbfuDWlvZSzzz JDiWTdtnIbePecu6I1/9/9xxFLuXLXLWRYmlOCPRUIu5qDgRAB2qdZONAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/tyj6UaLj6DZwZ_NhZeVJWzhIhr4>
Subject: [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 12:59:25 -0000

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.

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)