Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Aug 2008 12:40:23 +0300

Hi Keith,

per our conversation, I guess we can just leave the text as it is right 
now. The thing is that nesting was already defined for email and we do 
not really want to change those definitions and recommendations. The 
only thing we are doing here is stressing that you should not just 
perform nesting for fun. You need a reason to do that.

Thanks,

Gonzalo

Paul Kyzivat wrote:
> 
> 
> DRAGE, Keith (Keith) wrote:
> 
>> I know we do have this paragraph in section 4.1:
>>
>>    Nested MIME bodies are yet another useful tool to build and combine
>>    SIP extensions.  Using the extensions in the previous examples, a UA
>>    that supported a new session description format and that needed to
>>    include a location object in an INVITE request would include a
>>    'multipart/mixed' body with two body parts: a location object and a
>>    'multipart/alternative'.  The 'multipart/alternative' body part
>>    would, in turn, have two body parts: a session description written in
>>    SDP and a session description written in the newer session
>>    description format.
>>
>> But thinking about this, I suspect we define no semantics anywhere 
>> (please correct me if I am wrong) about what nesting means. Does a 
>> nested body require different interpretation to a multipart body, and 
>> if so, how do I discover what that difference is. All the nesting 
>> would seem to tell me is that there might be a different relationship, 
>> but it does not tell me what that relationship is.
> 
> I agree that the current loose wording leaves something to be desired.
> I just don't know how to fix it.
> 
> Let me give a concrete example:
> 
> Is an INVITE valid if it contains a body of:
> 
>     multipart/mixed {
>        multipart/mixed {
>           multipart/mixed {
>              application/sdp
>     }}}
> 
> Must the UAS keep unwrapping multiparts, looking for its SDP?
> 
> And while we are discussing weird cases, what about:
> 
>     multipart/mixed {
>        multipart/mixed {
>           multipart/mixed {
>              application/sdp-1
>           }
>           application/sdp-2
>     }}
> 
> If the latter is legal at all, which sdp is the offer? And what should 
> happen to the other one?
> 
> I know these are bizarre cases. I'm just pushing the envelope to 
> understand the implications for the sorts of decoding logic the stack 
> should be expected to use.
> 
>     Thanks,
>     Paul
>     

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Aug 2008 12:50:28 +0300

Hi Keith,

sure, I can add a sentence per your suggestion below.

Thanks,

Gonzalo

DRAGE, Keith (Keith) wrote:
> My personal preference would be to add a disclaimer sentence to indicate that such semantics are not defined in any SIP RFC (so far), so any interpretation of the relationship between multiple parts when they are nested or otherwise is solely dependent on the interpretation of the MIME values, and that the examples imply no specific definition of semantics for SIP. 
> 
> As this is an interpretation, different vendors may have different interpretations.
> 
> I could live without this, but something conveying this sense would be better.
> 
> Keith
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[email-masked]] 
>> Sent: Friday, August 01, 2008 10:40 AM
>> To: Paul Kyzivat
>> Cc: DRAGE, Keith (Keith); SIP IETF
>> Subject: Re: [Sip] Comments on draft-ietf-sip-body-handling-02
>>
>> Hi Keith,
>>
>> per our conversation, I guess we can just leave the text as 
>> it is right now. The thing is that nesting was already 
>> defined for email and we do not really want to change those 
>> definitions and recommendations. The only thing we are doing 
>> here is stressing that you should not just perform nesting 
>> for fun. You need a reason to do that.
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> Paul Kyzivat wrote:
>>>
>>>> would seem to tell me is that there might be a different 
>>>> relationship, but it does not tell me what that relationship is.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 1 Aug 2008 11:48:28 +0200

Keith