Re: Multiple body-parts in one INFO

Content-Type doesn't work. See the draft itself or Message-Context RFC.

On Dec 1, 2008, at 2:52 PM, Christer Holmberg wrote:

>
> Hi,
>
>> 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)?
>
> So, maybe we should use Content-Type, then?
>
> Regards,
>
> Christer
>
>
>
>
>> 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