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