Jonathan,
Did you see my messages in this thread? I raised several
issues with the approach you appear to be outlining again here, and I'm
wondering if you saw them. To recapitulate just slightly:
The negotiation model appears inadequate to deal with MIME types
with significant parameters, with multipart MIME types, or with
MIME types that have "bucket" semantics (like message/cpim, the
container video types, or the 3ggp bucket mime types).
Having a dispatch based on purpose without detailed specifications or
reference to specific applications seems to hit a middle ground that's
kind of nobody's sweet spot. A specific application already has detailed
semantics that go beyond this purpose to actual decisions of whether
to render or store, user permissions needed, sizes accepted, etc;
generalized MIME transfer protocols like SMTP or HTTP already
use a different system for deciding which applications to invoke
when faced with a MIME object, and this forces systems with that
logic to have a parallel track.
The muxing seems liable to head of line blocking unless BEEP-like
channels are introduced.
This seems to re-purpose the deployed TURN servers in ways that
transform them into a generic NAT/Firewall avoidance mechanism
for any MIME type. You're listing that as a feature. Isn't there
a risk that security folks will see it as a bug?
regards,
Ted
At 4:01 PM -0800 2/22/08, Jonathan Rosenberg wrote:
>It only gets pushed to the client if the client indicates support for
>it. Thus, the typical flow is:
>
>A->B : "hey, you can send me pic if you want"
>B->A : "ok I will"
>
>and I think this is very much like:
>
>A->B : "please send be pic"
>B->A : "ok I will"
>
>which is what SIP events is about. In terms of the need to understand
>the semantics of the data, they are identical.
>Now, the intended model in TOTE is that there would be two types of
>purpose parameters. Global ones which are standardized, and a vendor
>tree. The global ones require a specification, though it doesnt at the
>moment require standards track. But it does need an RFC. I am happy to
>debate standards track vs. ietf action.
>
>That said, depending on the purpose, I don't think there is that much
>needed in such a spec. For example, for pic, something along the lines
>of "this purpose is meant for picture sharing between users. For
>example, in cases where a user with a cell phone snaps a picture during
>a call and wishes to send it to the other person, or wishes to send an
>existing file on disk. The received picture is normally rendered,
>possibly with user permission, and possibly saved by the recipient. All
>implementations MUST support image/jpg."
>I'm not sure that much more is required; we could debate whether
>max-size needs to be dealt with, and that could be done any number of
>ways. The TOTE model would argue that you would do this by having a
>message from recipient to sender, over this TOTE connection, with the
>max size. Indeed, you could also have a message from sender to recipient
>first that indicates an interest in sending a picture right now,
>including picture metadata. This would imply that "pic" is really a
>three way handshake, two of which are some new messages we'd need to
>define (and presumably would be defined by the tote usage). We could
>alternatively send those params through SDP, but that constrains us to
>the O/A 2-way handshake; and as we have seen with things like SRTP,
>having the flexibility of building the protocol without the constraints
>of O/A is highly beneficial. It also means you can add new stuff without
>extending SIP itself.
>
>What TOTE does is it avoids the need for this particular application to
>define how to get connections set up through sip, how to secure them,
>how to do nat traversal for them, how to signal what they are used for,
>how to negotiate them, and so on. It also gives us the ability to share
>connections across applications when it makes sense; this also allows us
>to have very rich multi-app communications in one session without this
>large number of connections.
>
>And so in my mind, it lowers the bar for new applications by providing a
>framework for adding new ones without needing to change SIP, and to have
>the flexibility of engineering the application ideally for its
>particular needs.
>
>-Jonathan R.
>
>[EMAIL PROTECTED] wrote:
>> From: Dean Willis <[EMAIL PROTECTED]>
>>
>> Ok, I think I agree with you here. Each "purpose" would need to be
>> very clearly specified, at roughly the same level of detail as is
>> required for an event package or would be required for an INFO package
>> if we were to go that way.
>>
>> IMHO the purposes need to be specified in *more* detail than an event
>> package. The reason is that an event package is "pull" information,
>> the meaning of the information is defined by the event-name, but the
>> requestor is presumed to know *why* it wants the information, that is,
>> what it intends to do based on that information. A TOTE object, like
>> an INFO, is "push" information, and the attached meta-data must
>> specify not only what the information means, but how the recipient is
>> expected to act on it.
>>
>> Dale
>> _______________________________________________
>> 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
>>
>
>--
>Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
>Cisco Fellow Edison, NJ 08837
>Cisco, Voice Technology Group
>[EMAIL PROTECTED]
>http://www.jdrosen.net PHONE: (408) 902-3084
>http://www.cisco.com
>_______________________________________________
>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
_______________________________________________
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
