> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 16, 2007 3:56 PM > To: Stucker, Brian (RICH1:AR00) > Cc: DRAGE, Keith (Keith); IETF SIP List; Audet, Francois > (SC100:3055); Christer Holmberg > Subject: Re: What are we arguing about when we say INFO? (was > Re: [Sip] INFO) > > > On Oct 12, 2007, at 12:02 PM, Brian Stucker wrote: > > >> > >> That's back to the question of "Is SIP an application > protocol or a > >> transport protocol"? > >> > >> Should the SIP-layer software be aware of and coupled to > the state of > >> the application that's using SIP? > >> > >> If so, then the proper design model is to build a new SIP request > >> method for every new piece of application functionality. > > > > You forgot about supported. > > > > Well, it's entirely possible that Supported and Accept will > get damned big. I'd still like to have a query-for-specific > or "opt in" > model rather than a blanket "here's everything I can possibly > deal with" model for declaration of extensions. RFC 3265 > meets that requirement. > > >> > >> So for example, DTMF: Using this model of SIP extension, we might > >> define a new "DTMF" method. It would look just like > DTMF-over-INFO, > >> except the name of the method would be DTMF. > >> It clearly resolves the INFO-context question, because now we KNOW > >> we're getting dialog- related DTMF over it, and we know what to do > >> with it. We know what we can transport in DTMF-requests, > because the > >> RFC that defines the DTMF extension method will also > define exactly > >> what payload format to use. > > > > INVITE > > Supported: foo > > Allow: INFO > > Accept: application/foo > > > > But the MIME people aren't going to let you register a new > MIME type for "foo" that is specific to each application > semantic that might possibly use "foo". > > > 200 OK > > Supported: foo > > Allow: INFO > > Accept: application/foo > > > > ... > > > > INFO > > Content-Type: application/foo > > [DTMF] > > > > > > Where is this broken? > >> > > Broken in its usage of MIME. > > Let's say we have something (not DTMF) that needs to > transport jpg images that are used as soft-key overlays. To > do what you're suggesting, we'd need a new MIME-type > registration that says "This is just like jpeg, except that > it is only useful for keypad overlays". > The MIME folks would birth kittens.
I think you may have misunderstood my example here. I'm postulating that you don't change the MIME type (jpeg) you change the supported/required header value. _______________________________________________ Sip mailing list https://www1.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
