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

["Christer Holmberg (JO/LMF)" <[e-mail]>]

 

>Personally, I think we should treat parallel just like mixed 
>when received.

I agree. 

And, maybe forbid the usage of parallel with SIP, unless we really can
come up with a valid use-case where it is needed.

Regards,

Christer



>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