Re: [Sip] Support for Multipart/MIME

[Paul Kyzivat <[e-mail]>]

Dan Wing wrote:
> The now-expired draft
> http://tools.ietf.org/html/draft-jennings-sipping-multipart-02 explored
> multipart/alternative.  One difficulty, however, is what does it mean to say
> "can understand a part".
> 
> This is easy if one part is SDP and another part is SDPng.  If you
> understand SDPng, you process it; if you don't, you process the SDP.
> 
> However, it's really hard if one part is SDP and another part is also SDP --
> in some cases we would like the answerer to "pick the better SDP". 

The creator of the multipart/alternative has the job of picking which is 
the better one. By definition they alternatives are ordered with the 
preferred one last. (There is an assumption the the the preferred one is 
the least widely implemented, and the least preferred one is the most 
widely implemented.) You are supposed to process the *last* one that you 
are *capable* of processing.

But your point still remains. If there are two SDP alternatives, how do 
you decide if you can implement the last one? You are allowed to ignore 
much of SDP if you don't understand it. But is that supporting it?

> At the
> time, we were considering multipart/alternative as a way to offer RTP
> (RTP/AVP) and SRTP (RTP/SAVP), but we found it doesn't work well at all.
> Since then, draft-ietf-mmusic-sdp-capability-negotiation is a superior
> solution to sending an offer containing RTP and SRTP.  
> 
> I suppose we could avoid the difficulty by prohibiting identical
> Content-Types in the alternatives.

Or just clearly define what it means to support one in an alternative.

	Paul

> -d
> 
> 
>> -----Original Message-----
>> From: Christer Holmberg (JO/LMF) 
>> [mailto:[e-mail]] 
>> Sent: Thursday, May 03, 2007 3:50 AM
>> To: [e-mail]; [e-mail]
>> Subject: RE: [Sip] Support for Multipart/MIME
>>
>>
>> Hi,
>>
>> Multipart/alternative is interesting. I guess that, for SDP, 
>> it could be
>> used to provide different "offer alternatives". I think it 
>> would be good
>> to compare it against some of the other grouping/alternative 
>> mechanisms
>> we have defined for that purpose.
>>
>> Regards,
>>
>> Christer
>>  
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] 
>>> Sent: 30. huhtikuuta 2007 19:13
>>> To: [e-mail]
>>> Subject: Re: [Sip] Support for Multipart/MIME
>>>
>>>    From: Cullen Jennings <[e-mail]>
>>>
>>>    I think the WG should consider an update to 3261 (likely 
>>> done through  
>>>    the process Keith has proposed) that makes this multipart/MIME  
>>>    mandatory to implement.
>>>
>>> I assume that the requirement is that if a message has a 
>>> multipart/alternative body, and the UA is capable of 
>>> understanding one part of the body, then it must be able to 
>>> extract that part and use it to process the message.
>>>
>>> Dale
>>>
>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol Use 
>>> [e-mail] for questions on current sip 
>>> Use [e-mail] for new developments on the application of sip
>>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 


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