One approach is to bastardize Content-Disposition to mean Body-Part- Context, in the vein of Message-Context for e-mail (RFC 3458). Body- handling would specify generic SIP stacks to be aware that Content- Disposition is how you pair a body part with its intended use. Hope no one else wants Content-Disposition: render for anything else...
Another approach is to mandate Content-ID, and give guidance to writers of extensions that add body parts to explicitly state how to address the relevant body part.
So, one thing is clear: we really screwed up by trying to hack Message- Context into Content-Disposition. Mea Culpa for not noticing it sooner.
On Dec 1, 2008, at 7:04 PM, Dean Willis wrote:
Hadriel said:This "problem" already exists for current SIP messages, and it's up to the new extensions that add body-parts to solve it in a backward-compatible way for all message methods. We don't need to solve it specifically for INFO.Hadriel has a point here. We know that EVERY SIP usage where we end up with two or more attachments is going to have the attachment-selection problem, aka "which attachment goes with which extension?" This isn't just a problem for new work; it's potentially a problem for several old or ongoing bits of work that result in the potential for multiple attachments. Perhaps we should solve this universally in the body handling draft? -- Dean _______________________________________________ Sip mailing list https://www.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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.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
