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
