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:
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
