Re: Call for review of proposed update to ID-Checklist

John C Klensin <john-ietf@jck.com> Sun, 10 August 2008 23:32 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D223A687C; Sun, 10 Aug 2008 16:32:25 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FAE13A6824 for <ietf@core3.amsl.com>; Sun, 10 Aug 2008 16:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 D7pXGVHtqYRy for <ietf@core3.amsl.com>; Sun, 10 Aug 2008 16:32:23 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 224CA3A67EF for <ietf@ietf.org>; Sun, 10 Aug 2008 16:32:23 -0700 (PDT)
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1KSKOd-000Gcl-HQ; Sun, 10 Aug 2008 19:32:23 -0400
Date: Sun, 10 Aug 2008 19:32:18 -0400
From: John C Klensin <john-ietf@jck.com>
To: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <35F80F2ACF41F0D3E8EA9DA1@[192.168.1.110]>
In-Reply-To: <489F114F.2020803@gmx.de>
References: <34A11819D6D4490CA56321EC26704A32@BertLaptop> <p06240825c4c4b714140f@[165.227.249.203]> <489F114F.2020803@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke 
<julian.reschke@gmx.de> wrote:

> Hi,
>
> things I'd like to see done in IDs more consistently:
>
> In an Editorial Note on the front page:
>
> - state on which mailing list discussions should take place
> (include mailing list archive and subscription links)
>
> - point to issues lists when available
>
>
> References:
>
> - check that if the document obsoletes or updates another
> document, that one appear in the references section, and make
> sure that the document actually says what's going on with
> respect to the other documents (such as "Normative Changes
> from RFC xxxx")

Of course, if one does this, the automated nits checker 
complains about a reference to an obsolete RFC :-(

> - use symbolic references

The RFC Editor is still flexible about this, IMO for good 
reason.   It should not be the prerogative of this document, or 
even the IESG, to change the preference to a rule.

>...
> Code:
>
> - when using xml2rfc, add type parameters to artwork so that
> things like ABNF can be automatically extracted and checked

FWIW, I continue to believe, based on experience with a few 
fairly large and complex documents (most recently rfc2821bis) 
that the xml2rfc approach of treating ABNF as a special type of 
artwork is seriously broken for at least two reasons:

    (1) It effectively forces the author to do formatting on a
    line by line basis, which is not what generic markup is
    supposed to be all about and is pathological for
    pretty-print applications (including HTML and Postscript
    output) because it prevents taking advantage of different
    line length and wrapping options.  That problem gets more
    severe if productions extend over several lines and/or
    contain comments.

    (2) It prevents indexing and use of XML elements to identify
    and organize portions of the ABNF (e.g., distinguishing rule
    names (LHS) from definitions (RHS) and comments).

For both of these, use of hanging <list> elements can actually 
work better than the artwork model even those that option has 
more than its share of disadvantages as well.

While I understand that this is a sufficiently large change to 
xml2rfc that I should not hold my breath, I think it would be 
very unfortunate to use the Checklist and/or its automatic 
instantiation to aggressively push a sometimes-unfortunate 
practice.

> Versioning:
>
> - (this probably is controversial :-) - keep an appendix that
> gives a short overview of what changed compared to previous
> drafts

Yep, it is controversial.   Good idea sometimes, bad idea 
others, hence probably a poor checklist guideline beyond, 
perhaps, "please consider keeping...".

best,
   john

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf