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

[Ted Hardie <[e-mail]>]

> >     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.

But event packages are fairly fully specified, compared to what this
draft seems to propose.  If you have an extremely generic statement
like "pic" and expect to extract semantics beyond that of the top
level image/ mime type, I think you're going to get pretty disappointed.
Now that I am re-reading after having gotten "home" (wink-wink),
maybe I did miss the idea.  If the idea is that the specification of
"pic"  or "name" is at the level of the specification of an event package,
then we are dealing with something else entirely and the draft can
be re-written to express that.  But I would expect, in that case, for each
of the registered purposes to be very carefully specified as to what the
acting application would do with them.  And I suspect pretty much
everything like "name" would have to go.

>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.

Again, if the level of specification that is expected is equivalent to event
packages, this has some hope of working.  Look at the IANA considerations
section again, though, and I think you'll see that does not appear to
be required by the current draft.

> >
>>
>> 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?

I'm saying that what the draft appears to be replacing INFO with is as bad
as INFO, as the "purpose" looks to be a mighty low-quality signal for
disposition.  There are some existing, common MIME types which
are bad, no question.  "pic", however, doesn't seem to tell you any better than
image/jpeg whether to display, it file, transform it, examine it for watermarks,
or print out the coupon it contains for a free helicopter ride to
CityWest.    Neither image/jpeg or "pic" is likely to do as you as much
good as one of the application-protocol specific MIME types created with
a disposition in mind, like application/atom+xml .

> >
>
>Did I just wake up in a different quantum universe again? Dang it,
>that always confuses me.

Permit me to suggest a dram or two of a well-tempered liquid, preferably
after it has been aged in a wood barrel of some kind.  It might not result
in clarity, but that won't bother you nearly as much.

				Ted
_______________________________________________
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