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