RE: Estoterica regarding multipart MIME (was Re: [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related)

["Elwell, John" <john.elwell at siemens.com>]

QSIG over SIP implementations I am aware of use multipart/mixed.

John 

> -----Original Message-----
> From: Adam Roach [mailto:adam at nostrum.com] 
> Sent: 11 August 2007 05:54
> To: Paul Kyzivat
> Cc: Garcia, Miguel (NSN - FI/Espoo); mmusic
> Subject: Re: Estoterica regarding multipart MIME (was Re: 
> [MMUSIC] Filetransfer issue 49: multipart/mixed or multipart/related)
> 
> Paul Kyzivat wrote:
> > OK Adam. I can't find anything to argue with in your response.
> >
> > Practically speaking, I suspect that there are more 
> implementations of 
> > mixed than parallel out there. If parallel isn't 
> understood, then it 
> > is supposed to be processed as mixed, so the mixed 
> implementations out 
> > there should deal with it. (Will be interesting to see what 
> actually 
> > happens.)
> >
> > I guess the bottom line is what (if anything) we should *recommend* 
> > for use in the common cases such as SDP + QSIG.
> I still contend that the technically correct answer would be 
> multipart/parallel -- however, we did this wrong in RFC 3398 
> (I'm one of 
> the guilty parties), and I don't think there's any way of 
> getting that 
> particular cat back into this particular bag.
> 
> Future extensions would do well to use mixed only if ordering is 
> important, and parallel otherwise -- but it can only *hurt* 
> interoperability to try to change what's specified for the 
> stuff that's 
> already published, implemented and deployed.
> 
> /a
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic