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

Everyone seems to think there needs to be a generic way of identifying  
body bits.

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

_______________________________________________
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