Subject: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Aug 2016 13:50:51 +0000

Hi,

When a SIP message contains a multipart/mixed body, individual body parts can be associated with a Content-ID header field and header fields of the SIP message can refer to those body parts. Note that the Content-ID is not a SIP header field in such cases, but a MIME header field related to the individual body part.

However, in ECRIT it was identified that there are cases where a request with a single message body also needs a Content-ID header field as header fields of SIP message needs to refer to the body – in which Content-ID it needs to become a SIP header field.

Later, it was also realised that there exist non-ECRIT cases where it is also needed.

Please see the draft for examples.

We have submitted a draft, which gives description of the problem and defines the Content-ID header field for SIP.

For the GitHub fans: https://github.com/cdh4u/draft-content-id (NOTE: Individual repo)
<https://github.com/cdh4u/draft-content-id>

Regards,

Christer & Ivo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Aug 2016 11:39:45 -0400

Quick turnaround! It seems to do the job, and I especially like the 
conciseness of the abstract.

I'm just wondering if there are any other things like this that ought to 
be included.

ISTM that RFC2042 can be considered a "base class" for a family of 
message syntaxes that share a common style. Viewed that way, SIP ought 
to support all of the header fields defined in RFC2042. Those include:

- mime-version
- content-type
- content-transfer-encoding
- content-id
- content-description

It also generically adopts <Any RFC 822 header field which begins with 
the string "Content-">.

Unfortunately none of this seems to be defined in a way that is intended 
to support this sort of subclassing model. So it isn't straightforward 
to simply declare SIP to be a subclass of MIME and leave it at that.

But we could define the others one by one, by reference.

	Thanks,
	Paul

On 8/16/16 9:50 AM, Christer Holmberg wrote:
>
> Hi,
>
> When a SIP message contains a multipart/mixed body, individual body
> parts can be associated with a Content-ID header field and header fields
> of the SIP message can refer to those body parts. Note that the
> Content-ID is not a SIP header field in such cases, but a MIME header
> field related to the individual body part.
>
> However, in ECRIT it was identified that there are cases where a request
> with a single message body also needs a Content-ID header field as
> header fields of SIP message needs to refer to the body – in which
> Content-ID it needs to become a SIP header field.
>
> We have submitted a draft, which gives description of the problem and
> defines the Content-ID header field for SIP.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 17 Aug 2016 11:37:14 +0000

Hello,

thank you for the comments.

> to support all of the header fields defined in RFC2042. Those include:

Would the MIME-Version header field be included in header fields of a SIP message solely when the SIP message contains one body, or would it be included in case when SIP message contains several bodies? 

BTW, HTTP MIME-Version header field is specified - see http://www.iana.org/assignments/message-headers/message-headers.xhtml 

> - content-type

MIME Content-Type header field defined in RFC2045 matches the SIP Content-Type header field defined in RFC3261. Please note that ABNF for SIP Content-Type header field is based on ABNF in RFC2616 while ABNF for MIME Content-Type header field is in RFC2045.

So, IMO, everything is in place for Content-Type.

> - content-transfer-encoding

Is this really needed? SIP provides binary transport.

HTTP Content-Transfer-Encoding header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml

> - content-id

This is proposed to be specified the draft.

> - content-description

HTTP Content-Description header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml

> It also generically adopts <Any RFC 822 header field which begins with 

On top of the above, http://www.iana.org/assignments/message-headers/message-headers.xhtml additionally gives the following MIME or HTTP headers:
- Content-Alternative - in MIME, not in HTTP (and not available in SIP)
- Content-Base - in MIME, in HTTP (and not available in SIP). Marked as "obsoleted"
- Content-Disposition - in MIME, in HTTP (and available in SIP)
- Content-Duration - in MIME, not in HTTP (and not available in SIP)
- Content-Encoding - not in MIME, in HTTP (and available in SIP)
- Content-features - in MIME, not in HTTP (and not available in SIP)
- Content-Language - in MIME, in HTTP (and available in SIP)
- Content-Length - not in MIME, in HTTP (and available in SIP)
- Content-Location - in MIME, in HTTP (and not available in SIP)
- Content-MD5 - in MIME, in HTTP (and not available in SIP)
- Content-Range - not in MIME, in HTTP (and not available in SIP)
- Content-Script-Type - not in MIME, in HTTP (and not available in SIP)
- Content-Style-Type - not in MIME, in HTTP (and not available in SIP)
- Content-Version - not in MIME, in HTTP (and not available in SIP)

Not sure whether any header fields of the above (which are not in SIP already) are useful for SIP.

Kind regards

Ivo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Aug 2016 12:02:02 +0000

Hi,

>Would the MIME-Version header field be included in header fields of a SIP
>message solely when the SIP message contains one body, or would it be
>included in case when SIP message contains several bodies?
>
>BTW, HTTP MIME-Version header field is specified - see
>http://www.iana.org/assignments/message-headers/message-headers.xhtml

MIME-Version is already defined as a SIP header field in RFC 3261, and you
can see usage examples e.g. in RFC 3204.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Aug 2016 15:39:07 -0400

Ivo,

>> to support all of the header fields defined in RFC2042. Those include:

Just to be clear - I am not well schooled on all the intricacies of 
MIME. So I'm not sure which of these header fields might be (or not be) 
relevant for SIP. I brought it up to encourage a broader discussion.

> BTW, HTTP MIME-Version header field is specified - see http://www.iana.org/assignments/message-headers/message-headers.xhtml

I think this is not clear. The 3261 definition is simply a reference to 
HTTP (RFC2616), without any explanation. And RFC2616 isn't very clear 
about it either - but does say its use is optional.

So this may deserve some clarification.

> So, IMO, everything is in place for Content-Type.

Yep.

> HTTP Content-Transfer-Encoding header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml

Since sip provides for binary transfer it does seem *unnecessary*. For 
some uses it might still be convenient if somebody has an already 
encoded body they want to include. The downside is that it would not be 
backward compatible.

I guess it is currently still possible as long as used in one part of a 
multipart body.

> HTTP Content-Description header field is NOT specified either - see http://www.iana.org/assignments/message-headers/message-headers.xhtml

Since it seems to be intended solely for human consumption it doesn't 
seem very important.

> On top of the above, http://www.iana.org/assignments/message-headers/message-headers.xhtml additionally gives the following MIME or HTTP headers:

I was looking for a registry and didn't find it.

> Not sure whether any header fields of the above (which are not in SIP already) are useful for SIP.

Unfortunately ISTM that MIME hasn't been managed in a way that clearly 
separates those parts that are generic from those that are only 
meaningful for mail. (But I haven't studied all the docs, so maybe I'm 
wrong about this.)

Clearly http has done its own picking and choosing, as has sip. But the 
criteria for doing so aren't so obvious.

The current experience with content-id shows that potentially any mime 
body might make sense in a sip message. ISTM the question we need to ask 
is where to draw the line between those that can be included directly, 
vs. those that can only be included by wrapping them in another layer of 
mime wrapper.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Aug 2016 12:25:56 +0000

Hi,

I don¹t think we shall try to ³fix everything². We know that such work may
take forever.

The draft identifies the problem with Content-ID. If someone else know
about similar problems with other header fields, please bring it to the WG.

Obviously, if we think that the definition of some header field that IS
already defined for SIP (e.g. MIME-Version) is unclear, we can discuss
whether we should fix that.

But, let¹s work to fix the stuff that people need. If people need
something else in future, they can write a draft...

Regards,

Christer

On 17/08/16 22:39, "sipcore on behalf of Paul Kyzivat"
<[email-masked] on behalf of [email-masked]> wrote:

>> Would the MIME-Version header field be included in header fields of a
>>SIP message solely when the SIP message contains one body, or would it
>>be included in case when SIP message contains several bodies?
>>
>> MIME Content-Type header field defined in RFC2045 matches the SIP
>>Content-Type header field defined in RFC3261. Please note that ABNF for
>>SIP Content-Type header field is based on ABNF in RFC2616 while ABNF for
>>MIME Content-Type header field is in RFC2045.
>>
>> HTTP Content-Transfer-Encoding header field is NOT specified either -
>>see http://www.iana.org/assignments/message-headers/message-headers.xhtml
>
>> HTTP Content-Description header field is NOT specified either - see
>> On top of the above,
>>additionally gives the following MIME or HTTP headers:
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 18 Aug 2016 13:02:55 +0000

Hello,

Content-ID header field definition for SIP is definitely needed.

RFC5368 already contains an example of its usage in Figure 3:

------------

   REFER sip:[email-masked];gruu;opaque=hha9s8d-999a  SIP/2.0

   Via: SIP/2.0/TCP client.chicago.example.com

           ;branch=z9hG4bKhjhs8ass83

   Max-Forwards: 70

   To: "Conference 123" <sip:[email-masked]>

   From: Carol <sip:[email-masked]>;tag=32331

   Call-ID: d432fa84b4c76e66710

   CSeq: 2 REFER

   Contact: <sip:[email-masked]>

   Refer-To: <cid:[email-masked]>

   Refer-Sub: false

   Require: multiple-refer, norefersub

   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

   Allow-Events: dialog

   Accept: application/sdp, message/sipfrag

   Content-Type: application/resource-lists+xml

   Content-Disposition: recipient-list

   Content-Length: 362

   Content-ID: <[email-masked]>

   <?xml version="1.0" encoding="UTF-8"?>

   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"

           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

     <list>

       <entry uri="sip:[email-masked]?method=BYE" />

       <entry uri="sip:[email-masked]?method=BYE" />

       <entry uri="sip:[email-masked]?method=BYE" />

     </list>

   </resource-lists>

            Figure 3: REFER request with multiple REFER-Targets

------------

and RFC5368 is referenced by specifications of other standardization organizations (e.g. in OMA Push-To-Talk-over-Cellular OMA-TS-PoC_ControlPlane-V1_0_3-20090922-A), so Content-ID can be used as shown above in real networks.

So, it would be nice to close the gap rather soon.

I have no view on whether other Content-* header fields missing in SIP are needed in SIP or not.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Christer Holmberg
Sent: Thursday, August 18, 2016 2:26 PM
To: Paul Kyzivat; Ivo Sedlacek
Cc: SIPCORE
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00

Hi,

I don¹t think we shall try to ³fix everything². We know that such work may take forever.

The draft identifies the problem with Content-ID. If someone else know about similar problems with other header fields, please bring it to the WG.

Obviously, if we think that the definition of some header field that IS already defined for SIP (e.g. MIME-Version) is unclear, we can discuss whether we should fix that.

But, let¹s work to fix the stuff that people need. If people need something else in future, they can write a draft...

Regards,

Christer

>>> message syntaxes that share a common style. Viewed that way, SIP

>>> ought to support all of the header fields defined in RFC2042. Those include:

>>Content-Type header field defined in RFC3261. Please note that ABNF

>>for SIP Content-Type header field is based on ABNF in RFC2616 while

>>ABNF for MIME Content-Type header field is in RFC2045.

>>see

>>> It also generically adopts <Any RFC 822 header field which begins

>>> with the string "Content-">.

>> - Content-Alternative - in MIME, not in HTTP (and not available in

>>SIP)

>> - Content-Base - in MIME, in HTTP (and not available in SIP). Marked

>>as "obsoleted"

>> - Content-Script-Type - not in MIME, in HTTP (and not available in

>>SIP)

>> - Content-Style-Type - not in MIME, in HTTP (and not available in

>>SIP)

>> Not sure whether any header fields of the above (which are not in SIP

>>already) are useful for SIP.

>body might make sense in a sip message. ISTM the question we need to

>ask is where to draw the line between those that can be included

>directly, vs. those that can only be included by wrapping them in

>another layer of mime wrapper.

>[email-masked]<mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2016 10:13:49 -0400

> something else in future, they can write a draft...

OK. In spite of my desire for completeness I can accept sticking with 
just the immediate need.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 Aug 2016 15:18:21 -0700

>  Is this really needed? SIP provides binary transport.

When defining MIME types, it's usual to specify the content transfer 
encoding that is used.  So, it seems useful to permit 
Content-Transfer-Encoding as a SIP header field.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The trouble with doing anything right the first time is that nobody
appreciates how difficult it was.

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 26 Aug 2016 06:57:55 +0000

Hello,

> When defining MIME types, it's usual to specify the content transfer encoding that is used.  So, it seems useful to permit Content-Transfer-Encoding as a SIP header field.

Information in registration template state what sort of data a MIME type can consist of since some transports impose restrictions on the type of data they can carry. See rfc6838 section 4.8. 

However, SIP does not impose any such restriction.

Can you please give a use case where a SIP Content-Transfer-Encoding header field would be needed? Thank you.

Kind regards

Ivo

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Friday, August 26, 2016 12:18 AM
To: Ivo Sedlacek; Paul Kyzivat; [email-masked]
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-content-id-00

>  Is this really needed? SIP provides binary transport.

When defining MIME types, it's usual to specify the content transfer encoding that is used.  So, it seems useful to permit Content-Transfer-Encoding as a SIP header field.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- The trouble with doing anything right the first time is that nobody appreciates how difficult it was.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2016 12:02:02 -0400

> Content-Transfer-Encoding as a SIP header field.

Adding content-transfer-encoding to sip could cause backward 
compatibility problems. For instance, if I overrode the 
content-transfer-encoding for and INVITE with SDP, would the recipient 
be expected to be capable of decoding it?

While it could have value in some cases, if we were to do it we would 
have to add some rules for backward compatibility.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 26 Aug 2016 16:56:48 -0400

> have to add some rules for backward compatibility.

Well, there are three examples of "Content-Transfer-Encoding: base64" in
section 23 of RFC 3261.

What we're going to have to do is what people do in practice, only use
the Content-Transfer-Encoding header in the message if the body is one
of those media types that is commonly transported using a
content-transfer-encoding.  In practice, that is
application/pkcs7-signature and application/pkcs7-mime.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2016 17:09:45 -0400

> Well, there are three examples of "Content-Transfer-Encoding: base64" in

Yes, but those are all contained in subordinate body parts of a top 
level multipart body.

We are talking about defining content-transfer-encoding as a valid 
top-level header field in sip.

> application/pkcs7-signature and application/pkcs7-mime.

In practice that would be the sensible thing to do.

But I hate to leave it to common sense. I would rather have the valid 
usage well defined.

For the moment this is simply a hypothetical discussion - an 
extrapolation beyond the proposal to define content-id as a sip header 
field.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 26 Aug 2016 14:28:36 -0700

At 5:09 PM -0400 8/26/16, Paul Kyzivat wrote:

> extrapolation beyond the proposal to define content-id as a sip 
> header field.

I was thinking it might be useful, but in view of the extra 
complexity, I don't think it should be addressed in the Content-ID 
draft.

-------------- Randomly selected tag: ---------------
There is so much to be said in favor of modern journalism.
By giving us the opinions of the uneducated, it keeps us in touch
with the ignorance of the community.                --Oscar Wilde

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2016 17:32:13 -0400

On 8/26/16 5:28 PM, Randall Gellens wrote:
> I was thinking it might be useful, but in view of the extra complexity,
> I don't think it should be addressed in the Content-ID draft.

Yes. In the interest of expediency I am fine with addressing content-id 
by itself now, and possibly taking up other content-* at some later date.

	Thanks,
	Paul