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
