IMHO, this whole thread is threatening. Think of this analogy: SIP:3GPP::MIME:SIP-MIME
We are going WAY down the slippery slope of defining something that looks like MIME, but is not MIME. This is bad. Or evil. It depends on your disposition [sic]. If you want to know how that feels, what is your visceral response to Service Indicator? Well, that is how the MIME community responds to proposals that say, "we'll take MIME, but have it operate differently, but call it MIME." I know, no matter what we do here, there will be a 3GPP-MIME :-( For example, RFC 3204, referenced by the draft, is NOT the normative reference for the handling parameter. RFC 3204 describes SIP-ISUP interworking. It happens to describe a SIP-specific handling parameter. RFC 3459 is the normative reference for the handling parameter, which includes its use in SIP, as well as general-purpose MIME. I would offer the description for the motivation for the handling parameter in RFC 3459 is more relevant to SIP today than the description in 3204. [As a historical note, the text for RFC 3459 pre-dates RFC 3204 by 2 years, but had a stupid dependency on another document that didn't pop until 2003. That was my fault.] I do NOT buy the argument there are too many broken implementations to do the right thing. In that case, jettison the whole MIME infrastructure and build something you like (any takers for XCAP?). Do the right thing now, and say, "MIME is MIME." You even get some benefits, like a bunch of open source MIME implementations that one can use, rather than hacking these implementations to do SIP-specific stuff. On 5/29/07 9:05 AM, "Gonzalo Camarillo" <[EMAIL PROTECTED]> 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. > > 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. > > 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, >>> >>> 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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
