Either way can allow multiple. The means for expressing it are somewhat
different, but not of consequence.
Thanks,
Paul
Christer Holmberg wrote:
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 PROTECTED]
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
Content-Type: application/foo
Content-Dispotistion: info
...
<foo body>
Multipart mixed example with indirect content:
INFO ....
To: ....
From: ....
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
...
--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 PROTECTED] 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
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 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
