Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt

From: [email-masked]
Date: Mon, 30 Jan 2017 14:31:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : Content ID header field in Session Initiation Protocol (SIP)
        Authors         : Christer Holmberg
                          Ivo Sedlacek
	Filename        : draft-ietf-sipcore-content-id-00.txt
	Pages           : 8
	Date            : 2017-01-30

Abstract:
   This document specifies the Content-ID header field for usage in the
   Session Initiation Protocol (SIP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sipcore-content-id-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jan 2017 18:18:02 -0500

I support the objectives of this draft, and the draft itself is a good 
start. Things were looking good to me until I got to section 1.5. From 
then on I am confused - I don't know whether I misunderstand what is 
written or disagree with it.

First, let me state my philosophical starting point:

I have always considered SIP messages to be themselves be an instance of 
an extension to the basic MIME format. Hence the sip message itself *is* 
a mime message, starting with mime headers and then a mime body. All the 
sip-specific header fields can be considered to be specialized new MIME 
header fields.

Viewed that way, all of the Content-* headers are simply inherited from 
MIME.

If the definition of SIP had been written that way then we wouldn't be 
doing this now. But it wasn't. I consider this draft a step toward 
getting to that state in a round-about way.

Now to my specific issues:

I really don't understand section 1.5. It seems to make all of those 
header types mandatory. They are all *allowed* in sip messages except 
(currently) the Content-ID. But none of them is *required*. And I don't 
think this draft will change that.

As I conceive it, the Content-ID in a sip message will identify the sip 
message itself as a referenced MIME message (that happens to contain 
some extension headers). (It may be necessary to exclude the initial 
line in the sip message, because it fails to conform to MIME syntax.)

When resolving a Content-ID URL within a SIP message, you search for a 
matching Content-ID header starting with the SIP message itself and then 
continuing recursively through any contained body parts of type multipart/*.

	Thanks,
	Paul