Subject: [sipcore] Comments on draft-ietf-sipcore-content-id-01

From: [email-masked] (Dale R. Worley)
Date: Mon, 10 Apr 2017 17:49:40 -0400

The short title is "Content-ID-in-SIP", whereas it seems more natural
to use "Content-ID in SIP".

Table of Contents

     1.1.  Setting up ID value uniquely identifying body . . . . . .   2
     1.2.  Referencing the ID value uniquely identifying body  . . .   3

This seems an awkward way of phrasing it.  In particular, there seems
to be no reason to emphasize uniqueness here.  Perhaps

     1.1.  Establishing a Content-ID identifying the body
     1.2.  Referencing the Content-ID value identifying the body

--

     5.1.  Header Field  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

These items capitalize later words, whereas the other items capitalize
only initial words.  It seems that the current RFC style heavily
favors capitalizing all the "important" words in section titles.

1.  Introduction

   A message-body of the SIP message can contain one body only or can
   contain several body parts, as specified in [RFC3261] and [RFC5621].

Strictly speaking, a SIP message containing several body parts also
has a body (whose MIME type is multipart/something).  I think it would
be better to phrase this

   A message-body of the SIP message can be a non-multipart body or
   can be a multipart body that contains several body parts, as
   specified in [RFC3261] and [RFC5621].

I think this can be carried through to other places that use the
phrase "one body".  (Although "one body" is a close version of the
phrase "unitary body", which would be a good term for "non-multipart
body", though nobody uses the phrase!)

1.5.  Solution

Section 1.5 looks much like section 3.3, and I think the duplication
should be reduced.  Perhaps the text in 1.5 could be reduced to

   The Content-ID header field included in header fields of a SIP
   message identifies a body part consisting of the message-body of
   the SIP message.  The metadata provided by some additional header
   fields also applies to the message body as a whole.

3.2.  Syntax

   The ABNF for the Content-ID header fields is:

   Content-ID = "Content-ID" HCOLON msg-id

   NOTE: msg-id is specified in [RFC5322].

Comparing with RFC 5322, I see:

   msg-id          =   [CFWS] "<" id-left "@" id-right ">" [CFWS]

   CFWS            =   (1*([FWS] comment) [FWS]) / FWS

   comment         =   "(" *([FWS] ccontent) [FWS] ")"

I'm sure we don't want to allow comments!

I can see a couple of ways to avoid this.  One is to annotate it:

   The ABNF for the Content-ID header fields is:

   Content-ID = "Content-ID" HCOLON msg-id

   NOTE: msg-id is specified in [RFC5322], but may not contain
   "comment".

But this allows RFC 5322's FWS, which is slightly broader than RFC
3261's SWS.  Probably best is to force the whitespace to be in the
style of RFC 3261:

   The ABNF for the Content-ID header fields is:

   Content-ID = "Content-ID" HCOLON msg-id

   msg-id     = "<" id-left "@" id-right ">"

   NOTE: id-left and id-right are specified in [RFC5322].

Note that SIP header fields generally do not allow trailing
whitespace.

3.3.  Semantic

I think you want "Semantics" as the section title.

I notice this item in the list (which is duplicated in section 1.5):

   o  a Content-ID header field, if included in the header fields of the
      SIP message;

This reads awkwardly, because the beginning of the paragraph has
specified that there is a Content-ID header field in the message.  I
think this could be clarified by promoting this item to the top of the
list and explicitly labeling it all as metadata:

   The Content-ID header field included in header fields of a SIP
   message identifies a body part consisting of the message-body of
   the SIP message and the following metadata:

   o  the Content-ID header field itself;

and then continuing with "a MIME-Version header field", etc.

Dale

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 20 Apr 2017 12:34:49 +0000

Hello,

first of all, thank you for the review.

> The short title is "Content-ID-in-SIP", whereas it seems more natural to use

> "Content-ID in SIP".

Applied as suggested.

> This seems an awkward way of phrasing it.  In particular, there seems to be

> no reason to emphasize uniqueness here.  Perhaps

>      1.2.  Referencing the Content-ID value identifying the body

I agree it is awkward.

I made it even shorter to:

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

     1.1.  Identifying a body part . . . . . . . . . . . . . . . . .   2

     1.2.  Referencing a body part . . . . . . . . . . . . . . . . .   3

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

> These items capitalize later words, whereas the other items capitalize only

> initial words.  It seems that the current RFC style heavily favors

> capitalizing all the "important" words in section titles.

I guess RFC editor will anyway decide whether to capitalize all words of section titles or just the first one. I have slight preference for the latter style. No strong view.

> Strictly speaking, a SIP message containing several body parts also has a

> body (whose MIME type is multipart/something).  I think it would be better to

> phrase this

> I think this can be carried through to other places that use the phrase "one

> body".  (Although "one body" is a close version of the phrase "unitary body",

> which would be a good term for "non-multipart body", though nobody uses the phrase!)

OK to refer to "multipart body" and "non-multipart body".

However:

1) in some places, this forces split of the sentence to two sentences.

2) in other places, I rather talk about "content" where the "content" can be carried in (a) a body part of multipart body, or (b) in non-multipart body.

> Section 1.5 looks much like section 3.3, and I think the duplication should

> be reduced.  Perhaps the text in 1.5 could be reduced to

>    fields also applies to the message body as a whole.

OK to simplify.

I made it even shorter to:

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

   The Content-ID header field included in the header fields of a SIP

   message identifies a body part consisting of the message-body of a

   SIP message and metadata provided by some additional SIP header

   fields.

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

> But this allows RFC 5322's FWS, which is slightly broader than RFC 3261's

> SWS.  Probably best is to force the whitespace to be in the style of RFC 3261:

> Note that SIP header fields generally do not allow trailing whitespace.

Applied as suggested.

> This reads awkwardly, because the beginning of the paragraph has specified

> that there is a Content-ID header field in the message.  I think this could

> be clarified by promoting this item to the top of the list and explicitly

> labeling it all as metadata:

> and then continuing with "a MIME-Version header field", etc.

Good idea.

Minor tweak - I would prefer to state:

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

   The Content-ID header field included in the header fields of a SIP

   message identifies a body part consisting of the message-body of the

   SIP message, and >>the metadata provided by<<:

   o  a MIME-Version header field, if included in the header fields of

      the SIP message;

....

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

Kind regards

Ivo

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Apr 2017 12:47:05 +0000

Hi,

Pull request based on Ivo’s reply:

https://github.com/cdh4u/draft-content-id/pull/3

Regards,

Christer

From: sipcore <[email-masked]<mailto:[email-masked]>> on behalf of Ivo Sedlacek <[email-masked]<mailto:[email-masked]>>
Date: Thursday 20 April 2017 at 15:34
To: Dale Worley <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-content-id-01

Hello,

Applied as suggested.

I agree it is awkward.

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

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

However:

OK to simplify.

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

   fields.

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

Applied as suggested.

Good idea.

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

      the SIP message;

....

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

Kind regards

Ivo

---

From: Randall Gellens <[email-masked]>
Date: Thu, 20 Apr 2017 10:39:37 -0700

(1) Section 1.1 seems overly complex:
    However, when the message-body of the SIP message contains one body
    only, there is no body part specified.  Thus, there is also no
    defined method how to convey an ID value uniquely identifying the
    body part.

Perhaps:
    However, when the message-body of the SIP message is not a multipart,
    there is no way to convey an ID value identifying the body part.

(2) Section 1.3 seems overly complex:
    Since the Content-ID header field is not a defined SIP header field:

    o  If solely one body needs to be transported in a SIP message and
       the UAC does not need to include in the SIP message a SIP header
       field referencing the body part, then the UAC sets the message-
       body to the body.
    o  However, if solely one body needs to be transported in a SIP
       message and the UAC needs to include in the SIP message a SIP
       header field referencing the body part, then the UAC sets the
       message-body to be of the "multipart" MIME type and includes one
       body part and associated Content-ID header field.

Perhaps:
    Since the Content-ID header field is not a defined SIP header field,
    it is not possible to reference a unitary or the top-level body part.
     In cases where only a single part part is included and needs to be
    referenced, it must be wrapped in an otherwise unnecessary
    multipart/mixed.

(3) Section 1.4.1 seems overly complex:
    the UAC needs to include a message-body of "multipart/mixed" MIME
    type in the INVITE request, and the UAC needs to include a body part
    of the application/pidf+xml MIME type and associated Content-ID
    header field in the message-body of the "multipart/mixed" MIME type.

Perhaps:
    the UAC needs to wrap the application/pidf+xml body part in a
    multipart/mixed MIME media type, in order to be able to have a
    Content-ID header field referencing the application/pidf+xml.

(4) Section 1.4.2 seems overly complex:
    UAC needs to include a message-body of the "multipart/mixed" MIME
    type in the REFER request and the UAC needs to include a body part of
    the application/resource-lists+xml MIME type and associated Content-
    ID header field in the message-body of the "multipart/mixed" MIME
    type.

Perhaps:
    the UAC needs to wrap the application/resource-lists+xml body part in
    a    multipart/mixed MIME media type, in order to be able to have a
    Refer-To header field referencing the application/resource-lists+xml
    body part.

