Christer Holmberg (JO/LMF) wrote:
Hi Dan,
Couldn't you get this out of sync already today?
You get a SIP message with application/sdp, and then the message body
contains something else...
No you can't. If the sip message has Content-Type:application/sdp then
*by definition* the body contains sdp. If it doesn't look like sdp then
it is just syntactically incorrect sdp. The Content-Type in the message
is not redundant with one in the body - it is the one for the body.
Paul
Regards,
Christer
-----Original Message-----
From: Dan Wing [mailto:[EMAIL PROTECTED]
Sent: 11. toukokuuta 2007 8:35
To: Christer Holmberg (JO/LMF); 'Paul Kyzivat'
Cc: [EMAIL PROTECTED]; [email protected]
Subject: RE: [Sip] Support for Multipart/MIME
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 9:13 PM
To: Dan Wing; Paul Kyzivat
Cc: [EMAIL PROTECTED]; [email protected]
Subject: RE: [Sip] Support for Multipart/MIME
Hi,
* if they're out of sync, which one takes precedence (that
is, do I
process a Content-Type that isn't listed in the
Content-Type-List?)
The Content-Type contains "multipart/*", while the
Content-Type-List
contains the types (app/sdp, app/isup, app/whatever etc)
within that
multipart.
Please note that I am talking about SIP headers, not in the MIME
bodies (of course, if a MIME body contains another multipart/*, the
header could perhaps also be used there).
Let me clarify my point about that new Content-Type-List
header being out of sync with the body. Here is an example
-- a SIP header containing, among other things:
From: ...
To: ...
Content-Type-List: application/sdp
Content-Type: multipart/mixed; boundary=B
and the body contains:
--B
Content-Type: application/sdp
Content-Disposition: session
v=0
...
--B
Content-Type: application/pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
...
--B--
In such a situation, a device which supports
Content-Type-List in an effort to optimize its MIME parsing,
wouldn't know there is a "Content-Type:
application/pidf+xml" in the body.
* if a UA knew an intermediate box used Content-Type-List, the UA
could use Content-Type-List to make the intermediate box
think some
sort of Content-Type is not present. That additional content-type
might contain the secret of the universe, which the
intermediate box
really needed to know.
Well, this depends on the functionality of the middle-box.
If the middle-box is going to do some kind of policing, or
otherwise
verify that the multipart actually contains what is claimed in the
Content-Type-List, it will have to parse the multipart anyway.
Right.
Proxies are supposed to ignore the body, so what sort of
devices which aren't enforcing policy might benefit from the
Content-Type-List optimization?
* looking for "^Content-Type *:" isn't too hard; you don't really
need to bother parsing MIME and looking for nested parts
unless there
is, in fact, a content-type you care about. Per Paul's
message, if
you only want ones with
Content-Disposition: session, you could look for that
string within
4-5 lines of Content-Type; if you found it, then you could
parse the
MIME in the body.
I don't think it's that easy. Assume one MIME body contains a SIP
message (or part of a SIP message), or any other protocol
which uses
the Content-Type header, which is not the Content-Type
header of the
MIME body itself. The same goes for Content-Disposition.
Yes, there can of course be false-positives; the same sort of
false positives would occur with Content-Type-List: it could
list a content-type which is inside of a MIME part you
wouldn't otherwise process (due to the wrong
Content-Disposition, for example).
-d
Regards,
Christer
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 6:44 PM
To: Paul Kyzivat; Dan Wing
Cc: [EMAIL PROTECTED]; [email protected]
Subject: RE: [Sip] Support for Multipart/MIME
Hi,
The following is not a proposal, but more "brain storming".
Would it be helpful to have a SIP header, e.g.
Content-Type-List, which
would list the different Content-Types in a multipart/* body.
A node could then first check that header in order to see
whether the
multipart/* contains something a specific node is
interested in -
without having to parse the full multipart/* body
first. It could
speed up the processing in nodes which may have interest
only in a
small set of Content-Types.
Comments?
Regards,
Christer
_______________________________________________
Sip mailing list https://www1.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
