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

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

Reply via email to