Re: Multiple body-parts in one INFO

Hadriel Kaplan wrote:
>> -----Original Message-----
>> From: Christer Holmberg [mailto:[email protected]]
>> Sent: Sunday, November 30, 2008 4:58 PM
>>
>> 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.  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.

The problem is that none of them really considered the impact of 
multiple body parts, so it is anything but clear how an application is 
supposed to decipher one of these messages when it does contain multiple 
body parts. We are going to find that when combined with body parts for 
other purposes, implementations will do a variety of things. (That 
includes existing legal usages, such as body parts with C-D of "alert", 
which have been defined for a long time but never used.)

The body-handling draft tries to sort this out. But based on that we 
need to do better going forward than we did in the past.

Things were only "simple" in the past because we left things unspecified 
that needed to be specified.

You can have your "simple" solution here, analogous to the historic 
mechanism, by explicitly defining that body part(s?) with the 
content-disposition of "render" are to be considered to be the 
info-package payload. I say "render" because that is the *default* C-D, 
so it keeps things "simple" since it can be omitted. However you then 
should specify what happens if there are multiple body parts with C-D of 
"render". Also, you then need to specify whether a multipart body with a 
C-D of "render" should be viewed (in total) as the info-package payload, 
or whether some contained part of it should be the payload.

Personally, I would rather go with something less "simple" but more 
explicit here. Either a special C-D, or the CID reference.

	Thanks,
	Paul

> 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:
> 
> ----BEGIN----
> INFO sip:[email protected] SIP/2.0
> Call-ID: [email protected]
> From: <sip:[email protected]>;tag=27285
> To: <sip:[email protected]>;tag=GR52RWG346-34
> CSeq: 2 INFO
> Via: SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK-6110000000000893
> Max-Forwards: 70
> Info-Package: virtual-loc
> Geolocation: <cid:whereami@invalid>
> Content-Length: [whatever]
> Content-Type: multipart/mixed;boundary="boundary1"
> 
> --boundary1
> Content-Type: application/pidf+xml
> 
> [xml stuff goes here]
> --boundary1
> Content-Type: application/pidf+xml
> Content-Disposition: by-reference
> Content-ID: whereami@invalid
> 
> [xml stuff goes here]
> --boundary1--
> ----END----
> _______________________________________________
> 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