Re: [Sip] On The Essentialness of Corrections

[Dean Willis <[e-mail]>]

On Dec 14, 2007, at 4:36 PM, Jonathan Rosenberg wrote:

> 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.

Ok, there's probably a valid argument here. It's important to note  
also that if something is an "essential correction", we'd be willing  
to say that an implementation that does not conform to the correction  
is in violation of the specification and needs to be fixed. In other  
words, there is the same sort of justification for fixing it as there  
is for "MUST" in RFC 2119 -- failure to conform creates a failure to  
interoperate or function correctly.

Now, it's arguable whether the record-route-fix falls into this  
category or not. Route rewriting, as opposed to double recording,  
prevents route signing. Is the ability to use route-signing important  
enough that we'd say that any implementation that precludes its use  
is "broken"? I'd say that this is the test.


>> 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.

Let's say we roll the 7 changes (I just made that number up, there  
may be more or less) for 2008 into the 2008 essential corrections  
RFC. What do we do in 2009? Copy all of the 2008 changes into the  
2009 RFC? What happens when we've had overlapping changes, such that  
the same part of the spec has been touched twice? Does the second  
change need to write step-by-step edits against the base RFC, or  
against the base RFC as amended by the first change? This gets hairy,  
and it is made a lot easier if we write the first change against the  
RFC, apply the first change to the RFC to generate the -bis spec, and  
then make subsequent corrections bundles against the -bis spec. This  
gives us a "fully assembled" spec to work against. Reverse deltas as  
opposed to forward deltas, from a source-code-control perspective.

> 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.

I'll certainly agree that a substantial amount of discipline is  
required in either case.

The question is: Do we want one document an implementor can go to, or  
do we want a base document plus many "diff" deltas?

Looking at the bug tracker for RFC 3261, I can see that there have  
been 85 different bugs filed. While some may not meet the criteria of  
"essential" (is confusing "excepting" and "accepting" essential?),  
I'll bet you there are still a lot of things that need fixing in the  
doc. And RFC 3261 isn't the only spec that needs polishing -- there  
are over 200 bugs in that tracker.

> 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.

I'm not proposing SIP 3.0 here -- just proposing ways to correct the  
known bugs in our RFCs that produces a result usable by developers,  
students, other SDOs, and other readers of those RFCs. What we're  
doing now IS NOT WORKING.

--
Dean




_______________________________________________
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