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 MIME spec already says that if you don't understand >multipart/X then you should treat it as if it were >multipart/mixed. So at a minimum we should expect >implementations to do that much with alternative.
Well, assuming we don't think THAT could cause problems in the future... But, since that is generic specific MIME behavior I think we'll have to live with it. But, I STILL think it's good to give an implementation to option to reject alternative - at least if we find out that is what existing implementations are doing. >If we are going to make more accommodation than that based on >what is in the wild then I suggest we should take a survey >first to find out what we really need to cope with. We should >be able to get some good data from SipIT. Maybe we should be >trying to come up with a list of specific questions, or maybe >we can have an essay question on the survey to get a >description of exactly what is/isn't supported. My understanding is based on my SIPit experience, and what I have implemented myself. But, I have to admit I haven't been to SIPit for a while, so someone else (Robert?) may have better information. >I think we will have a pretty good chance of seeing support >in the future if we can tell implementors what they must do. It's not always the implementors we have to tell - often it's the people paying the implementors :) >I did specifications for multipart support in a stack a few >years ago (which is when I discovered all these open issues), >and I had to make up what was done based on speculation about >what would be used. Even hard things can be straightforward >to implement if the requirements are clear. I am not saying that it is difficult to implement alternative, but I doubt many have done it. But, it would be interesting to know what implementations do: 1. do they treat alternative as mixed? 2. do they reject the request? 3. do they support alternative? 4. do they discard the message body? I think our spec should allow options 1, 2 and 3. Regards, Christer > >>> > >>> 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
