Re: [Sip] New I-D - TOTE - "INFO" on the media path

[Dean Willis <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip