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

[Christer Holmberg <[e-mail]>]

Hi,

…

>>>>>- Is there an expectation for the SIP Content-ID header field value
>>>>> to be referenced from outside the SIP message? If so, what are the
>>>>> uniqueness expectations? Note that for MIME, Content-ID is expected
>>>>>to 
>>>>> be globally unique. Is that the case here?
>>>> 
>>>> (Christer) The draft does not change the uniqueness requirements of
>>>> Content-ID.
>>>> 
>>>>> If the Content-ID is _not_ expected to be referenced from outside of
>>>>> the SIP message that contains it, then we have a sort of degenerate
>>>>> case where it always identifies _this_ message regardless of the
>>>>> value. Does that value ever need to change? Does that suggest >any
>>>>> guidance on how to construct values?
>>>> 
>>>> (Christer) RFC 5621 does not define the above characteristics for
>>>> multipart body usage, and I see no reason how anything would be
>>>> different for a non-multipart message body. If you think there is
>>>> something generic about Content-ID that needs to be clarified I think
>>>> that should be done as a separate task.
>>> 
>>> 5261 used the Content-Id MIME header field. That field and it¹s
>>> uniqueness requirements are defined elsewhere. This draft defines a
>>> Content-ID sip header field. That didn¹t exist before. Therefore I
>>> think this needs to describe the uniqueness requirements.
>>> 
>>> 5322 requires msg-id to be globally unique because it¹s intended to be
>>> useful outside the context of the given message. Is that the case here?
>>> If not, then a globally uniqueness requirement may not make sense in
>>> this context. (IIUC, every single instance of the Content-Id SIP
>>>header 
>>> field could have the same, identical value, and things would work
>>> fine.)
>> 
>> (Christer) I have never heard about Content-ID being used outside the
>>context of a given message, so I think the value only needs to be unique
>>within a given message
>
>Are you expecting to ever have both the SIP header field and one or more
>MIME Content-ID header fields in the same message?

I don’t have a use-case at the moment, but I don’t think we should
disallow it.


>If so, then text to the effect of the following seems to make sense:
>
>“The value of Content-Id header field value must be unique in the context
>of a given SIP message, including any imbedded MIME Content-Id header
>field values. Note that the SIP Content-ID header field value is not
>expected to be unique among all SIP messages; it has no meaning outside
>of the message in which it is included.”

Looks good.

s/imbedded/embedded

>
>If, OTOH, you think there might ever be a need to reference a body from a
>different SIP message, then we would need it to be globally unique.

IF someone ever comes up with such use-case, we can deal with it.


>> 
>> 
>> Specific comments:
>> 
>>>>> 1.4 and children: These examples seem like fairly weak motivation,
>>>>> since I assume in both cases one could still have just put a single
>>>>> body-part inside a multipart envelope. That
>>>>> seems more an "inconvenience" than a "problem". Are there any known
>>>>> use-cases where that would not be possible? (This is certainly not a
>>>>> show stopper; we are allowed to solve
>>>>> inconveniences. But if there are any stronger motivations that could
>>>>> be documented, they might save questions down the road.)
>>>> 
>>>> (Christer) I can't think of any use-cases where it would not be
>>>> possible to use a single-body inside a multipart envelope instead.
>>>>So, 
>>>> it is about "convenience".
>>> 
>>> The word "optimization" comes to mind.
>> 
>> (Christer) I guess that works too :)
>
>Okay, no change needed.
>
>> 
>>>>> 3.2, 2nd note: How has the msg-Id been simplified, and why?
>>>> 
>>>> (Christer) The simplification was done based on a comment from Dale W.
>>>> 
>>>> https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html
>>> 
>>> I think it would be helpful to say something like ³Š simplified to
>>> disallow the use of comments and to adapt to SIP¹s use of leading
>>>white 
>>> space."
>> 
>> (Christer) Ok, we¹ll add some text.
>
>Thanks. If you can submit a version with that change, as well as some
>guidance on uniqueness as discussed above, I think it will be ready for
>IETF LC.

I should have something ready no later than Monday.

Regards,

Christer