> > 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. > > It seems that this issue is moot, since SDPng seems to have been > declared dead.
Yes, it seems that way. > > 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. > > Don't you mean multipart/alternative? Argh, yes. Thanks for catching that mistake. Anyway - someone needs to run with this multipart/mixed for sure, and probably also multipart/alternative and multipart/related (per Ted's suggestion, although I don't see a use case for multipart/ related at the moment). I no longer have the bandwidth to coauthor draft-jennings-sipping-multipart. -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
