On Jul 15, 2008, at 2:09 PM, Paul Kyzivat wrote:
Dean Willis wrote:
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
reason
to 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".
Its probably a little different from either of these existing
policies.
Thats because it should only be applicable to *preexisting* usages.
We don't want new, yet to be deployed, usages registered in this way.
(We will probably have to use the honor system for determining which
usages qualify.)
I'm proposing that new, yet-to-be-deployed INFO usages would be in the
same registry. Only if they need a SIP Option Tag for negotiation
would they need a standards-track RFC.
I do NOT want the SIP working group to live forever as the "INFO
police". It just really doesn't matter that much what people put in an
INFO as long as they don't hurt each other with conflicting usages.
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
every
INFO message.
I think either this is a different registry, or else it is the same
registry but a different class of entry.
Nope.
I'm inclined to think it is a different registry because it is a
different namespace. The namespace for (1) is mime-types, while for
(2) it is a unique namespace of Info-types.
That's not what I'm suggesting; it's NOT mime-types; it's Info-types
in all cases. I'm saying we retroactively invent an Info-type for each
documented existing usage. As people rev their old-use code, they
would add the Info-type to their Info messages.
It might be OKAY to have a mime-type as an additional column in the
registry, although that potentially leads us down an area of mime-type
exclusion.
Do we also need a set of content-dispositions for each Info-type?
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-
track
RFC 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.
Revising the old usages is IMO counterproductive. They are what they
are.
ok.
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).
Its not even that bad. It only whacks the dialog if you put Requires
in the dialog-establishing request. If you simply put it in the INFO
itself, then the dialog doesn't get whacked.
Let's say that you send a 4XX error response to an in-dialog INFO
(because you don't understand the Info-type of the dialog). What does
that do to the dialog?
--
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
