tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07
Jonathan Rosenberg <jdrosen@dynamicsoft.com> Mon, 11 February 2002 22:10 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19289 for <sip-archive@odin.ietf.org>; Mon, 11 Feb 2002 17:10:37 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05821 for sip-archive@odin.ietf.org; Mon, 11 Feb 2002 17:10:39 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04196; Mon, 11 Feb 2002 16:35:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04109 for <sip@optimus.ietf.org>; Mon, 11 Feb 2002 16:34:55 -0500 (EST)
Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17883 for <sip@ietf.org>; Mon, 11 Feb 2002 16:33:51 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BLY96Y025602; Mon, 11 Feb 2002 16:34:10 -0500 (EST)
Message-ID: <3C6838A0.86D9AF48@dynamicsoft.com>
Date: Mon, 11 Feb 2002 16:33:20 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: William Marshall <wtm@research.att.com>
CC: sip@ietf.org
Subject: tsvchange and Supported/Require, was: [Sip] Last Call comments on 2543bis-07
References: <200202041726.MAA76667@fish.research.att.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit
going through this thread, logging the bugs needed to be fixed. Ran into a question here: William Marshall wrote: > 2) Carriers are unfortunately obliged to meet regulatory requirements. > At least some of these, related to Electronic Surveillance, will not > be standardized by IETF (see RFC 2804), though publication is > encouraged (presumably as informational RFCs). However, they may > require > extensions to SIP, and definition of additional headers and option tags. > > It would be unfortunate if this resulting protocol could not be called > SIP. This is an ugly subject, granted, and I do not want it to delay > publication of bis as an RFC. My proposed resolution of this is > to have bis make reference to draft-tsvarea-sipchange-xx for the > guidelines of extensions being standard-track RFCs, and have the > discussion when that draft is re-issued and last-called. > Affects lines 1094-7, 1103-4, 1306-7 I think much of this thread was not properly interpreted by the list, because people are not aware of the specific content of these lines. And that makes a big difference. These lines are about the usage of option tags in Supported and Require. The spec says that these headers can only contain references to standards track RFCs. That does NOT mean that one can't define an extension to sip outside of IETF and use it (that is covered by tsvchange). This requirement does say that such an extension could not be *required* by clients, and it cannot be indicated as being explicitly supported (which would allow servers to require it). These words about Require and Supported come from IESG, and they are based on bad experiences with protocols in the past that did not have such restrictions. Specifically, a protocol in the past allowed for mandatory vendor specific extensions. This was abused by a large vendor, whose servers always required support of their extensions from clients. That vendor was able to call their product compliant to the spec. What we are hoping to avoid is similar problems with SIP. You can't force someone to only put standards-track tags in Require/Supported, but if they do, you can at least publically state that it is not compliant to the specification. Since this issue is really independent of tsv-change, there is no need to reference tsv-change at all, and I have no plans to do so. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Last Call comments on 2543bis-07 William Marshall
- Re: [Sip] Last Call comments on 2543bis-07 Jonathan Rosenberg
- Re: [Sip] Last Call comments on 2543bis-07 Robert Sparks
- Re: [Sip] Last Call comments on 2543bis-07 Henning Schulzrinne
- Re: [Sip] Last Call comments on 2543bis-07 William Marshall
- Re: [Sip] Last Call comments on 2543bis-07 Henning Schulzrinne
- RE: [Sip] Last Call comments on 2543bis-07 Rosen, Brian
- RE: [Sip] Last Call comments on 2543bis-07 William Marshall
- RE: [Sip] Last Call comments on 2543bis-07 Scott Bradner
- Re: [Sip] Last Call comments on 2543bis-07 Allison Mankin
- Re: [Sip] Last Call comments on 2543bis-07 Henning Schulzrinne
- Re: [Sip] Last Call comments on 2543bis-07 Jonathan Rosenberg
- Re: [Sip] Last Call comments on 2543bis-07 Jonathan Rosenberg
- RE: [Sip] Last Call comments on 2543bis-07 Tom-PT Taylor
- RE: [Sip] Last Call comments on 2543bis-07 Scott Bradner
- Re: [Sip] Last Call comments on 2543bis-07 William Marshall
- Re: [Sip] Last Call comments on 2543bis-07 William Marshall
- Re: [Sip] Last Call comments on 2543bis-07 Robert Sparks
- RE: [Sip] Last Call comments on 2543bis-07 Drage, Keith (Keith)
- Re: [Sip] Last Call comments on 2543bis-07 William Marshall
- tsvchange and Supported/Require, was: [Sip] Last … Jonathan Rosenberg