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:[EMAIL PROTECTED]
> Sent: Wednesday, May 23, 2007 01:24
> To: Audet, Francois (SC100:3055)
> Cc: Paul Kyzivat; [email protected]; 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:[EMAIL PROTECTED]
> >> Sent: Wednesday, May 16, 2007 05:18
> >> To: Gonzalo Camarillo
> >> Cc: Audet, Francois (SC100:3055); [email protected]; 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
