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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Robert Sparks
Sent: 07 February 2008 21:35
To: sip List
Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip-
invfix-01
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 <[EMAIL PROTECTED]>
Date: February 7, 2008 3:22:23 PM CST
To: [EMAIL PROTECTED]
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.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
