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
