inline:
Dan York wrote:
On Jul 7, 2008, at 9:50 AM, Jonathan Rosenberg wrote:
inline:
Robert Sparks wrote:
inline
On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote:
Mary,
My latest thought is that we should "grandfather" existing uses of
INFO. We would provide a registry of them, without blessing them or
standardizing their specifications. That would at least shine some
light in the dark corners.
DY> I completely agree with the need for a registry of existing uses of
INFO. At least if we know what they are, we can then understand what
gaps in existing standards may be out there and what areas may need more
work. Compiling such a registry also may limit further proliferation of
new uses as people looking to use INFO may find an existing one and use
it instead. (Assuming they think to look for this registry instead of
just going ahead with doing whatever they want with INFO.)
DY> I'm not sure I fully agree with "grandfathering" existing uses of
INFO. I mean, on the one hand, there's really nothing we can do about
them, so in that respect they *are* "grandfathered". But I think we
should provide some guidance to new implementors about how they should
use INFO. So compiling a registry of existing uses would be good... as
long as there was also some way to highlight which of the uses are the
ones "preferred" by the IETF.
At the same time, we would define the new INFO usage framework
(still TBD) and ban *new* INFO usages that don't follow it.
Well, if we don't think banning INFO as a whole would be listened to,
why do we think banning INFO that doesn't use this new framework
would be listened to?
That's where I'm having difficulty with the question. I can see the
bite of work it would take to make the framework.
I'm still trying to see what would actually use it if we did?
Can somebody list the packages that we've already identified that we
would put out with this framework?
There are two separate questions here.
One is: if we put out this framework, would folks currently building
non-standard INFO usages use it for their next new proprietary usage.
The other is, are there existing packages (standard or proprietary)
that we would move over to this framework?
On the former question - I think the cost of this framework is light
enough, and the benefit is great enough (much easier determination of
what INFO usages are supported and will be used), that there is little
reason for folks NOT to use it. Implementors break standards not out
of malice, but because they find that what we have produced is not
sufficient, or too expensive to implement given the value in brings.
So the key to success is extreme simplicity.
DY> I agree that the key is extreme simplicity. However, I am rather
skeptical that we'd see much movement over to the framework from
existing implementors of non-standard INFO usages. If you are a vendor
who has a working solution out there in the field using INFO in some
non-standard way, what is your incentive to change that *working*
implementation?
Not much. I think we're talking about new stuff. I am making the
assumption that we're not 'done' - we'll see continuing needs for new
signaling data transfer, both standards-based and proprietary.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
