Re: Multiple body-parts in one INFO

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