RE: [Sip] Support for Multipart/MIME

[Ted Hardie <[e-mail]>]

At 2:40 PM -0500 5/9/07, James M. Polk wrote:
>It's possible/probable/obvious (depending on who you talk to) that multipart will have to be supported for emergency calling, in which there is an SDP body and a Location message body...
>
>This doesn't mean UAs that *don't* establish voice/video dialogs will have to support multipart, just for those UAs that do establish voice/video dialogs with emergency response centers (again, depending on who you talk to).

That won't be multipart/alternative, though, as the location body and the SDP body
won't be alternatives but independent items.   I think they would be
multipart/mixed.  See this from RFC 2046:

5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".

5.1.4.  Alternative Subtype

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

<snip>
				Ted




>At 02:15 PM 5/9/2007, 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".  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.
>>
>>-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



_______________________________________________
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