inline:
Dean Willis wrote:
>
> 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.
Right, and to be clear, 'violation of the specification'
basically
refers to 3261 itself.
>
> 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.
Clearly no. RFC3261 explicitly says you can't do it. I can't
think of
any reasonable use case for it.
>
>
>>> 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?
That was Keith's original proposal.
> 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?
Well, this may be a problem in theory only and not in
practice. We don't
have this problem AFAIK for any of the existing stuff.
> 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 agree that it is easier for someone, starting from
scratch, to pick up
a document which is all of sip including the corrections,
all built in.
However for folks who already implemented rfc3261 and want
to know what
has changed, a separate document that clearly states the new
functionality is easier.
>
>> 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.
I think we'll find the discipline much harder to follow if
we are
actually producing an rfc3261bis. Would we indeed reject a
one-line
clarifying correction?
>
> 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.
OK - so that is more than just a few essential corrections,
its a real
revision.
>
>> 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.
WELL, rfc2543->rfc3261 wasn't a sip3.0 either; it was
meant to be only
fixes, clarifications and elimination of unimplemented
things. But it
was still huge.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall
St.
Cisco Fellow Edison, NJ
08837
Cisco, Voice Technology Group
jdrosen cisco.com
http://www.jdrosen.net
PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
