So, the problem you are citing is the issue that you want to harvest data
out of the ID or RFC. That's common now, and getting more common. You then
immediately move to say ASCII is the right output format because it makes
harvesting the data you want easy.
Well, probably not as easy as publishing the ID/RFC in some way that is
designed to make harvesting of the data within it easy. Say, xml (2629 and
follow ons).
I believe this issue has been raised before, but we have three uses for the
ID and RFC files: we read them, we harvest data from them and we archive
them (RFCs anyway) for later use.
Any format can be used for any purpose, but it might be time to fully stand
up to requirements to harvest data, and to recognize (as I did on another
side thread), that reading is getting harder and harder for ASCII. It may
be a decent archive format still, but I'm not sure it's going to stay that
way.
Of course, if you have three different uses, and you end up with more than
one format to satisfy all of your requirements, then you have the
"normative" problem. I really think some of you wave that particular flag a
bit too strongly, but I think that most of us would be okay with publishing
in multiple formats, including ASCII (for now), and even with saying that
the ASCII text is the normative one, if and when there is any difference
that matters between the formats.
I think publishing the xml for harvesting really is the best thing we can
do. If we do, we may want some more work done to make more harvesting
possible. The schema now is really organized around readability. This
probably has less to do with defining new tags than in using some metadata
to mark things like ABNF, code, MIBs and the like.
I am a proponent of PDF output format; I find it very useful for reading. I
have had very few problems with PDF, fewer than with ASCII these days. I am
also pretty pleased with HTML as the current tool (xml2rfc) creates.
That would mean the the I-D editor and the RFC editor uses xml2rfc, we
publish the xml, the ASCII and possibly PDF and/or html from the xml. If
you want, the ASCII can be normative. That also implies the desired input
format is xml. We can discuss if we want the RFC editor to accept something
else and bear the burden of converting to xml.
I've heard the RFC editor has tried using xml and xml2rfc and is not
satisfied with the results as far as creating ASCII versions of RFC text.
It would be interesting to hear what problems they have seen.
Brian
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
David B Harrington
Sent: Saturday, January 07, 2006 9:33 AM
To: 'John C Klensin'; 'Marshall Eubanks'
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: Alternative formats for IDs
Hi,
As a MIB Doctor and chair of the Bridge WG, I have been working with
the IEEE 802.1 WG, who will assume maintenance responsiblities for the
Bridge WG Mib modules.
IEEE 802.1 publishes their standards in PDF. We had to make a special
request that they make the MIB portion of their documents available in
ASCII format, partly so, as part of the transition process, IETF MIB
Doctors could review their documents (e.g., running the MIB module
through smilint and other compilers), but also so the MIB modules
could be extracted for importing into network management applications,
such as NET-SNMP and HP OvenView.
A similar issue will exist for documents that contain code snippets.
While I personally like PDF for many things, I find PDF to be a poor
choice for IETF works-in-progress, or even for RFCs because they lack
many of the characteristics that ASCII files offer.
David Harrington
dbharrington(_at_)comcast(_dot_)net
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of John C Klensin
Sent: Monday, January 02, 2006 3:37 PM
To: Marshall Eubanks
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Alternative formats for IDs
Marshall,
--On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks
<tme(_at_)multicasttech(_dot_)com> wrote:
...
The project, currently referred to as PDF/A, will address
the growing need to electronically
archive documents in a way that will ensure preservation of
their contents over an extended period of
time, and will further ensure that those documents will be
able to be retrieved and rendered with a
^^^^^^^^^^^^^^^^^^^^^^
consistent and predictable result in the future. This need
exists in a growing number of international
government and industry segments, including legal systems,
libraries, newspapers, regulated industries, and others.
The work will address the use of PDF for multi-page
documents that may contain a mixture of
text, raster images and vector graphics. It will also address
the features and requirements that must be
supported by reading devices that will be used to retrieve and
render the archived documents.
^^^^^^
Emphasis added, of course.
As I have understood it, PDF/A is intended as an archival format
for the sorts of documents that exist on paper, with a primary
goal of being able to render things that look just like the
paper looked like. It has not been a requirement that PDF/A
support extraction of text, editing, insertion of new materials,
and other forms of markup. Indeed, some of the participants in
the PDF/A effort might consider support for some of those things
to be liabilities. Your note reinforces that impression.
As such, it is (IMO, barely) possible that PDF/A would be a
reasonable format for storing archival documents such as RFCs.
But it would be a terrible format for working documents such as
I-Ds, for the reasons discussed in my earlier note.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf