Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip-invfix-01

From: Robert Sparks <[email-masked]>
Date: Thu, 7 Feb 2008 15:34:35 -0600

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-masked]>
> Date: February 7, 2008 3:22:23 PM CST
> To: [email-masked]
> 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 08 Feb 2008 07:31:50 +0000

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-masked] [mailto:[email-masked]] 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).

	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-masked]>
		Date: February 7, 2008 3:22:23 PM CST
		To: [email-masked]
		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.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 29 Feb 2008 09:28:12 -0600

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-masked] [mailto:[email-masked]] On Behalf  
> Of Robert Sparks
> Subject: [Sip] Fwd: New Version Notification for draft-sparks-sip- 
> invfix-01
>
> to create some form of derived document that's the "current spec".  
> If we really want a new document, lets create

Sip mailing list  https://www.ietf.org/mailman/listinfo/sip

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 29 Feb 2008 16:24:04 +0000

Robert,
 
OK, I accept what you say.
 
John

	From: Robert Sparks [mailto:[email-masked]] 
	Sent: 29 February 2008 15:28
	To: Elwell, John
	Cc: sip List
	Subject: Re: [Sip] Fwd: New Version Notification for
draft-sparks-sip-invfix-01

	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

		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-masked]
[mailto:[email-masked]] 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-masked]>
				Date: February 7, 2008 3:22:23 PM CST
				To: [email-masked]
				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.