Hi, >we should be ready for a transition to a new session >description protocol, which includes experimental networks >using their own stuff, and people seem to agree that >alternative is the way to go. That is why it would be great >if we could mandate its support already now. > >The more we wait, the more trouble we could have in the >future to use it.
Yes. But, at the same time we need to try to be backward compatible, and take into consideration existing implementations which may support mixed but not alternative. If those implementations reject alternative I think our spec should not make them "not compliant". The same thing goes for nested bodies. The more we can "fit" the spec into what is already out there, the better. So, I don't mind to strongly recommend people to implement alternative, and give examples why it may be useful in the future, but at the same time I think we should also say that if the receiver does not support alternative a error response MUST be sent - in order to avoid cases e.g. described by Francois, where the receiver simply discard the multipart and continues the call setup. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > > > Hi, > > > >>>> OPEN ISSUE 1: do we need to say something about other types? > >>>> Related (rfc2387), parallel, digest, external-body. > >>> I don't know much about these. I quickly scanned 2387 and > see that > >>> it has some special rules re processing > Content-Disposition of the > >>> contained (related) parts. I *think* those are consistent > with what > >>> we are doing. > >> I have added the following text to Section 5: > >> > >> "This specification recommends support for 'multipart/mixed' and > >> 'multipart/alternative'. At present, there are no SIP > extensions > >> that use different 'multipart' subtypes such as parallel > >> [RFC2046], digest [RFC2046], or related [RFC2387]. If such > >> extensions were to be defined in the future, their authors would > > need to make sure > >> (e.g., by using an option-tag or by other means) that entities > >> receiving those 'multipart' subtypes were able to > process them. As > >> stated earlier, UAs treat unknown 'multipart' subtypes as > >> 'multipart/mixed'." > > > > I think the text is good. > > > > But, I wonder whether we should alternative to the list of > "different > > multipart subtypes". At present there are no SIP extensions using > > alternative either, so... > > > > Or, at least we could leave support of alternative open for the > > moment, until we get more information about how it's supposed to be > > used in the first place (regarding identical content type > values etc). > > > > > >>>> 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. > >>> > >>> So I think what you have is ok. > >> I double check with an email expert to make sure we get this right. > > > > > >>> Another thing in Section 3: You have used SHOULD in this > section. I > >>> thought we wanted to change this to MUST. Did we? > >> You refer to the following statement, right? > >> > >> "In particular, UAs SHOULD support the 'multipart/mixed' > >> and 'multipart/alternative' MIME types." > >> > >> If people agree that this should be a MUST, I will be > happy to change > >> it. > > > > Again, I think we should wait a little regarding alternative. > > > > Regards, > > > > Christer > > _______________________________________________ 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
