Subject: RE: Plenary decision?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jul 2003 16:14:23 -0700

> As I said, I can't remember a time when the people
> present who went up to mike to defend ASCII numbered less than at
> least 3 times number of people who wanted to use some propietary
> (i.e., MS Word) or non-editable (i.e., Postscript) formats.

This is a straw man. HTML is a completely open format.

If you use XHTML and define the schema appropriately you can 
easily verify that no proprietary extensions have been used.

Alternatively there are plenty of tools to verify against a DTD.

		Phill

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Jul 2003 18:57:32 +0200

Phillip,

Like most things, what matters is the detail.  Feel free to put together
a formal specification of the formatting rules to be following,
including character sets, format control constructs, etc.  Since you say
that all the necessary stuff already exists and is readily available,
I'm sure your specification document will be quite short.

However, in case you have not noticed, "HTML" is an ambiguous reference.  Clearly
anything specified for IETF documents must be precise and easily usable
by the broadest audience possible.  This includes text searchable, of
course.

In order to ensure ease of adoption and use, you should also consider
including citations to the open tools that are readily available, for
generating conformant documents, as well as tools for any other support
functions that will make users happy with it.

Until then, this debate is like so many other technical discussions in
the IETF, where folks debate concepts, utterly ignoring the concrete
details and minor matters of usability.

d/

ps. Folks, until we see a specification for an alternative format, could
we please constrain discussion of this topic to a recitation of the
requirements. Having to repeat this debate every few years seems rather
wasteful.

HBP> This is a straw man. HTML is a completely open format.

HBP> If you use XHTML and define the schema appropriately you can 
HBP> easily verify that no proprietary extensions have been used.

HBP> Alternatively there are plenty of tools to verify against a DTD.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Jul 2003 14:18:50 -0400

] Like most things, what matters is the detail.  Feel free to put together
] a formal specification of the formatting rules to be following,
] including character sets, format control constructs, etc.  Since you say
] that all the necessary stuff already exists and is readily available,
] I'm sure your specification document will be quite short.

http://www.cs.utk.edu/~moore/opinions/whether-rfcs-in-html.html

---

From: Thomas Narten <[email-masked]>
Date: Sun, 13 Jul 2003 08:56:03 +0200

Another document folk interested in this topic might want to review is
is:

http://www.cs.columbia.edu/~hgs/tmp/rfc.txt

Internet Engineering Task Force
Internet Draft                                               Schulzrinne
schulzrinne-rfc-00.txt                                       Columbia U.
September 3, 2000
Expires: January 2001

    Suggestions for Future Document Format Requirements for RFCs and
                            Internet Drafts

Abstract

   A dwindling fraction of authors of I-Ds and RFCs are still fluent in
   nroff, the official input format for RFCs. With the use of other
   tools, the consistency and layout quality of RFCs and I-Ds has
   suffered.  Printing, hyperlinking and viewing of ASCII documents are
   unsatisfactory. In this document, we investigate how the I-D and RFC
   series can be upgraded in usability while maintaining stability,
   longevity and cross-platform abilities that have been hallmarks of
   the RFC series.

6 Acknowledgements

   This document attempts to summarize the discussion on the IAB, wg-
   chairs and IESG mailing lists that took place during August 2000. Any
   misrepresentations are the fault of the author.