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