I do not see an obvious, generic way of doing this.
Thus for those out there who think there is a generic way of identifying body parts for SIP, please write text.
On Dec 2, 2008, at 4:02 AM, Gonzalo Camarillo wrote:
Hi Eric,if you think the body handling draft needs to give guidance on this, could you be more specific as to what exact guidance you want to be given (i.e., send text if you think the draft should say something about this ;o) )?Thanks, Gonzalo Eric Burger wrote:That was my knee-jerk reaction, until I realized that EVERY method needs to address the issue. All body-handling can do is give guidance. 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 forseveral 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------------------------------------------------------------------------ _______________________________________________ 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
