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 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip