At 10:36 AM -0800 2/25/08, Jonathan Rosenberg wrote: >Ted, > >I did see your note. Dean had responded, and your response to him, I >thought, indicated that you were satisfied that having purposes >specified (which was the intent of the draft) addressed your concerns. >Sorry for having misunderstood. Some responses below:
Sorry for the delay in replying. Some further questions below. >Ted Hardie wrote: >> 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). > >OK; this was just a -00. There are two ways to deal with that: > >1. add the additional negotiation needed for this as new SDP parameters, or > >2. don't bother at all with MIME negotiation as part of SDP for TOTE; >rather, each purpose would have a protocol to doing the negotiations >needed to make its functionality work. This avoids needing to do a >general purpose MIME thing. FOr example, in the case of "pic", we'd >actually define a little protocol that negotiates pictures sizes and >supported types. In that applications, buckets and multiparts aren't an >issue. > >I'm inclined towards #2 actually. But note that, I put into TOTE exactly >the same level of MIME negotiation that SIP itself provides. SO if it is >grossly inadequate here, so it is there. I'd be interested in seeing more on how #2 works. One of my concerns with "pic", to take one example, is how a very generic purpose like trading images gets used by applications that want it. How does a system know when a pic being sent from one side of the TOTE exchange to the other is meant as a new user icon, an avatar for a MMORPG, or a stand-alone picture relevant to some ongoing exchange on a real time channel? If there is more interaction than just "purpose" and mime type, then re-use of this by applications that want the facility may work. Otherwise, it seems you are either going to head towards purposes like "vnd.WoW" that have no generality or you are going to get what amounts to a least-common-denominator application. The "I can send you my name" application is not really too compelling. > > >> 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. > >That was never the intent. The IANA considerations section states that >these require specification. > >> 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. > >That would seem to argue for pulling the MIME aspects out of TOTE. > >> >> The muxing seems liable to head of line blocking unless BEEP-like >> channels are introduced. > >This is discussed; if the purpose requires significant content, set it >up as a separate session/tcp connection. What you have there now is: However, if a purpose represents a significant amount of data, such that head-of-line blocking might occur between purposes, an agent SHOULD utilize a separate TOTE session for that purpose. I guess this still worries me. If an application wants to set up a TOTE connection with an existing peer, I'm guessing it will need to decide whether to re-use an exiting session or set up a new one. While it may have a sense of whether it will have large amounts of data to send, it doesn't have any idea of the sensitivity to head of line blocking from the other users of the connection. That pushes the decision into the agent which knows something about both. But that ends up requiring a lot of knowledge of the protocol usage characteristics of the using application which go beyond what TOTE will carry on the wire (some uses of "pic" with image/jpeg are really highly unlikely to cause head of line blocking; others might be a real clog). Defaulting to non-muxed connections eliminates that, of course, but removes one of the benefits you propose. > > >> 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? > >I think you are getting wrapped up in the MIME parts of this, which is >not the main point. The main point is that there are lots of cases where >we need UA to UA communications - see: > >http://www.ietf.org/internet-drafts/draft-kaplan-sip-info-use-cases-00.txt > >I was trying to provide a common mechanism for addressing those cases >where we don't want to send all this garbage over SIP - we want it over >the media plane. Are you objecting to that? A number of your purposes seem pretty far outside the info-use-cases draft, and the level of generality does raise issues. Maybe I am too concerned with the "generic MIME transport" aspects of this, but I think replacing INFO with a media plane solution that does not have at least the level of specificity of event packages is not helpful and may even be harmful. I'll try to corner you in Philadelphia to discuss this in person, especially on your "little protocol" proposal above. There may be an opportunity there. regards, Ted >-Jonathan R. > > >-- >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 https://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
