RE: [Sip] Support for Multipart/MIME

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[e-mail]] 
> Sent: Wednesday, May 30, 2007 1:57 AM
> To: Dan Wing
> Cc: 'Paul Kyzivat'; 'Francois Audet'; [e-mail]; '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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip