On Jun 24, 2008, at 11:52 AM, Robert Sparks wrote:
The bet we would be placing by putting the work into creating this
framework is that it actually takes some motivation away from using
a non-standard bare INFO to realize some new application (and that
there are new applications out there where this would be a really
good tool to have to realize them). Is this framework really
lowering a barrier to entry or relieving some other pain so that the
people who would otherwise make a new non-standard use of INFO come
use it? I'm having a really hard time seeing that.
Well, that's the whole reason we write RFCs instead of just telling
people to innovate, isn't it?
If we end up on the wrong side of that bet, we've arguably made
things _worse_ taking work away from other things, creating
mechanics that have to be implemented, tested and will ultimately be
abused, and not solving the actual problem in the first place.
So, I'll continue to look for some evidence this will actually get
used and relieves some pressure to just go use INFO in a proprietary
way and skip all this standards pain (hopefully folks here can help
me with this).
Without it, I think the better path would be to create the registry
you describe, publish an informational document pointing out the
pitfalls of the approaches they take, and get on with other work.
Don't use INFO. By the way, here's the "standard required" process for
registering your non-standard INFO use by MIME-type and content-
disposition. . . Don't blame us when it kills you, or you have to
register a new MIME or content-disposition because somebody already
signed up for the one you want to use.
I kind of like that approach. Can we do the same thing with P-headers?
It'd sure save us a lot of work.
--
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
