Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 May 2017 11:58:59 +0000

Hi Ben,

I have created a pull request, based on your comments:

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

However, I wasn¹t sure how to address the following comment:

"1.2 and 1.3: A sentence or two that more strongly contrasts "body part"
vs "message-body" would be helpful. I think that some people will think of
a message-body as still a body-part.²

I think section 1.1 describes the difference between a message-body and a
body-part. I don¹t think we should copy/paste that in sections 1.2 and
1.3. Or, did I misunderstand you comment?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 May 2017 11:27:59 -0500

> On May 26, 2017, at 6:58 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

The diff looks fine. We probably want to make sure the WG shares the opinion that the Content-ID will never be referenced from outside the SIP message.

Jean, do  you have thoughts on that from the shepherd perspective?

> However, I wasnąt sure how to address the following comment:
> 
> a message-body as still a body-part.˛
> 
> body-part. I donąt think we should copy/paste that in sections 1.2 and

On reflection, I think this might be fine like it is. I know that some people casually refer to the entire body as still a “part”, but that doesn’t seem to be reflected in the MIME RFCs. Let’s see if anyone comments in LC.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 May 2017 17:53:39 +0000

Hi,

...

>> However, I wasn't sure how to address the following comment:
>> 
>> vs "message-body" would be helpful. I think that some people will 
>> think of a message-body as still a body-part.˛
>> 
>> I think section 1.1 describes the difference between a message-body 
>> and a body-part. I donąt think we should copy/paste that in sections 
>> 1.2 and 1.3. Or, did I misunderstand you comment?
>
> On reflection, I think this might be fine like it is. I know that some people casually refer to the entire body as still a “part”, but 
> that doesn’t seem to be reflected in the MIME RFCs. Let’s see if anyone comments in LC.

Ok.

I'll wait for Jean's comment regarding usage-of-Content-ID-outside-the-SIP-message before submitting a new version.

Regards,

Christer

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 26 May 2017 14:28:31 -0500

Hi Ben,

On 5/26/17 11:27 AM, Ben Campbell wrote:
> The diff looks fine. We probably want to make sure the WG shares the
> opinion that the Content-ID will never be referenced from outside the
> SIP message.
> 

The WG did discuss whether the Content-ID could be used outside of the 
message. The takeaway was, that since a SIP header has non-MIME fields, 
the Content-ID can't really refer to the entire message, and thus would 
not be useful outside the message.

Anyone have any input on the changes to the draft?

Jean

PS - nit: Campbell is misspelled in the "Change Log".

>> "1.2 and 1.3: A sentence or two that more strongly contrasts "body
>> part" vs "message-body" would be helpful. I think that some people
>> will think of a message-body as still a body-part.˛
>> 
>> and a body-part. I donąt think we should copy/paste that in
>> sections 1.2 and 1.3. Or, did I misunderstand you comment?
> 
> On reflection, I think this might be fine like it is. I know that
> some people casually refer to the entire body as still a “part”, but

---

From: Ben Campbell <[email-masked]>
Date: Fri, 26 May 2017 20:36:36 -0500

> On May 26, 2017, at 2:28 PM, A. Jean Mahoney <[email-masked]> wrote:
> 
> Hi Ben,
> 
> The WG did discuss whether the Content-ID could be used outside of the message. The takeaway was, that since a SIP header has non-MIME fields, the Content-ID can't really refer to the entire message, and thus would not be useful outside the message.
> 

There seems to be two ideas intertwined there; namely the idea of what a content-ID identifies, and the idea of whether a content-ID could be referred to from outside the containing SIP message. But I take your comment to mean that both were discussed. Is that correct?

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 28 May 2017 18:40:38 +0000

Hi,

>> The WG did discuss whether the Content-ID could be used outside of the message. 
>> The takeaway was, that since a SIP header has non-MIME fields, the Content-ID can't 
>> really refer to the entire message, and thus would not be useful outside the message.
> 
> There seems to be two ideas intertwined there; namely the idea of what a content-ID identifies, 
> and the idea of whether a content-ID could be referred to from outside the containing SIP message. 
> But I take your comment to mean that both were discussed. Is that correct?

As far as I remember, we did not discuss the possibility of referencing a body outside the SIP message.

However, nobody has requested for that possibility, so I don't think we need to cover it. If someone, as some point, see a need for it, he/she can update the spec and define how it is done, what impacts it has on the uniqueness etc.

Regards,

Christer

>>> will think of a message-body as still a body-part.˛ I think section 
>>> 1.1 describes the difference between a message-body and a body-part. 
>>> I donąt think we should copy/paste that in sections 1.2 and 1.3. Or, 
>>> did I misunderstand you comment?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 May 2017 15:02:49 -0500

> On May 28, 2017, at 1:40 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

It’s kind of hard to define extra-message references later if the initial version does not require global uniqueness. If people want to leave that option open, then global uniqueness may still make sense now. I’m okay with it either way as long as the WG has thought it through, and hasn’t just picked it arbitrarily.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 May 2017 16:21:31 -0400

> It’s kind of hard to define extra-message references later if the initial version does not require global uniqueness. If people want to leave that option open, then global uniqueness may still make…

I'm struggling to conceive of what extra-message references would 
*mean*. Under what circumstances would that make sense? I guess one 
might make some sort of case for reference to body parts from other 
messages in the same dialog. But doing that would require that the state 
to be referenced be retained - hence expanding the dialog state model.

It would also then raise a whole host of new issues regarding how those 
references might/might not work through B2BUAs.

Imagining some meaning beyond a dialog is even more fanciful. It would 
require an even more expansive expansion of state models.

I don't think we should go there.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 May 2017 21:41:56 +0000

Hi,

I really think that mandating global uniqueness, for a possible use-case that nobody is still aware of, is overkill.

IF such use-case comes up, someone can always update the spec in order to mandate a globally unique value for such use-case. Alternatively, the value can be used together with some other value(s) (Call-ID, transaction-id, CSeq etc etc etc) in order to create a unique reference.

Regards,

Christer 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 31 May 2017 22:03
To: Christer Holmberg <[email-masked]>
Cc: A. Jean Mahoney <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST

>>>> The diff looks fine. We probably want to make sure the WG shares 
>>>> the opinion that the Content-ID will never be referenced from 
>>>> outside the SIP message.
>>> The takeaway was, that since a SIP header has non-MIME fields, the 
>>> Content-ID can't really refer to the entire message, and thus would not be useful outside the message.
>> 
>> There seems to be two ideas intertwined there; namely the idea of 
>> what a content-ID identifies, and the idea of whether a content-ID could be referred to from outside the containing SIP message.

>>>> I donąt think we should copy/paste that in sections 1.2 and 1.3. 
>>>> Or, did I misunderstand you comment?