Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt

Dean Willis <dean.willis@softarmor.com> Thu, 28 February 2008 18:23 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618023A6EE2; Thu, 28 Feb 2008 10:23:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.01
X-Spam-Level:
X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-jKhKxr4+7v; Thu, 28 Feb 2008 10:23:53 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E36728C983; Thu, 28 Feb 2008 10:21:39 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC263A6A3A for <sip@core3.amsl.com>; Thu, 28 Feb 2008 10:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKPH9PU-M1xR for <sip@core3.amsl.com>; Thu, 28 Feb 2008 10:21:37 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 48DC228CA91 for <sip@ietf.org>; Thu, 28 Feb 2008 10:20:34 -0800 (PST)
Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id m1SIKLig015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2008 12:20:23 -0600
Message-ID: <47C6FB5F.8090209@softarmor.com>
Date: Thu, 28 Feb 2008 12:20:15 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Icedove 1.5.0.14pre (X11/20080208)
MIME-Version: 1.0
To: "James M. Polk" <jmpolk@cisco.com>
References: <20080224054501.90B6A3A6A07@core3.amsl.com> <200802250404.m1P44eZm023626@dragon.ariadne.com> <XFE-SJC-212GpaoG1VR00004ef4@xfe-sjc-212.amer.cisco.com>
In-Reply-To: <XFE-SJC-212GpaoG1VR00004ef4@xfe-sjc-212.amer.cisco.com>
X-Enigmail-Version: 0.94.2.0
Cc: sip@ietf.org
Subject: Re: [Sip] I-D Action:draft-ietf-sip-rph-new-namespaces-02.txt
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

James M. Polk wrote:
>
>>    Abstract:
>>
>>    This document creates additional Session Initiation Protocol
>>    Resource-Priority namespaces, and places these namespaces in the
>>    IANA register.
>>
>> As an editorial matter, can the abstract be made less vague?  Such as
>> mentioning that it creates a set of namespaces for the use of the US
>> Defense Information Systems Agency...
> 
> well, at least I didn't overstate things...  ;-)
> 
> I can change this if you want me to

Since I personally only read the abstract of new drafts and extrapolate
all further content (including any errors) by intuitive deduction, I'm
sure that a more detailed abstract would be helpful. ;-)

Seriously, a well-written abstract is a big help for people who haven't
been reading along with the development. Many students I've talked to
start with the abstract, and then use that to decide how the RFC fits
into the mental framework they're building as they try to come to grips
with the documentation-kraken that SIP has become.

We should be careful to make our abstracts as useful for this sort of
thing as we can. That means that the abstract needs to tell us what the
draft is about well enough to fit it into a framework, but not tell us
much about the implementation detail. Admittedly, it is a fine balancing
act -- but I'm afraid the abstract for the draft in question hasn't even
stepped up to the high-wire, much less maintained its balance.

--
dean

_______________________________________________
Sip mailing list  https://www.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