Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
Christer Holmberg <christer.holmberg@ericsson.com> Wed, 24 May 2017 06:22 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C30126E3A; Tue, 23 May 2017 23:22:53 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 90D0ZJqPp7W2; Tue, 23 May 2017 23:22:52 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B32881204DA; Tue, 23 May 2017 23:22:51 -0700 (PDT)
X-AuditID: c1b4fb2d-5a49e9a000000d37-e5-592526765221
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.8D.03383.67625295; Wed, 24 May 2017 08:21:42 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Wed, 24 May 2017 08:21:40 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ben Campbell <ben@nostrum.com>
CC: "draft-ietf-sipcore-content-id.all@ietf.org" <draft-ietf-sipcore-content-id.all@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05
Thread-Index: AQHSzolPaE+D+c83j0ekLBIazLog+6IAT7OAgABMwwCAAnGaEA==
Date: Wed, 24 May 2017 06:21:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBC5FC9@ESESSMB109.ericsson.se>
References: <B9456A83-63CA-492C-89AB-622A024681A5@nostrum.com> <D548A4E4.1CFD7%christer.holmberg@ericsson.com> <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com>
In-Reply-To: <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7qO5ONdVIg+ltJhbzO0+zW8w8u4vF 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV0bDPYOCWw4Vy/61sTcwtth3MXJy SAiYSJzbuJmxi5GLQ0jgCKPE22UXmCGcxYwSW97NAspwcLAJWEh0/9MGaRARUJJ43ryVBaSG WaCDUeLpkj5WkISwgJ1E07I5TCD1IgL2EvuniEPUO0k8etDNBGKzCKhKrFr1ggWkhFfAV2LD L1WIVUsZJb717gFr5QRqffFKDqScUUBM4vupNWCtzALiEreezGeCuFlAYsme88wQtqjEy8f/ WCFsJYnGJU9YQcYwC2hKrN+lD9GqKDGl+yE7iM0rIChxcuYTlgmMorOQTJ2F0DELSccsJB0L GFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRGysEtv3V3MK5+7XiIUYCDUYmHt15ANVKI NbGsuDL3EKMEB7OSCK+JGFCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZqakF qUUwWSYOTqkGRp0EpgiTt1LHtSZ37hM4HRn3RTiHVbxCWf/30Wk/TvqmHJ/L/fjlelnbL3F3 trNwBrdH/dq19zhr/lLOuT8n/fBd9rU6p70peFZ953uLR5sFTYtm/rhS8Jep2TRqm/O5htem qpnsFdksosq5F+ZMKfB78bHkzWKebUXbM+aff7tcTLPFZ1JKqxJLcUaioRZzUXEiAJkkqT6Q AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/tXQqfXUQxfRTJxcxiaEp2Gz5D-8>
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 06:22:54 -0000
Hi, Discussion Points: >>>- I have some difficulty seeing the difference between "the body and >>>related metadata" and "the SIP message". I realize you have the more >>>MIME-specific header fields in mind when you say "metadata". But any >>>SIP header field could be considered metadata. >> >> (Christer) As metadata, we are only considering SIP header fields >> that are also defined as MIME header fields. >> >>>The main point of that question is, as used in MIME, Content-Id is >>>intended to label a body part. Message-Id is used to label the whole >>>message. Aren't we talking about the whole message here? >> >> (Christer) No. > >We are borrowing this from the usage in email, where people usually >consider _all_ the header fields as metadata, thus the usage of >"Message-Id" rather than "Content-Id" when referring to the entire >contents. I¹m not saying it¹s wrong to do it differently for SIP, but >it would be good to include some motivation for that difference. I >suspect the difference has to do with the purpose of email being to >deliver the content, while for SIP the purpose of the content is to >modify the handling of session initiation. In which case one might >consider the content itself as ³metadata². (I¹m curious to hear if >there are other >reasons.) (Christer) I have to say that I am getting a little lost... With a multipart body, each body part MIME can contain MIME header fields providing metadata for that specific body part. With a non-multipart body, you can today do the same thing using MIME header fields that have been defined as SIP header field (Content-This, Content-That). However, Content-ID has not been defined as a SIP header field, and that is what we do in the draft. We are not adding new metadata, or extending the scope of the metadata - we simply allow using the same metadata to describe a non-multipart body as you can use to describe body parts in a multipart body. If your issue is caused by usage of the term "metadata" without a formal definition, then we can define the term "metadata" as "a MIME-Version SIP header field and any 'Content-' prefixed SIP header field". Or, we can replace any occurrence of the term "metadata" with "a MIME-Version SIP header field and any 'Content-' prefixed SIP header field" in the draft. >>>- Is there an expectation for the SIP Content-ID header field value >>>to be referenced from outside the SIP message? If so, what are the >>>uniqueness expectations? Note that for MIME, Content-ID is expected to >>>be globally unique. Is that the case here? >> >>(Christer) The draft does not change the uniqueness requirements of >>Content-ID. >> >>>If the Content-ID is _not_ expected to be referenced from outside of >>>the SIP message that contains it, then we have a sort of degenerate >>>case where it always identifies _this_ message regardless of the >>>value. Does that value ever need to change? Does that suggest >any >>>guidance on how to construct values? >> >>(Christer) RFC 5621 does not define the above characteristics for >>multipart body usage, and I see no reason how anything would be >>different for a non-multipart message body. If you think there is >>something generic about Content-ID that needs to be clarified I think >>that should be done as a separate task. > >5261 used the Content-Id MIME header field. That field and it¹s >uniqueness requirements are defined elsewhere. This draft defines a >Content-ID sip header field. That didn¹t exist before. Therefore I >think this needs to describe the uniqueness requirements. > >5322 requires msg-id to be globally unique because it¹s intended to be >useful outside the context of the given message. Is that the case here? >If not, then a globally uniqueness requirement may not make sense in >this context. (IIUC, every single instance of the Content-Id SIP header >field could have the same, identical value, and things would work >fine.) (Christer) I have never heard about Content-ID being used outside the context of a given message, so I think the value only needs to be unique within a given message. Specific comments: >>>1.4 and children: These examples seem like fairly weak motivation, >>>since I assume in both cases one could still have just put a single >>>body-part inside a multipart envelope. That >>>seems more an "inconvenience" than a "problem". Are there any known >>>use-cases where that would not be possible? (This is certainly not a >>>show stopper; we are allowed to solve >>>inconveniences. But if there are any stronger motivations that could >>>be documented, they might save questions down the road.) >> >>(Christer) I can't think of any use-cases where it would not be >>possible to use a single-body inside a multipart envelope instead. So, >>it is about "convenience". > >The word "optimization" comes to mind. (Christer) I guess that works too :) >>>3.2, 2nd note: How has the msg-Id been simplified, and why? >> >> (Christer) The simplification was done based on a comment from Dale W. >> >> https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html > >I think it would be helpful to say something like ³Š simplified to >disallow the use of comments and to adapt to SIP¹s use of leading white >space." (Christer) Ok, we¹ll add some text. Editorial: >>>1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version. >> >>(Christer) That¹s strange. I checked the XML file, and everything >>seems correct. Could the fact that the sentence starts with the >>reference have anything to do with it? >> >><t><xref target="RFC5621" pageno="false" format="default"/> defines >>generic handling of a multipart message-body in a SIP message.</t> > >I don¹t know, it may be an xml2rfc bug. If there¹s no error in the xml, >then we could leave this to the RFC editor. (Christer) Ok. Regards, Christer
- [sipcore] AD Evaluation of draft-ietf-sipcore-con… Ben Campbell
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Christer Holmberg
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Christer Holmberg
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Ben Campbell
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Christer Holmberg
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Ben Campbell
- Re: [sipcore] AD Evaluation of draft-ietf-sipcore… Christer Holmberg