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

[Eric Burger]

Wrong because there is no explicit linking of a body part to what that body part belongs to.

On Dec 1, 2008, at 9:18 AM, Christer Holmberg wrote:

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)?

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

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