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 http://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
