RE: [Sip] On The Essentialness of Corrections

["Elwell, John" <[e-mail]>]

As a further consideration, MMUSIC already seems to be taking an
approach for SDP similar to Dean's proposal for SIP:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-00.txt

John

> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]] 
> Sent: 15 December 2007 18:53
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] On The Essentialness of Corrections
> 
> 
> 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
> 


_______________________________________________
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