I'm fine with that interpretation, too, because it keeps us away from using MIME to negotiate and we keep negotiation in SDP (and SDP Cap Neg).
-d > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 3:10 PM > To: Dan Wing > Cc: 'Gonzalo Camarillo'; 'Francois Audet'; [email protected]; > 'Christer Holmberg (JO/LMF)' > Subject: Re: [Sip] Support for Multipart/MIME > > Dan, > > If I follow what you are saying then I disagree with the use case. > > I believe the Content-Language specifies the language of the > text in the > body part, not the language that might be conveyed in a media stream > that is negotiated by the SDP in the body part. > > Paul > > Dan Wing wrote: > > > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, May 30, 2007 1:57 AM > >> To: Dan Wing > >> Cc: 'Paul Kyzivat'; 'Francois Audet'; [email protected]; 'Christer > >> Holmberg (JO/LMF)' > >> Subject: Re: [Sip] Support for Multipart/MIME > >> > >> Hi Dan, > >> > >> thanks for the pointers. It seems that we want to specify > that, for > >> multipart/alternative bodies whose content disposition is > >> "session" (or > >> early session), the content-types of all body parts MUST > be different. > >> > >> However, multipart/alternative bodies with a different > >> disposition type should follow the general MIME rules. > > > > Yes, I concur. > > > > You also brought up an interesting point with language. > One Might Consider > > it reasonable to have multipart/alternative, with several > application/sdp > > parts which differ in language (and probably different m/c > lines). Your > > document should probably provide a pointer to SDP's a=lang > and guidance > > towards its use in conjunction with SDP Capability > Negotiation. Sortof a > > 'you might be tempted to use MIME constructs where SDP > should be used > > instead'. That is, if there is agreement that a=lang and > SDP Capability > > Negotiation is the right way to select language. > > > > (I'm thinking of situations where, for example, you want to > send an offer > > for an English, German, or French announcement ("The dam > broke, please > > evacuate to higher ground") or an IVR or a human telephone > operator). > > > > -d > > > >> Cheers, > >> > >> Gonzalo > >> > >> > >> Dan Wing wrote: > >>> Paul Kyzivat wrote: > >>> ... > >>>>> OPEN ISSUE 2: we know that we do not want two SDPs in a > >>>>> 'multipart/ > >>>>> alternative', but is this valid generally with any > >> content type? > >>>>> Would it be possible to provide two alternative body > >>>>> parts using the > >>>>> same format and, thus, the same content type but in, > >>>>> say, different > >>>>> languages? > >>>> Its my understanding that the distinction is based on > which can be > >>>> understood, relative to Content-Type. It isn't apparent > to me that > >>>> making this decision based on other attributes is valid. For > >>>> one thing the parts are supposed to be ordered by increasing > >>>> richness. If they differed by language this wouldn't be true. > >>> Multipart/alternative is the best we have, though. And who > >> is to say that > >>> image/jpeg is richer than image/gif, or that english is > >> richer than latin? > >>> Anyway, the following RFCs standardize the use of > >> Content-Language and refer > >>> to using multipart/alternative when providing support for multiple > >>> languages: > >>> > >>> http://tools.ietf.org/html/rfc3282 > >>> http://tools.ietf.org/html/rfc3066 > >>> > >>> -d > >>> > > _______________________________________________ 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
