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:[EMAIL PROTECTED]
>>> Sent: Thursday, May 03, 2007 3:50 AM
>>> To: [EMAIL PROTECTED]; [email protected]
>>> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> > Sent: 30. huhtikuuta 2007 19:13
>>> > To: [email protected]
>>> > Subject: Re: [Sip] Support for Multipart/MIME
>>> >
>>> > From: Cullen Jennings <[EMAIL PROTECTED]>
>>> >
>>> > 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
>>> > [EMAIL PROTECTED] for questions on current sip
>>> > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
>>> Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
>>Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
>Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
