I agree with John too. I don't see the benefit. It would be beneficial to have one for a specific package, for example dtmf, maybe, but not the mechanism. It's like having an option tag to support the Allow/Accept/Supported headers, as opposed to their values. This draft is basically just a negotiation mechanism and defining how to handle things - not the things themselves.
We'll still have the method name "INFO" for the Allow header, if you want to say you can't do INFO requests. -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Elwell, John > Sent: Friday, November 21, 2008 8:21 AM > To: Christer Holmberg; DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat > Cc: SIP List > Subject: Re: [Sip] INFO Framework: Tags > > Christer, > > OK, it might be simple, but still unnecessary, so why do it. I haven't > heard a compelling argument in its favour. Per-package option tags are > far more compelling (depending on particular needs of a package), > although I agree such packages would need a standards track document. > > John > _______________________________________________ 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
