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

[Eric Burger]

Content-Type doesn't work. See the draft itself or Message-Context RFC.

On Dec 1, 2008, at 2:52 PM, Christer Holmberg wrote:

Hi,

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

body part belongs to.

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

So, maybe we should use Content-Type, then?

Regards,

Christer

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