Hi, >For inadequate implementations I think we must focus on the >installed base that must be coped with. In that regard, >specifying something that the existing implementation must >do, that it doesn't already do, makes little sense.
I guess there are people who know this better than me, but I do believe there are implementations which do reject nested bodies today. I agree that we can't do anything regarding implementations which simply discard anything they don't understand. Regards, Christer > > Paul Kyzivat wrote: > >> 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. > >> > >> Paul > >> > >> 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
