RE: [Sip] Support for Multipart/MIME

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[e-mail]] 
> Sent: Thursday, May 10, 2007 9:13 PM
> To: Dan Wing; Paul Kyzivat
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> > > Sent: Thursday, May 10, 2007 6:44 PM
> > > To: Paul Kyzivat; Dan Wing
> > > Cc: [e-mail]; [e-mail]
> > > 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip