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

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Feb 2017 08:07:28 -0800

At 6:18 PM -0500 1/31/17, Paul Kyzivat wrote:

>  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.

My feelings exactly, and I was about to write a message saying so 
when I read Paul's.

>  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.

I agree, and I don't understand why the draft does so.  The draft 
should add Content-ID to the list of SIP header fields without also 
requiring any other header fields to be present.

>  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.)

I asked Ned about this (what does the Content-ID refer to) and he 
provided a good answer:

    The content-id refers to the MIME entity (RFC 2045 section 2.4),
    which would be the MIME subset of the message header and the body.

    It doesn't make sense for the content-id just to reference the body,
    since the body by itself lacks type and encoding information. On the
    flip side, it's a reach for the content-id to refer to the non-MIME
    stuff in the header - that function is provided by the message-id
    header.

>  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/*.

Makes sense.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ignorance is nothing more than indifference to what is before us;
we have only to pay attention--and we are paying attention in a way,
but to pretty noise, the newer the better.
--Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Feb 2017 12:11:15 -0500

Randall,

On 2/1/17 11:07 AM, Randall Gellens wrote:
>> 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.
>
> My feelings exactly, and I was about to write a message saying so when I
> read Paul's.
>
>>  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.
>>
>> be doing this now. But it wasn't. I consider this draft a step toward
>> getting to that state in a round-about way.
>>
>>  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.
>
> I agree, and I don't understand why the draft does so.  The draft should
> add Content-ID to the list of SIP header fields without also requiring
> any other header fields to be present.
>
>> 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.)
>

That is where my discussion about viewing a sip message as a mime 
message with extension headers comes in. When processed by an entity 
that only understands basic mime headers, all of the sip headers should 
be ignored as unknown.

Specifically, Request and Response are defined as follows:

   Request        =  Request-Line
                   *( message-header )
                   CRLF
                   [ message-body

   Response        =  Status-Line
                      *( message-header )
                      CRLF
                      [ message-body ]

For purposes of mime processing, everything following the Request-Line 
or Response-Line can be considered to constitute the mime message.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Feb 2017 19:36:42 +0000

Hi Randall & Paul,

Thanks for your comments!

I'll look more into the details later, but just an initial reply: the intention is not to mandate all headers to be present, so that will be fixed.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 01 February 2017 18:07
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt

> is written or disagree with it.

My feelings exactly, and I was about to write a message saying so when I read Paul's.

> don't think this draft will change that.

I agree, and I don't understand why the draft does so.  The draft should add Content-ID to the list of SIP header fields without also requiring any other header fields to be present.

> initial line in the sip message, because it fails to conform to MIME 

I asked Ned about this (what does the Content-ID refer to) and he provided a good answer:

>  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/*.

Makes sense.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Ignorance is nothing more than indifference to what is before us; we have only to pay attention--and we are paying attention in a way, but to pretty noise, the newer the better.
--Wyatt Mason, review of E.E. Cummings biography, Harper's May 2005.

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 2 Feb 2017 08:41:40 +0000

Hello,

> 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.

RFC3261 does not state that SIP messages are themselves an instance of an extension to the basic MIME format so the draft has not expected that.

> 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.

The intention of the draft was NOT to mandate those header fields.

The intention of the draft was to specify what forms the MIME body part identified by the Content-ID when the message-body of the SIP message is not of multipart/* MIME type.

The intention of the draft was to state that such MIME body part consists of:
- the message-body portion of the SIP message;
- a Content-Disposition header field if included in the message-header portion of the SIP message;
- a Content-Encoding header field if included in the message-header portion of the SIP message;
- a Content-Language header field if included in the message-header portion of the SIP message;
- a Content-Length header field if included in the message-header portion of the SIP message;
- a Content-Type header field if included in the message-header portion of the SIP message; and
- a Content-ID header field itself if included in the message-header portion of the SIP message.

MIME-Version header field (if included in the message-header portion of the SIP message) should be included as well, but the draft omitted that.

Any other SIP header fields included in the message-header portion of the SIP message would NOT be part of the MIME body part.

> 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.)

I think we deviate only on whether non-MIME headers (e.g. Via) would be consider a part of the MIME body part identified by the Content-ID.
- in your proposal, this would be the case.
- in the draft, this would not be the case.

> 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/*.

I agree on this.

Kind regards

Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Feb 2017 11:39:09 -0500

> RFC3261 does not state that SIP messages are themselves an instance of an extension to the basic MIME format so the draft has not expected that.

I realize it doesn't say this, and AFAIK it wasn't intended that way either.

Nevertheless, AFAIK viewing it that way will cause no problems. I think 
we are free to retroactively declare it so.

> - in the draft, this would not be the case.

OK, that clarifies things. It is worthwhile to discuss the pros and cons.

As you are proposing it, if an implementation is trying to integrate 
with existing mime-processing software it will be necessary to 
*construct* this synthetic mime-message, from selected messages and the 
body of the sip message. That seems painful.

As I'm suggesting, it is sufficient to hand over a pointer to the first 
header line in the message. Then the processing software will be 
obligated to ignore header fields it doesn't understand. But IIUC 
typical mime processing software is already expected to do that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Feb 2017 12:11:00 +0000

Hi,

>body of the sip message. That seems painful.

How is that different from today?

The other Content-X header have been defined as SIP header fields since
the beginning of time, so software needs to be able to handle them.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 3 Feb 2017 12:38:15 -0500

> How is that different from today?

I did an implementation a long time ago (and long gone) that did it as I 
describe - nothing had to be copied to do mime processing.

I guess we should really simply be describing the semantics without 
suggesting that this needs to be implemented in a particular way.

I think we are in rough agreement of what the conceptual meaning is. We 
just have to find words that are clear.

	Thanks,
	Paul