RE: [Sip] Support for Multipart/MIME

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

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 like your text on Multipart/Alternative. I'd like to include the 
  following snippet of text from draft-jennings-sipping-multipart-02.txt
  in there:

   It is critical that multipart/alternative offers follow the semantics
   of multipart/alternative, notably the following text from RFC2046
   [2]:

       "THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE:  Each
        part of a "multipart/alternative" entity represents the same
        data, but the mappings between the two are not necessarily
        without information loss.  For example, information is lost
        when translating ODA to PostScript or plain text.  It is
        recommended that each part should have a different Content-ID
        value in the case where the information content of the two
        parts is not identical."

  I'd also like to see an example of Multipart/Alternative for the
  MESSAGE message (with text/plain and text/html for example).


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

  

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