> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Friday, October 12, 2007 12:57 PM > To: Stucker, Brian (RICH1:AR00) > Cc: Dean Willis; 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) > > > > Brian Stucker wrote: > > > You forgot about supported. > > > >> 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 > > > > 200 OK > > Supported: foo > > Allow: INFO > > Accept: application/foo > > > > ... > > > > INFO > > Content-Type: application/foo > > [DTMF] > > > > > > Where is this broken? > > This can work if there is an RFC defining the foo option that > specifies that when both parties support foo then: > - the UAC may use INFO to send information using > Content-Type application/foo and Content-Disposition: (TBD) > - the circumstances triggering the UAC to send are ... > - the expected actions of the UAS upon receiving are ... > > Because this uses an option, and a new option can only be > defined via an RFC, this technique is only available > (legally) when an RFC will be approved. (Of course people > have been known to invent new options without an RFC, but > that is non-conforming usage.)
That seems like more of a legal loophole for defining event header values than anything else. There's only one currently IANA registered event header value that is not associated with an RFC and I doubt that one is going to live for very long in light of RTCP-XR. Are you advocating not having to have an RFC for an event header as a positive thing? If so, then isn't this equivalent to a vote for leaving INFO alone? Regards, Brian _______________________________________________ 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
