RE: [Sip] Support for Multipart/MIME - order of bodies

["Francois Audet" <[e-mail]>]

Personally, I think we should treat parallel just like mixed when
received.
And continue to use mixed for sending, at least for things that exist
already (like QSIG/ISUP).

I would be surprised if parallel was really used in the wild...

But I do agree we could say something about it. 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[e-mail]] 
> Sent: Monday, May 28, 2007 00:58
> To: Dan Wing; Audet, Francois (SC100:3055); Gonzalo Camarillo (JO/LMF)
> Cc: Paul Kyzivat; [e-mail]
> Subject: RE: [Sip] Support for Multipart/MIME - order of bodies
> 
> 
> Hi,
> 
> One question is when "parallel" should be used instead of "mixed".
> 
> When mixed is used, the order of the bodies is significant, 
> which is not the case for parallel. And, for ISUP or QSIG, is 
> there a difference in which order the ISUP/QSIG and SDP 
> bodies are presented?
> 
> I know that support of ISUP/QSIG bodies are implemented using 
> mixed, and I am not proposing to change that. But, I think 
> the draft should maybe talk a little more about the 
> differences between parallel and mixed.
> 
> In most cases I guess it doesn't matter which one would use. 
> At least I can't think of any SIP use-case where the order of 
> the bodies would be significant.
> 
> Regards,
> 
> Christer
> 
>  
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: 23. toukokuuta 2007 22:53
> > To: 'Francois Audet'; Gonzalo Camarillo (JO/LMF)
> > Cc: 'Paul Kyzivat'; [e-mail]; Christer Holmberg (JO/LMF)
> > Subject: RE: [Sip] Support for Multipart/MIME
> > 
> > Yes, I expect RFC3204's syntax and semantics work fine between two 
> > implementations that implement RFC3204.
> > 
> > My question if it the choice of multipart/mixed in RFC3204 
> was correct 
> > or if multipart/related would have been more appropriate 
> for RFC3204.  
> > I have this question because the QSIG (and ISUP) are 
> directly related 
> > to the SDP, and the QSIG/ISUP data provides additional information 
> > about that outgoing PSTN call leg that assists it in being set up.
> > 
> > My underlying question is what guidance we want to provide for 
> > Gonzalo's document.  If RFC3204's use of multipart/mixed is what we 
> > want to do in SIP when there are bodyparts that have a relationship 
> > with each other, then Gonzalo's document will need to 
> discourage use 
> > of multipart/related.
> > 
> > -d
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[e-mail]]
> > > Sent: Wednesday, May 23, 2007 12:22 PM
> > > To: Dan Wing; Gonzalo Camarillo
> > > Cc: Paul Kyzivat; [e-mail]; Christer Holmberg (JO/LMF)
> > > Subject: RE: [Sip] Support for Multipart/MIME
> > > 
> > > 
> > > Hi Dan,
> > > 
> > > To answer your question about the Multipart usage for ISUP/QSIG 
> > > tunnelling.
> > > 
> > > No, it does not set-up two calls. It sets-up ONE call.
> > > 
> > > The SDP is mandatory.
> > > 
> > > The QSIG or ISUP is optional. If supported it provides additional 
> > > information for the softswitches for legacy PSTN interop or other 
> > > features.
> > > If not it should be safely ignored.
> > > 
> > > So 3204 operates exactly as it should. Works fine. Has 
> been working 
> > > fine for years (except for implementations that have 
> problems with 
> > > Multipart MIME, which has forced the use of B2BUA that
> > strip off these
> > > MIME bodies.)
> > > 
> > > > > -----Original Message-----
> > > > > From: Francois Audet [mailto:[e-mail]]
> > > > > Sent: Wednesday, May 23, 2007 11:18 AM
> > > > > To: Gonzalo Camarillo
> > > > > Cc: Paul Kyzivat; [e-mail]; Dan Wing; Christer
> > > Holmberg (JO/LMF)
> > > > > Subject: RE: [Sip] Support for Multipart/MIME
> > > > > 
> > > > > This is great Gonzallo. Thanks for doing this.
> > > > > 
> > > > > Here are some comments:
> > > > > 
> > > > > - In section 4, another example that I think you should
> > list for
> > > > >   Multipart/Mixed is RFC 3204 which actually has examples of 
> > > > >   INVITEs with Multipart/Mixed (one for SDP, the other for 
> > > > >   QSIG/ISUP tunnelling). That spec also illustrates 
> the content-
> > > > >   disposition mechanism (i.e., "optional" for QSIG/ISUP).
> > > > 
> > > > I wasn't aware of that usage in RFC3204.  In both 
> section 4.1 and 
> > > > its example, though, I don't think it's using multipart/mixed 
> > > > correctly.  Here is its example (section 4.1 is similar):
> > > > 
> > > >    To illustrate the use of the 'application/QSIG' media
> > type, below
> > > > is
> > > >    an INVITE message which has the originating SDP
> > > information and an
> > > >    encapsulated QSIG SETUP message.
> > > > 
> > > >    Note that the two payloads are demarcated by the
> > > boundary parameter
> > > >    (specified in RFC 2046 [4]) which in the example has 
> the value
> > > >    "unique- boundary-1". This is part of the 
> specification of MIME
> > > >    multipart and is not related to the 'application/QSIG' 
> > > media type.
> > > > 
> > > >          INVITE sip:[e-mail] SIP/2.0
> > > >          Via: SIP/2.0/UDP sc10.nortelnetworks.com
> > > >          From: sip:[e-mail]
> > > >          To: sip:[e-mail]
> > > >          Call-ID: [e-mail]
> > > >          CSeq: 1234 INVITE
> > > >          Contact: <sip:[e-mail]>
> > > >          Content-Length: 358
> > > >          Content-Type: multipart/mixed; 
> boundary=unique-boundary-1
> > > >          MIME-Version: 1.0
> > > > 
> > > >          --unique-boundary-1
> > > >          Content-Type: application/SDP; charset=ISO-10646
> > > > 
> > > >          v=0
> > > >          o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4
> > > >          s=SDP seminar
> > > >          c=IN IP4 MG141.nortelnetworks.com
> > > >          t= 2873397496 2873404696
> > > >          m=audio 9092 RTP/AVP 0 3 4
> > > > 
> > > >          --unique-boundary-1
> > > >          Content-type:application/QSIG; version=iso
> > > > 
> > > >          08 02 55 55 05 04 02 90 90 18 03 a1 83 01
> > > >          70 0a 89 31 34 30 38 34 39 35 35 30 37 32
> > > >          --unique-boundary-1--
> > > > 
> > > > Per the semantics of multipart/mixed, both of those bodies are 
> > > > interpreted by the recipient -- wouldn't that cause two
> > calls to be
> > > > set up?  Or does the SDP describe the VoIP leg and the QSIG 
> > > > describes the PSTN leg?  If the latter, I do feel
> > multipart/related
> > > > would have been a better choice.
> > > > 
> > > > [[As MIME parsers are supposed to interpret unrecognized
> > > > multipart/* as multipart/mixed, a MIME-compliant parser that 
> > > > currently has the RFC3204-described behavior
> > <quote>should</quote>
> > > > work correctly if it received a multipart/related instead of 
> > > > multipart/mixed.]]
> > > > 
> > > > > - I like your text on Multipart/Alternative.
> > > > 
> > > > Yes, that section is very well written and captures exactly the 
> > > > problem with multipart/alternative.
> > > > 
> > > > ...
> > > > > - I believe that the following text in section 4 is not
> > > > strong enough:
> > > > > 
> > > > >    If a UAS does not support multipart bodies and
> > > receives one, the
> > > > > UAS
> > > > >    SHOULD return a 415 (Unsupported Media Type) response.
> > > > > 
> > > > >   Instead, it should read as follows:
> > > > > 
> > > > >    If a UAS does not support multipart bodies and
> > > receives one, the
> > > > > UAS
> > > > >    MUST return a 415 (Unsupported Media Type) response,
> > > and it MUST
> > > > >    return a list of acceptable formats as specificed in 
> > > > > [RFC3261]/21.4.13.
> > > > > 
> > > > >   I believe this is in line with RFC 3261/8.2.3. I will
> > > > point out that
> > > > >   we have found in the field that if a UAS does NOT send a
> > > > > 415 and just
> > > > >   "ignores" the Multipart body altogether, what happens
> > > is that the
> > > > > receiver of the
> > > > >   INVITE interprets the INVITE as having NO initial Offer,
> > > > and sends
> > > > > an an
> > > > >   Offer of it's own in the 200/18X. This is interpreted by
> > > > the sender
> > > > > of the
> > > > >   INVITE as an Answer, resulting in all hell breaking loose.
> > > > 
> > > > That's awful.  You could detect this situation by requiring the 
> > > > answerer to insert a reference to the Content-ID they're
> > answering;
> > > > if an ACK comes back without that Content-ID, you'll know you 
> > > > encountered such a defective implementation.
> > > > 
> > > > -d
> > > > 
> > > > 
> > > >  
> > > > > > -----Original Message-----
> > > > > > From: Gonzalo Camarillo
> > [mailto:[e-mail]]
> > > > > > Sent: Wednesday, May 23, 2007 01:24
> > > > > > To: Audet, Francois (SC100:3055)
> > > > > > Cc: Paul Kyzivat; [e-mail]; Dan Wing; Christer
> > > > Holmberg (JO/LMF)
> > > > > > Subject: Re: [Sip] Support for Multipart/MIME
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I have taken a stab at writing a quick draft about both
> > > issues (I
> > > > > > agree it makes sense to tackle them in a single
> > > > document). Until it
> > > > > > appears in the archives, you can fetch it from:
> > > > > > 
> > > > > > 
> http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-h
> > > > > > andling-00.txt
> > > > > > 
> > > > > > I have marked a few open issues so that we can continue
> > > > discussions
> > > > > > around those on the list (this is, of course, just 
> an initial 
> > > > > > draft).
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > Gonzalo
> > > > > > 
> > > > > > 
> > > > > > Francois Audet wrote:
> > > > > > > My preference is one document. 
> > > > > > > 
> > > > > > >> -----Original Message-----
> > > > > > >> From: Paul Kyzivat [mailto:[e-mail]]
> > > > > > >> Sent: Wednesday, May 16, 2007 05:18
> > > > > > >> To: Gonzalo Camarillo
> > > > > > >> Cc: Audet, Francois (SC100:3055); [e-mail]; Dan
> > > > > Wing; Christer
> > > > > > >> Holmberg (JO/LMF)
> > > > > > >> Subject: Re: [Sip] Support for Multipart/MIME
> > > > > > >>
> > > > > > >> Hi Gonzalo,
> > > > > > >>
> > > > > > >> I guess the question is whether we want to write a
> > document
> > > > > > >> specifically focused on Content-Disposition, or 
> if we want
> > > > > > to combine
> > > > > > >> work on that with work on specifying use of multipart.
> > > > > > >>
> > > > > > >> They aren't the same thing, but content-disposition
> > > > becomes more
> > > > > > >> significant when there are multiple body parts, so
> > > > there is some
> > > > > > >> justification for combining the work.
> > > > > > >>
> > > > > > >> 	Paul
> > > > > > >>
> > > > > > >> Gonzalo Camarillo wrote:
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> yes, Paul and I talked about writing a draft to 
> clarify a
> > > > > > >> few issues
> > > > > > >>> that relate to content dispositions in SIP a 
> while ago. We
> > > > > > >> were quite
> > > > > > >>> busy at that point and did not have time to 
> write it, but
> > > > > > >> maybe it is
> > > > > > >>> time to do it now.
> > > > > > >>>
> > > > > > >>> Cheers,
> > > > > > >>>
> > > > > > >>> Gonzalo
> > > > > > 
> > > > > > 
> > > > 
> > 
> 


_______________________________________________
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