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