Gonzalo Camarillo wrote:
Hi,what I am hearing is that there are implementations out there that support multipart but not nested. Therefore, we need to decide two things:1) do we want to have a MUST for multipart and a SHOULD for nested? I would say that we should have the same level (e.g., MUST, if we decided that MUST is appropriate) for both.
I think if we don't do this, we will simply be creating another problem such as the problem we have today with multipart.
2) do we need a way for implementations that support multipart but not nested to be quickly updated to, at least, report that fact with an error response? This may make sense.
This only makes sense if there is something that the sender can do about it. For instance today a 415 that indicates support for SDP but not for multipart tells a sender that used multipart with SDP and some optional parts to try again with just the SDP.
So the question is: is there anything that the sender could do in this case. We already have a SHOULD strength requirement to not do gratuitous nesting. If that had been followed then the nesting must not be gratuitous, so what is the fallback strategy.
Also, I think if we do a survey we are likely to find more restrictive limitations than just no nesting. For instance multipart may only work with certain contained body parts. I suspect it is a fools errand to attempt to describe the particular restrictions of a non-compliant implementation in the hopes that the sender will be able to craft an alternative form of request that is useful.
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.
Paul
Cheers, Gonzalo 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, ChristerSip mailing list https://www1.ietf.org/mailman/listinfo/sipThis 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
