Re: Body Handling and Multiple body-parts in one INFO

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 [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