My guess is that we would focus on "Standard-Track" INFO (e.g. # 5).
Of course, all others such vendor-specific INFO implementations can be added as a part of the above. For example, options can be built-in in the standard-track INFO to have those capabilities (e.g. #s 1, 2, 3, & 4) if one does not want to use the standardized one. BR/Radhika ----- Original Message ----- From: Dean Willis Date: Tuesday, July 15, 2008 14:33 Subject: [Sip] Moving along with the INFO discussion To: SIP IETF > > We had a large, long, and lengthy thread of discussion that I will try > to summarize. > > So far, almost everybody who has voiced an opinions says we need > to fix, > rather than deprecate, INFO. > > Opinions on fixing it vary. > > Most people seem to think we need a registry of INFO usages that will, > at the very least, give us a table of the existing usages and the RFCs > or other specs that define them. > > The sticky point of discussion is a negotiation and discovery > mechanism.We've had on-list proposals for a strong mechanism based > on the mode > used in RFC 3265. > > Some folks think we need to do this, and others thing there's no > reasonto bother since it is not likely to get implemented because just > inventing a non-standard INFO use is easier. > > Is there a middle ground? > > > What if we were to: > > 1) Establish an INFO registry and register our existing usages, policy > either "first come, first served" or "Specification required". > > 2) Define an Info-type header field and register (in the regoistry of > #1) a value for each known Info usage. Fully-compliant implementations > would send an Info-type header field with the appropriate value in > everyINFO message. > > 3) Require registration of an Info-type for each future usage into the > registry of #1 above. > > 4) Define an "Info-type not supported" error response message. This > handles the use case of a UAS that receives an INFO with an Info- > type it > does not understand. > > 5) For Info-types for which discovery is required, use a standards- > trackRFC to define a SIP extension and option tag, and use the usual > OPTIONS/Require negotiation mechanism for discovery. We might consider > revising each INFO-using RFC to define an appropriate option tag. > > This lets people easily register INFO usages and a corresponding > Info-type tag. It lets nodes that don't understand an Info-type usage > reject the message (at the expense of whacking the dialog, which > arguably was already in need of whacking). And it provides a standard > (although heavy) mechanism for discovery and negotiation when > those are > required. > > I think the above addresses the major concerns, is reasonably > implementable, is reasonably operable, and requires the smallest > possible effort to document. It's also pretty much backward > compatible. > -- > Dean > _______________________________________________ > 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 > _______________________________________________ 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
