|
John - sorry for the slow reply - I wrote a reply the day you sent this, but as far as I can tell it got eaten before it made it to the list.
I didn't intend section 7 to be "just" a description - you inferred that from "this section describes"?.
Yes, the document has the risk you describe. I don't think we can avoid that without giving up making a standalone section that's as clear as Jonathan wants or specifying exactly what changes in 3261. The only way to mitigate that risk is careful review, which I think is possible given that the scope of this fix (and all *fix documents) should be pretty small.
I feel pretty strongly that _for this change_, specifying exactly what gets touched in 3261 is important or we'll end up with interoperability arguments. The language that got touched is argued through at each SIPit already - not making it as crystal clear as possible how it gets impacted will make that worse. Whether or not we need to do that for every *fix document, I don't feel quite as strongly about, but this one is an existence proof that we'll need it for some.
RjS
On Feb 8, 2008, at 1:31 AM, Elwell, John wrote: Robert, So we have two sections containing RFC 2119 language and saying the same thing in different ways. If section 7 is just a description, as it claims, then should it not avoid RFC 2119 language. Otherwise, which section takes precedence in the event of a conflict? John
Based on the feedback from the -00 draft, I've added a section that details the changes this draft makes in a more descriptive form (in addition to the patching-the-text form that already exists).
Please look at the new section 7 and see if this addresses the concerns around the document format.
I also spent some time experimenting with the suggestions to provide the changes in a diff format and have not found anything promising. For the sake of discussion, I did prepare a patch file that I'll send in a separate message. I'm becoming more convinced that that's the wrong approach to take though. We really don't want to create some form of derived document that's the "current spec". If we really want a new document, lets create a bis and be done with it.
The point of creating the patch-the-text form in the first place was not to facilitate creating a new document out of the old document. It was done so that the impact of the changes on the spec is expressed in as unambiguous a form as possible. The worst outcome would be an update that _didn't_ make these explicit statements and half of the implementors in the world end up looking at a section and saying "Oh, I didn't know it meant to change _that_".
RjS
Begin forwarded message: From: IETF I-D Submission Tool < idsubmission ietf.org">idsubmissionietf.org> Date: February 7, 2008 3:22:23 PM CST To: RjSnostrum.com">RjSnostrum.com Subject: New Version Notification for draft-sparks-sip-invfix-01
A new version of I-D, draft-sparks-sip-invfix-01.txt has been successfuly submitted by Robert Sparks and posted to the IETF repository.
Filename: draft-sparks-sip-invfix Revision: 01 Title: Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests Creation_date: 2008-02-07 WG ID: Independent Submission Number_of_pages: 18
Abstract: This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk.
The IETF Secretariat.
|