(5) Suggested text changes in Section 1.5:

OLD:
    To avoid the unnecessary usage of a message-body of a "multipart"
    MIME type when only one body needs to be included in a SIP message,
    this document specifies a Content-ID header field as a SIP header
    field.

    SIP message and:

NEW:
    To avoid the need to unnecessary wrap a message body in a multipart MIME
    type, this document specifies the Content-ID header field as a SIP header
    field.

    A Content-ID header field included in the header fields of a SIP message
    identifies a body part consisting of the message-body of the SIP 
message and:

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ask a question and you're a fool for three minutes; do not
ask a question and you're a fool for the rest of your life.
                                         --Chinese proverb

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Apr 2017 14:11:15 -0400

Ivo Sedlacek <[email-masked]> writes:
> 2) in other places, I rather talk about "content" where the "content"
> can be carried in (a) a body part of multipart body, or (b) in
> non-multipart body.

Well...  What exactly do you want the term to mean?  I mean, there are
three things I can name off the top of my head:

- the body of the SIP message
- a body part which is not itself a multipart
- a body part which is part of a multipart

Given that parts of multiparts can themselves be multiparts, there are
body parts that are examples for most of the eight possible true/false
combinations of these properties.

As far as I know, there's no (interesting) statement one can make which
requires an "A or B" description of its subject -- as long as you
carefully think through what it is that you mean, and choose a phrase
that accurately describes it.

In your example, I suspect that you use "content" to mean "a body part
which is not itself a multipart" (since the whole body is itself a body
part).

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Apr 2017 16:04:02 -0400

I still think it is simpler to think of the entire sip message, with the 
exception of the Request-Line and Status-Line, as a mime message, with 
all the uniquely sip message-headers simply being mime extension 
headers. Then all these nomenclature issues go away.

	Thanks,
	Paul

On 4/20/17 2:11 PM, Dale R. Worley wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 21 Apr 2017 06:46:03 +0000

Hello,

> I still think it is simpler to think of the entire sip message, with the exception of the Request-Line and Status-Line, as a mime message, with all the uniquely sip message-headers simply being mime extension headers. Then all these nomenclature issues go away.

I commented on this proposal already - see response to Comment-3 in the attached mail.

Kind regards

Ivo Sedlacek

Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt
From: Ivo Sedlacek <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 1 Mar 2017 08:21:32 +0000
List-Id: SIP Core Working Group <sipcore.ietf.org>

Hello,

I re-read the comments raised at the sipcore list to draft-ietf-sipcore-content-id-00 and identified:

Comment-1) Paul pointed that the draft can be read as the SIP Content-* header fields are mandatory.

                Response: I attempt to address the comment by added a clarification in -01 that the body part formed from a SIP message contains the SIP header fields, >>if included in header fields of the SIP message<<.

Comment-2) Randall indicated that RFC2045 uses "entity" rather than "body part".

                Response: RFC3261 and RFC5621 use body parts. RFC2398 uses "body part" and "MIME entity" interchangeably. Thus, I would rather stick to "body part".

Comment-3) Paul suggested to state that the body part is formed from *all* the SIP header fields (rather than just those identified in section 3.3.)

                Response:

                - Paul's suggestion would require that all SIP header fields are registered by IANA as MIME header fields.

                - We would need to do so to ensure that none can register e.g. a MIME "History-Info" header field with syntax or semantic deviating from the SIP "History-Info" header field.

                - IMO, this makes too much dependency between SIP and MIME and thus I would prefer to stick to explicitly identified SIP header fields which form the body part, as in section 3.3.

Furthermore, I identified that MIME-Version should be listed as a SIP header field which also forms the body part, and included it in section 3.3.

We have created a pull request with the changes: https://github.com/cdh4u/draft-content-id/pull/1  We intend to submit a new version of the draft before the Chicago cut-off, so please take a look.

Kind regards

Ivo

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Apr 2017 07:01:04 +0000

Hi,

I REALLY don¹t think we shall make this more complicated than it has to
be. Let¹s leave that for 3261bis...

The purpose of the work is to register Content-ID as a SIP header field.

Regards,

Christer

On 21/04/17 09:46, "sipcore on behalf of Ivo Sedlacek"
<[email-masked] on behalf of [email-masked]> wrote:

>Hello,
>
>> I still think it is simpler to think of the entire sip message, with
>>the exception of the Request-Line and Status-Line, as a mime message,
>>with all the uniquely sip message-headers simply being mime extension

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 21 Apr 2017 07:16:28 +0000

Hello,

