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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of David B Harrington Sent: Saturday, January 07, 2006 9:33 AM To: 'John C Klensin'; 'Marshall Eubanks' Cc: ietf@xxxxxxxx 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@xxxxxxxxxxx > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of John C Klensin > Sent: Monday, January 02, 2006 3:37 PM > To: Marshall Eubanks > Cc: ietf@xxxxxxxx > Subject: Re: Alternative formats for IDs > > Marshall, > > --On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks > <tme@xxxxxxxxxxxxxxxxx> 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf