Hi, >More or less repeating what I said before: > >I expect we do have to account in some way for >implementations that have already been deployed, in absence >of a clarifying document. Exactly how we deal with that is still TBD. > >But as we define what is required to support this in the >future, I think there is *no* benefit to defining two levels >of support - full and partial. Anybody that sets out to >provide support for this document should be expected to do it >all - its not that much harder.
I also think we should take into consideration what is already out there, and not suddenly make all those implementations "wrong" just because we are now adding lots of new MUSTs. I am pretty sure that most implementations today supporting multipart only support mixed, and non-nested bodies (maybe Robert has more correct information based on his SIPit work). So, when we think about nested bodies, non-mixed multiparts etc etc etc, we really need to think whether it's a need for it in SIP in the first place - at least without an option tag. Because, again, making a huge document which mandates people to implements lots of things, just because it can be done, will not help. People will not implement it, unless they see any need for it. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > >> I wonder whether we should define an option-tag for the > support of > >> nested bodies. > >> > >> I don't think there's a lot to be gained from defining such an > >> option-tag. The sender should already be aware that there > is a risk > >> the recipient can't understand nested bodies, and have > arranged for > >> suitable fallbacks. Conversely, the recipient should (at > least) be > >> able to skip the nested multipart body part in the proper "I don't > >> understand this body part" way. All an option-tag would > do is allow > >> the sender to not add a fallback. > > > > In that case we need some specific text saying that if the receiver > > does not support nested multiparts it MUST do-this-and-do-that. > > > > Because, as I said earlier, I don't think we will achieve > what we want > > by saying that one MUST be able to parse nested multiparts. > It can be > > rather tricky to implement (depending on how the parser is > > implemented, though), and since there aren't really any > use-cases out > > there yet I am pretty sure some people will choose not to > implement it > > (and saying that people are not compliant in that case will > not really > > help from an interop perspective). So, because of that I think it > > would be good not to mandate the support of nested > multiparts, but to > > mandate appropriate behavior if not supported - just like > in any other > > case when a MIME body contains an unsupported but required > content type. > > > > 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 > >> > > > > > > _______________________________________________ > > 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 > > > > > _______________________________________________ > 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 > _______________________________________________ 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