> Well...  What exactly do you want the term to mean?  

By content, I intend to refer to a pieces of information. 
One example of the content is an XML text of application/pidf+xml MIME type.
Another example of the content is a JPEG picture.
Another example of the content is an unstructed text.

The content can be transported by SIP (using various methods, as indicated by you below), can be transported by other protocol (e.g. HTTP), or e.g. can be stored in a file in a computer.

> I mean, there are three 
> things I can name off the top of my head:

The above are several methods how to transport the content in SIP.

> Given that parts of multiparts can themselves be multiparts, there are body 
> parts that are examples for most of the eight possible true/false 
> requires an "A or B" description of its subject -- as long as you carefully 
> think through what it is that you mean, and choose a phrase that accurately 
> describes it.
> 
> In your example, I suspect that you use "content" to mean "a body part which 
> is not itself a multipart" (since the whole body is itself a body part).

No. 

The content is a piece of information.
The body part which is not itself a multipart is a method to transport the content.

Kind regards

Ivo

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 21 Apr 2017 07:42:30 +0000

Hello,

thank you for the review and let me respond to your comments.

>     there is no way to convey an ID value identifying the body part.

The original text identified two problems (Problem-1, Problem-2) while the text identifies only one (Problem-2).

Problem-1: RFC2045 defines a body part as follows. 
	----------------
	   The term "body part" refers to an entity inside of a multipart
	   entity.
	----------------
	Thus, today, by definition, message-body which is not multipart is not a body part. 

Problem-2: there is no way to refer from a SIP header field to a message-body which is not multipart.

Anyway, the text above has already been updated in the proposed new version of the draft shared yesterday. Does the updated version resolve the comment?

>     referenced, it must be wrapped in an otherwise unnecessary

RFC2045 defines body part as follows:
----------------
   The term "body part" refers to an entity inside of a multipart
   entity.
----------------

So, given the definition above, "a unitary or the top-level body part" cannot exist.

Again, the text above has already been updated in the proposed new version of the draft shared yesterday. Does the updated version resolve the comment?

>     Content-ID header field referencing the application/pidf+xml.

Is there a formal definition of wrapping a body part to a multipart/mixed MIME media type?

Based on Dale's suggestion, I updated the text to:
-------------
   the UAC needs to set the message-body of the
   INVITE request to a multipart body, and the UAC needs to include a
   body part with a content of the application/pidf+xml MIME type and
   with an associated Content-ID header field in the multipart body.
-------------

Does this resolve the comment?

>     Refer-To header field referencing the application/resource-lists+xml

Same as for (3) above.

>     identifies a body part consisting of the message-body of the SIP message and:

I simplified it even more based on Dale's comment to state:
---------------
1.5.  Solution

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

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Apr 2017 13:26:28 +0000

Hi,

I¹ve had a chat with Ivo, and we have updated the text in the pull request.

Most changes are in the Introduction, but some alignment changes have also
been done elsewhere. The idea was to only use terminology already defined
elsewhere.

Note that we have added a ³Update to RFC 2045 and RFC 5632² section, where
we still need to add some text, basically saying that the CID URL is can
also be used with message-bodies (currently the RFCs only talk about body
parts). We do NOT intend to make a OLD-TEXT-NEW-TEXT change, but simply
add a statement.

The XML changes, and TXT file based on the latest changes, can be seen
here:

https://github.com/cdh4u/draft-content-id/pull/3/files

Regards

Christer

On 21/04/17 10:16, "sipcore on behalf of Ivo Sedlacek"
<[email-masked] on behalf of [email-masked]> wrote:

>The content can be transported by SIP (using various methods, as
>indicated by you below), can be transported by other protocol (e.g.
>HTTP), or e.g. can be stored in a file in a computer.
>
>> I mean, there are three
>>body 
>>carefully 
>>which

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 21 Apr 2017 14:32:23 -0400

Ivo Sedlacek <[email-masked]> writes:
> > Comment-3) Paul suggested to state that the body part is formed from
> *all* the SIP header fields (rather than just those identified in
> section 3.3.)
>
> Response:
...
> - We would need to do so to ensure that none can register e.g. a MIME
> "History-Info" header field with syntax or semantic deviating from the
> SIP "History-Info" header field.

That's an interesting point, because we *do* need to ensure that nothing
is registered as a "MIME header" that already exists as either an e-mail
header, an HTTP header, or a SIP header.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Apr 2017 12:34:02 +0000

Hi,

I have updated the pull request, and there is now an update to RFC 5621.

I intend to submit a new version soon, so please take a look.

Regards,

Christer

On 21/04/17 16:26, "sipcore on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>