RE: draft-rfc-image-files-00.txt

[John C Klensin <john-ietf at jck.com>]

Michael,

Please remember the following minor issues:

(1) xml2rfc may be widely used, but it is not a requirement or a
standard.  It actually has no formal status in the IETF.  Even
the informational RFC that describes it is long out of date.
All of that is reasonable for the way it is being used today,
but is not consistent with your proposal.

(2) People do prepare I-Ds and input to the RFC Editor in other
ways.  Plain ASCII text prepared with an editor, nroff, and,
using other sets of tools, MS Word are all in use and there may
be others that I don't know about.  The specification in the
image file document are compatible with all of these as well as
with xml2rfc (plus or minus some changes or post-processing).

(3) While one can debate it at length --and we, no doubt, will
have to do that-- the other graphic and specification mechanisms
you cite do not have either the track record or external
acceptance to make a reasonable guarantee of long-term stability.

   john
 

--On Tuesday, 26 August, 2008 17:30 +0100 michael.dillon at bt.com
wrote:

>> On first reading this seems to be an interesting way to go.
> 
> It seems to be heading in the right general direction, but 
> I wonder why it does not concentrate on specifying inputs
> rather than outputs. Given that XML is now widely used as the
> input format for RFCs, it seems worthwhile to review the bits
> of XML-related stuff that are mature enough for use for
> writers.
> 
> For instance, SVG for diagrams and PNG for images, standard
> CSS for tables.
> 
> Of course, there has to be a defined standard reporitory output
> for "publishing" the RFCs, but that already seems to be PS/PDF.
> If the IETF defines a standard input format, and the XML2RFC
> toolset is updated to support that tFrom ietf-bounces at ietf.org  Tue Aug 26 09:45:12 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 422063A6A7B;
	Tue, 26 Aug 2008 09:45:11 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8048B3A6935
	for <ietf at core3.amsl.com>; Tue, 26 Aug 2008 09:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Level: 
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, 
	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 qXOZzivO1+ps for <ietf at core3.amsl.com>;
	Tue, 26 Aug 2008 09:45:06 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211])
	by core3.amsl.com (Postfix) with ESMTP id BA6933A6A7B
	for <ietf at ietf.org>; Tue, 26 Aug 2008 09:45:05 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1KY1fF-000CuC-Cm; Tue, 26 Aug 2008 12:45:05 -0400
Date: Tue, 26 Aug 2008 12:45:04 -0400
From: John C Klensin <john-ietf at jck.com>
To: michael.dillon at bt.com, ietf at ietf.org
Subject: RE: draft-rfc-image-files-00.txt
Message-ID: <B9072265A7B1BE6E735B55D4 at p3.JCK.COM>
In-Reply-To: <C0F2465B4F386241A58321C884AC7ECC07BBFC39 at E03MVZ2-UKDY.domain1.systemhost.net>
References: <C0F2465B4F386241A58321C884AC7ECC07BBFC39 at E03MVZ2-UKDY.domain1.systemhost.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-BeenThere: ietf at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Michael,

Please remember the following minor issues:

(1) xml2rfc may be widely used, but it is not a requirement or a
standard.  It actually has no formal status in the IETF.  Even
the informational RFC that describes it is long out of date.
All of that is reasonable for the way it is being used today,
but is not consistent with your proposal.

(2) People do prepare I-Ds and input to the RFC Editor in other
ways.  Plain ASCII text prepared with an editor, nroff, and,
using other sets of tools, MS Word are all in use and there may
be others that I don't know about.  The specification in the
image file document are compatible with all of these as well as
with xml2rfc (plus or minus some changes or post-processing).

(3) While one can debate it at length --and we, no doubt, will
have to do that-- the other graphic and specification mechanisms
you cite do not have either the track record or external
acceptance to make a reasonable guarantee of long-term stability.

   john
 

--On Tuesday, 26 August, 2008 17:30 +0100 michael.dillon at bt.com
wrote:

>> On first reading this seems to be an interesting way to go.
> 
> It seems to be heading in the right general direction, but 
> I wonder why it does not concentrate on specifying inputs
> rather than outputs. Given that XML is now widely used as the
> input format for RFCs, it seems worthwhile to review the bits
> of XML-related stuff that are mature enough for use for
> writers.
> 
> For instance, SVG for diagrams and PNG for images, standard
> CSS for tables.
> 
> Of course, there has to be a defined standard reporitory output
> for "publishing" the RFCs, but that already seems to be PS/PDF.
> If the IETF defines a standard input format, and the XML2RFC
> toolset is updated to support that toolset aoolset and output PS/PDF
> format for the repository, then that takes care of the format
> issue. Then there is only one file, not two or three. And the
> toolset could feasibly generate a text file plus PS/PDF images
> only format, as an alternate output if that is desired. Or SWF
> output files, or TGZ file with a folder containing HTML and
> separate files for each SVG diagram or PNG image. No need to
> choose, just prioritise.
> 
> Stylistic issues are quite separate, although they should
> probably also be specified up front if it keeps things more
> orderly. I'd suggest avoiding numbering images/diagrams in
> favor of naming them. E.g. see diagram former-state-machine or
> refer to image original-napkin-notes.
> 
> --Michael Dillon
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf




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


nd output PS/PDF
> format for the repository, then that takes care of the format
> issue. Then there is only one file, not two or three. And the
> toolset could feasibly generate a text file plus PS/PDF images
> only format, as an alternate output if that is desired. Or SWF
> output files, or TGZ file with a folder containing HTML and
> separate files for each SVG diagram or PNG image. No need to
> choose, just prioritise.
> 
> Stylistic issues are quite separate, although they should
> probably also be specified up front if it keeps things more
> orderly. I'd suggest avoiding numbering images/diagrams in
> favor of naming them. E.g. see diagram former-state-machine or
> refer to image original-napkin-notes.
> 
> --Michael Dillon
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf




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