Re: Multiple body-parts in one INFO

Wrong because there is no explicit linking of a body part to what that  
body part belongs to.

Content-Disposition is absolutely the wrong thing.  The original  
Content-Disposition is about whether you wait for the whole message to  
arrive before rendering, and if you render the part where you find it  
or as an attachment.  SIP has bent this totally out of shape beyond  
recognition, almost to the point where it really is Message-Context.

Perhaps that is the answer?  Do-as-I-say (Message-Context), not Do-as- 
I-mean (Content-Disposition)?

On Dec 1, 2008, at 9:18 AM, Christer Holmberg wrote:

>
> Wrong where/what/how?
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Eric Burger
>> Sent: 1. joulukuuta 2008 16:13
>> To: Hadriel Kaplan
>> Cc: SIP List
>> Subject: Re: [Sip] Multiple body-parts in one INFO
>>
>> Just because everyone else got it wrong does not mean we have
>> to be wrong, too...
>>
>> On Dec 1, 2008, at 6:14 AM, Christer Holmberg wrote:
>>
>>>
>>> Hi,
>>>
>>>>> Sounds ok.
>>>>> But, doesn't the Info-Package header syntax still have to
>> allow the
>>>>> piggy-backer to:
>>>>> 1) List multiple info packages
>>>>> 2) For each listed info package, provide the cid
>>>>
>>>> Nope.  We've already said we're going to not bother doing multiple
>>>> packages. (or at least I think people have agreed with
>> that, I hope)
>>>>
>>>> So the next question was on multiple body-parts.
>>>
>>> I still want to see why we, if we are going to allow multiple body
>>> parts, can't allow multiple info packages, but let's leave
>> that for a
>>> moment...
>>>
>>>> Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY, MESSAGE, and legacy
>>> INFO, can all carry bodies and not one of
>>>> them defined a CID mechanism for the body part that was specific to
>>> their message method context, we shouldn't need
>>>> to for INFO either.
>>>
>>> Yes. And, if we are going to use CID, it means yet another RFC to
>>> support.
>>>
>>> What's wrong with using Content-Disposition?
>>>
>>>> A "piggy-backer" is an extension to SIP that piggy-backs
>> bodies onto
>>>> any message method types.  Geolocation is an example of
>> one.  Since
>>>> it's the responsibility of the piggy-backer to handle
>> identifying its
>>>> specific body-part and dis-ambiguating it from the
>> method's, we don't
>>>> have to do anything.  In other words, Geolocation would
>> already have
>>>> to deal with current INFO message and body syntax.
>>>>
>>>> For example, let's suppose someone creates an INFO package for
>>>> sending virtual location information in a game, using a
>> content-type
>>>> of application/pidf+xml.  (whether they should have done it in SIP
>>>> vs. the media layer is orthogonal)  And let's suppose for whatever
>>>> reason the SIP stack always adds Geolocation information
>> of the UA's
>>>> physical location.
>>>> Here is what it would look like:
>>>
>>> But, what if the information the piggy-backer wants to send
>> also uses
>>> info packages?
>>>
>>> Regards,
>>>
>>> Christer
>>> _______________________________________________
>>> 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