IMO the registry of existing usages is at least, if not more, important
than standardizing future usages. It gets all the proprietary usages out
in the light of day. That will provide a way to understand what sort of
mess we have.
Paul
Roy, Radhika R Dr CTR USA USAMC wrote:
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
_______________________________________________
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
