Re: [Sip] Multiple body-parts in one INFO

[Eric Burger]

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

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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