Re: [Sip] On The Essentialness of Corrections

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip