inline:
Dean Willis wrote:
Here's a test I'd like to propose: If the change is such that if we were
re-writing the affected RFC we'd include the new behavior as normative
behavior, then we track it as a revision. This allows us to fully
deprecate the behavior that it replaces, such that we no longer have to
consider the old behavior when compliance testing. If we can't deprecate
the replaced behavior, then we really do have an extension (not a
revision), and we need an extension negotiation mechanism to know when
it can be used or is being used.
I'm not sure I agree with this. I think we have some extensions which
we'd arguably include as, 'things we'd make as new normative behavior
that is core to sip'. I personally would have wished that nat traversal
were an integral part of sip and if I could do it over, would not have
it split out. But clearly ICE and outbound and all that are not
essential corrections.
In my mind, the right litmus test is that the new behavior:
1. cannot be negotiated using the standardized techniques, AND
2. represents a change that impacts interoperability with other
implementations which might not implement this new behavior
THEN its an essential correction.
THings like BNF bugs are clearly in scope. Something like record-route
fix doesn't meet this litmus test because of the second item. I can
implement this and fully interoperate with existing implementations.
I'd actually like to see us go beyond the batching of "essential
corrections" and start maintaining complete and fully-revised versions
of the normative behaviors as internet drafts, perhaps occasionally
publishing them as RFCs that replace the older versions. So for example
with RFC 3261, we'd maintain a "draft-ietf-sip-rfc3261-bis" that would
start as a copy of RFC 3261 (with current boilerplate, of course) and
then be edited to reflect the changes documented in each "essential
correction" we agree to. Then instead of telling implementors to go read
RFC 3261 plus a dozen more potentially conflicting revision documents,
we could just say "see draft-ietf-sip-rfc3261-bis-xx".
I thought the idea is that there is just one revision document
(essential corrections) and not seven.
I promise you that once you open the floodgates to an rfc3261 revision
spec, the temptation to do LOTS of other things to the document will be
too great. Clarify this while we're at it? OK. Maybe we should pull that
extension in. ANd so on. I don't want to do that. Segmenting this into
an essential corrections document keeps pandoras box from opening.
The amount of work that went into rfc2543 -> rfc3261 was astoundingly
large, as any of the editors who basically did this as a full time job
for like 6 months will tell you (my boss would ask me when I was coming
back to work...). I do not think we as a working group have or want to
spend the cycles on such a monumentally large task at this time.
-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://www1.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
