On Feb 19, 2008, at 4:29 PM, Ted Hardie wrote: > Howdy, > So I read this, then re-read this after having some more coffee, > and I seriously considered re-reading it again after something > alcoholic, > just so I could see whether it seemed like a good idea in any of > those states. > Since my workplace declines to provide a wet bar, I didn't manage the > last, so there is some chance I'm way off base here. > First, some comments on the mechanics. Having a "purpose" > that is not tied to the top level type of the mime type you're > transporting > opens you up to a lot of silly states. If I send you a purpose > claiming > something is a pic, but provide text/plain, is it ascii art? If I > claim it is > a pic, but provide application/octet-stream, will the data get fed to > a renderer? That is, does the MIME type or the purpose handle > disposition? > The "Semantics" session seems to indicate it is purpose that governs > this: > > Semantics: Each purpose MUST clearly define what its used for. > T he > definition must be sufficiently clear to allow an implementation > to decide whether to render the object, what kind of UI to apply, > how and where to store the object, how to process it, and so on.
Well then, none of the way we use MIME in any of the "considered good" uses in SIP must make any sense. For example, with NOTIFY, the body is some sort of MIME object that may well have many different possible uses. It's the event type that tells us what that specific mime type means in the context of this NOTIFY. Otherwise said, an event package that defines a NOTIFY contain an application/octet-stream has to explain what to do with the octet- stream. What does it mean if we get a NOTIFY containing an image/jpeg? Should we display it? File it? Turn it into an mjpeg movie? Run a fingerprint recognizer on it? Apply steganogarphic analysis to extract the watermark? Here, the handling is driven by the event type, not the MIME type. That's the same as a "purpose" in TOTE. Each TOTE purpose would need to be documented, and that documentation would need to explain what MIME types can be sent for that purpose, and what it means to receive such a type in the context of a given purpose. > > > That's going to break how a lot of other things handle MIME object > transport, and incidentally call into question a very basic mechanism > for minting new application protocols currently in favor (that is, > using specialty > MIME types to trigger the handling). I'm not saying it's not a > valid design choice, > but it does run counter to the current set of trends. I also am > concerned that in using > the purpose, the design opens things up to crafted payload attacks. The whole argument against INFO is that the MIME type itself is inadequate to trigger the handling. If it were adequate, we wouldn't have had this big fight about INFO for the last n-many years. Or are you now saying INFO is good and sip-events are BAD? > Did I just wake up in a different quantum universe again? Dang it, that always confuses me. -- Dean _______________________________________________ Sip mailing list http://www.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
