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