> > 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: > > Right. Mixed is a far cleaner semantic problem than alternative. It > means "Use all of these that you understand, to the best of your > ability, and complain if there's nothing you understand."
I agree that multipart/mixed makes sense when you're sending different content-types and you want the receiver to process each one that he understands. This is useful if you're doing an Invite that includes your location (application/sdp and application/pidf+xml [draft-ietf-sip-location-conveyance]). However, if you're sending SDP and SDPng, multipart/mixed does not make sense. If you're sending SDP and SDPng, you want the answerer to pick one. For the next decade, anyone that understands SDPng will also need to continue to understand SDP. And we don't want the receiver to creatively use both the SDP offer and the SDPng offer. Email is similar: if you configure Thunderbird or Outlook to send messages with text/plain and text/html they are put inside multipart/related, not multipart/mixed. -d _______________________________________________ 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
