Subject: [Sip] Proposal for multiple INFO bodies in an INFO

From: Eric Burger <[email-masked]>
Date: Thu, 30 Oct 2008 14:29:22 -0400

Good thing I waited 10 days...

Initially, I was very swayed by the argument that things would be  
much, much easier if we restricted an INFO request to a single Info- 
Package.

However, and especially as the last person to touch RFC 4483, I can  
see the argument that *any* SIP message can end up with a multipart/ 
mime body, even if you think you can limit it to just your stuff,  
because the UA can always have a content indirection pointer in the  
header pointing to a mime body part.

Therefore, even if we restrict an INFO request to carry a single Info- 
Package, we need a mechanism to uniquely identify and, at the SIP  
header level, indicate which body part belongs to the package.

I would offer once we solve that, we also get multiple INFO request  
bodies for free.

I would also offer that since INFO does not change SIP state, which  
means there is not even a concept of a message succeeding but the INFO  
body doing something that "fails", the objection that it would be hard  
for a UA to report on one body "failing" with another body  
"succeeding" is a non-issue.  Yes, this does mean that you cannot use  
INFO to tunnel IP.  See RFC 3252 for more on this.  I do not see this  
as a problem.

Therefore, on to the solution.  We use the MIME approach.  The body  
parts get tagged with Content-IDs. The Info-Package has a parameter,  
CID, which points to the body part.  The ONLY question I have is  
whether we should simply mandate always having this parameter to make  
the protocol and parser easier, but a small burden on UAC's that  
really are only sending a single body.  Other than that, the mechanism  
looks like:

INFO .....
To: ....
From: ....
Info-Package: foo
Content-Type: application/foo;cid=this
Content-Id: this
...

<foo body>

Multipart mixed example with indirect content:

INFO ....
To: ....
From: ....
Info-Package: foo;cid=abcd1234zz
Mumble: <cid:abcd9999qq>
Content-Type: multipart/mixed;boundary="theboundary"
...

--theboundary
Content-Type: application/mumble
Content-Id: abcd9999qq
...

<mumble stuff>

--theboundary
Content-Type: application/foo
Content-Id: abcd1234zz

<foo body>

--theboundary--

Multiple Info Packages follow. Note that by using Content-Id, order is  
irrelevant.

INFO ....
To: ....
From: ....
Info-Package: foo;cid=abcd1234zz
Info-Package: bar;cid=wxyz9876
Content-Type: multipart/mixed;boundary="theboundary"
...

--theboundary
Content-Type: application/bar
Content-Id: wxyz9876
...

<bar stuff>

--theboundary
Content-Type: application/foo
Content-Id: abcd1234zz

<foo body>

--theboundary--

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Oct 2008 16:44:07 -0400

Of course I agree with all the stuff below on the necessity of dealing 
with multipart bodies.

While I was advocating a Content-Disposition mechanism for identifying 
the relevant part(s), I have no problem with the CID: mechanism. If we 
go that way I think we should *always* use the CID reference.

	Thanks,
	Paul

Eric Burger wrote:
> Initially, I was very swayed by the argument that things would be much, 
> much easier if we restricted an INFO request to a single Info-Package.
> 
> However, and especially as the last person to touch RFC 4483, I can see 
> the argument that *any* SIP message can end up with a multipart/mime 
> body, even if you think you can limit it to just your stuff, because the 
> UA can always have a content indirection pointer in the header pointing 
> to a mime body part.
> 
> Therefore, even if we restrict an INFO request to carry a single 
> Info-Package, we need a mechanism to uniquely identify and, at the SIP 
> for a UA to report on one body "failing" with another body "succeeding" 
> is a non-issue.  Yes, this does mean that you cannot use INFO to tunnel 
> IP.  See RFC 3252 for more on this.  I do not see this as a problem.
> 
> CID, which points to the body part.  The ONLY question I have is whether 
> we should simply mandate always having this parameter to make the 
> protocol and parser easier, but a small burden on UAC's that really are 
> only sending a single body.  Other than that, the mechanism looks like:
> 
> INFO .....
> To: ....
> From: ....
> Info-Package: foo
> ------------------------------------------------------------------------
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 30 Oct 2008 22:38:05 +0100

Hi Erick,
 
I am not your suggestion of using CID for Info packages is what has been discussed (I may be wrong, of course).
 
I think what Paul was proposing was to have a Content-Disposition value indicating that a particular body shall be treated as in info package.
 
INFO .....
To: ....
From: ....
Info-Package: foo
Content-Type: application/foo
Content-Dispotistion: info
...

<foo body>

INFO ....
To: ....
From: ....
Info-Package: foo

--theboundary
Content-Type: application/mumble
Content-Disposition: whatever

<mumble body>

--theboundary
Content-Type: application/foo
Content-Disposition: info

<foo body>

--theboundary--

Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Eric Burger
Sent: Thu 30/10/2008 19:29
To: IETF SIP List
Subject: [Sip] Proposal for multiple INFO bodies in an INFO

INFO .....
To: ....
From: ....
Info-Package: foo

<foo body>

INFO ....
To: ....
From: ....

--theboundary

<mumble stuff>

--theboundary

<foo body>

--theboundary--

INFO ....
To: ....
From: ....

--theboundary

<bar stuff>

--theboundary

<foo body>

--theboundary--

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Oct 2008 20:35:46 -0400

I am ok with either way.

I think using C-D follows the precedent of INVITE for finding "its body 
part" via C-D of "session".

	Thanks,
	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 30 Oct 2008 18:56:20 -0700

Eric Burger wrote:
...
> IP.  See RFC 3252 for more on this.  I do not see this as a problem.

Not sure I follow this. If an INFO carries bodies for info packages A 
and B and the one for A is fine but the one for B is malformed, then is 
the INFO rejected or not?

Thanks,
Anders

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 31 Oct 2008 14:05:02 +0100

Hi,

Erick says that once we are able to indicate which mime contains the
info package, we would be able to allow multiple info packages.

For, that would of course require that we either allow multiple
Info-Package headers, or that a single header can list multiple info
packages.

Regards,

Christer

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 31. lokakuuta 2008 2:36
> To: Christer Holmberg
> Cc: Eric Burger; IETF SIP List
> Subject: Re: [Sip] Proposal for multiple INFO bodies in an INFO
> 
> I am ok with either way.
> 
> I think using C-D follows the precedent of INVITE for finding 
> "its body part" via C-D of "session".
> 
> 	Thanks,
> 	Paul
> 
> Christer Holmberg wrote:
> > Hi Erick,
> >  
> > I am not your suggestion of using CID for Info packages is 
> what has been discussed (I may be wrong, of course).
> >  
> > I think what Paul was proposing was to have a 
> Content-Disposition value indicating that a particular body 
> shall be treated as in info package.
> >  
> > INFO .....
> > To: ....
> > From: ....
> > Info-Package: foo
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Oct 2008 09:35:46 -0400

Either way can allow multiple. The means for expressing it are somewhat 
different, but not of consequence.

	Thanks,
	Paul