Subject: RE: Alternative formats for IDs

From: [email-masked] (Noel Chiappa)
Date: Mon, 2 Jan 2006 15:24:35 -0500 (EST)

> From: John C Klensin <[email-masked]>

    > the state of online collaboration and editing that we have been at for
    > 20 or 30 years.
    > Finally, there is a longstanding and more or less explicit decision in
    > the IETF community to keep the costs of participation as low as possible

There's one other thing, also tied to the IETF (and its predecessor's) long
existence, which is the long-term accessability of online documents - again,
another facet in which our experience is pretty unique. Is MS-Word (or
anything else) going to be 30 years from now?

In case you think this is a silly question, I just recently finished scanning
/ OCR'ing / proofing the oft-cited IEN-19 (Shoch, "Inter-Network Naming,
Addressing, and Routing"), from January 1978 - 28 years ago. The original of
this document was presumably in some Bravo format, and the printing version
was in PRESS - and I somehow doubt either is supported anywhere in the world
now. I only had a hardcopy, so the question's a bit moot, but I very much
doubt a machine-readable version of either form would have done me much good.

ASCII may be pretty lobotomized, but it *is* timeless.

(Not that I'm per-se against allowing more powerful forms, mind, but any
proprietary option is just not viable, IMO.)

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 2 Jan 2006 16:03:54 -0500

Dear Noel et al;

I trust that the whole IETF community  will have a Happy New Year.

> doubt a machine-readable version of either form would have done me  

"Don't re-invent the wheel" is I think generally a good engineering  
principle. In this case, there
are a number of entities that are interested in long term archival   
storage of electronic documents; I think that the IETF should use   
their expertise and experience.

It seems that the library community has settled on PDF as its long  
term storage choice, and  is
moving to standardize this.

 From Harvard University's Report to the Digital Library Federation,  
October, 2004 :
http://www.diglib.org/pubs/news05_01/harvardnews5.htm

PDF/A

Adobe's Portable Document Format (PDF) has become the de-facto  
standard for web-based delivery of electronic documents. The  
International Organization for Standardization (ISO) has initiated an  
effort to create an standard for an archival profile of PDF that is  
amendable for long-term preservation. This standard, PDF/A, is  
intended to provide an unambiguous definition of the requirements  
necessary for the reliable and predictable future rendering of  
archived PDF documents. The second draft of the PDF/A standard was  
released in May 2004 and is currently undergoing a comment period by  
experts from the constituent national bodies of ISO. Stephen Abrams,  
the LDI Digital Library Program Manager at Harvard University, is the  
project leader and document editor for the ISO PDF/A joint working  
group.

-----

The next ISO meeting  on this is january 25-26 in Berlin, Germany

http://www.aiim.org/standards.asp?ID=25013

Here is the PR announcing the  project :

  A new joint activity has been initiated between NPES The  
Association for Suppliers of
Printing, Publishing and Converting Technologies, and the Association  
for Information and Image
Management, International (AIIM International) to develop an  
International standard that defines the
use of the Portable Document Format (PDF) for archiving and  
preserving documents.

  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.

  This joint committee formed under AIIM and NPES will identify  
issues to be addressed, as
well as proposed solutions, and will develop a draft document that  
will then be presented to a Joint
Working Group of the International Organization for Standardization  
(ISO) for development and
approval as an International Standard.

-----
The Library of Congress has set up a web site devoted to this issue,
http://www.digitalpreservation.gov/ ,
which lists all of the formats being considered at

http://www.digitalpreservation.gov/formats/fdd/descriptions.shtml

and the ones specifically for text at
http://www.digitalpreservation.gov/formats/fdd/text_fdd.shtml

these being

DTB, Digital Talking Book
OEBPS_1_0, Open eBook Forum Publication Structure 1.0.1
OEBPS_1_2, Open eBook Forum Publication Structure 1.2
NCBIArch_1, NCBI/NLM Journal Archiving and Interchange DTD, version 1
NITF, News Industry Text Format

PDF, Portable Document Format
PDF_1_4, PDF, Versions 1.0-1.4
PDF_1_5, PDF, Version 1.5
PDF/A, PDF for Preservation
PDF/X, PDF for Prepress Graphics File Interchange

XML

with PDF/A  being further described at : http:// 
www.digitalpreservation.gov/formats/fdd/fdd000125.shtml

(Note : There is of course wording that says that "Inclusion of a  
format does not imply that it is preferred or acceptable for Library  
of Congress collections. Conversely, omission of a format from the  
list does not imply that it is not preferred or acceptable.  
Descriptions will be drafted and added over time.")

-----

My personal conclusion is

- I am in favor of moving beyond ASCII only.
- I am against using any non-standardized format, such as Word
- If there was a proposal to use PDF/A as standardized, I would  
support it.

Regards
Marshall Eubanks

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jan 2006 16:36:33 -0500

Marshall,

--On Monday, 02 January, 2006 16:03 -0500 Marshall Eubanks
<[email-masked]> 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

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Jan 2006 13:46:57 -0800 (PST)

> Lets go ahead and ask then -

>   Does anyone else think that IETF should allow documents which
>   format/structure is not publicly known as one of the ways to
>   distribute IETF specifications?

For the record, my answer is "absolutely not".

> And why do all the other SDOs get along with non-ASCII formats?
> On my intranet I have a list of 120+ SDOs in the communications
> and computer-science fields, and although I haven't gone through
> them all (I have asked someone to do so) I haven't found another
> group that uses ASCII files.

First off, there's a big difference between using, say, an appropriately
constrained subset of HTML and using MS Word. Both may be non-ASCII, but one is
publicly specified whereas the other is not.

Second, your assumption that other SDOs have been able to blissfully make use
of private formats like MS Word without incident is simply untrue. One obvious
counterexample I know of is the CCITT/ITU, which has in the past used MS Word
as a distribution format for many of it's documents. I have quite a few of
these documents on hand and occasionally need to refer to old versions of them,
but when I try and read them using modern tools the results are rarely good.
Many of these documents simply refuse to open, sometimes crashing the tool I'm
using, while others do open but are misformatted, sometimes to the point of
being illegible.

Like it or not, compatibility with future versions is just not something you
can count on. Of course this is also true with formats whose specifications are
public, but at least with those you have the option of writing something to the
specification that will read the stuff.

>     > the IETF community to keep the costs of participation as low as possible

Quite true. I don't like thinking about how much $$$ I've spent trying to deal
with proprietary formats of one sort or another.

> anything else) going to be 30 years from now?

Not if the past is any indicator.

> Addressing, and Routing"), from January 1978 - 28 years ago.

Access to old versions of specifications is often quite important. Even if you
ignore the frequent direct use of such specifications, it is not at all
uncommon for a modern RFC to have normative references to other RFCs written 25
years or more ago.

It is also worth noting that access to old drafts can be quite useful. And this
isn't confined to the IETF. To use the CCITT/ITU as an example again, back in
the day there was a widely used X.400 body part format that was only ever
specified in a particular draft of ISO 10021. (It never appears in any ITU
version of the specification, draft or otherwise.) You either had to have a
copy of this draft or you were reduced to dumping the ASN.1 and guessing what
the various fields were.

> The original of

Well, I don't know about PRESS specifically, but I have a book describing the
Interpress format in a fair amount of detail. If it is the same it might
actually be possible to process it, probably most easily by converting it to
PostScript (which in many ways is it's descendant). So once again, it's all
about whether or not the details of the format are public.

> ASCII may be pretty lobotomized, but it *is* timeless.

Or as close to it as we can reasonably get.

> proprietary option is just not viable, IMO.)

I completely agree.

				Ned

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Jan 2006 23:59:30 -0500

On Monday, January 02, 2006 04:03:54 PM -0500 Marshall Eubanks 
<[email-masked]> wrote:

> It seems that the library community has settled on PDF as its long  term
> storage choice, and  is
> Adobe's Portable Document Format (PDF) has become the de-facto  standard
> for web-based delivery of electronic documents. The  International
> Organization for Standardization (ISO) has initiated an  effort to create
> an standard for an archival profile of PDF that is  amendable for
> long-term preservation. This standard, PDF/A, is  intended to provide an
> unambiguous definition of the requirements  necessary for the reliable
> and predictable future rendering of  archived PDF documents. The second
> draft of the PDF/A standard was  released in May 2004 and is currently
> undergoing a comment period by  experts from the constituent national
> bodies of ISO. Stephen Abrams,  the LDI Digital Library Program Manager
> at Harvard University, is the  project leader and document editor for the
> ISO PDF/A joint working  group.

I think you're drawing too many conclusions from that report.
The report you quoted comes from the newsletter of a small consortium of 
libraries focused specifically on "digital library" issues, which largely 
(though not entirely) consists of storing, handling, and making available 
digital representations of traditional-format works.  It _may_ represent 
the consensus of that small consortium, but there is no evidence to 
indicate that it represents the opinion of librarians at large -- most of 
whom have no more expertise than we in the management and storage of data.

Further, the article does not say that the library community or the DLF has 
settled on PDF as its long-term storage format, or that it is moving to 
standardize it.  What it does say is:

- PDF has become the de-facto standard for _delivery_ of documents.
  This is arguably true, at least for the sort of documents they're
  interested in, and for cases where reproducing the precise appearance
  of a document is considered important.

- The ISO (not the library community) has initiated an effort to produce
  a standard profile of PDF suitable for archival use (_not_ an effort to
  cause any particular community to adopt such a format).

I agree that it is desirable to avoid gratuitously re-inventing the wheel. 
I don't think anyone here has suggested developing a new document format at 
all, let alone one specifically for IETF documents.  Several people have 
suggested adopting particular existing formats, but that is not 
re-inventing the wheel.  And those who have made the "archival format" 
argument most strenuously have also argued for retaining the current 7-bit 
ASCII format, a wheel which has been around for considerably longer than 
PDF/A.

The IETF has thrived for many years using a document format which is easy 
to produce, view, and edit on virtually any platform, and easy to 
distribute via virtually any means.  I'm not saying there is no room for 
change, but any new format needs to do reasonably well with respect to both 
of these properties -- only having one is _not_ sufficient.

Oh, one more thing.  The most widely-used archival form in use at libraries 
I've visited has been written or printed words on paper.  This form has 
much going for it -- it can represent any character set humans have ever 
used, can contain any diagram, and does not require any special software to 
to view or produce.  Editing is a bit of a pain, though, and its damned 
inconvenient to distribute, so this is probably not the best document 
format for the IETF.

But as John points out, it is what most other SDO's have been using. 
Sometimes being different doesn't mean you're wrong, just that you're ahead 
of your time.

-- Jeff

---

From: "David B Harrington" <[email-masked]>
Date: Sat, 7 Jan 2006 08:32:39 -0600

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
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of John C Klensin
> Sent: Monday, January 02, 2006 3:37 PM
> To: Marshall Eubanks
> Cc: [email-masked]
> Subject: Re: Alternative formats for IDs
> 
> Marshall,
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 7 Jan 2006 15:18:08 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
David B Harrington
Sent: Saturday, January 07, 2006 9:33 AM
To: 'John C Klensin'; 'Marshall Eubanks'
Cc: [email-masked]
Subject: RE: Alternative formats for IDs

Hi,

David Harrington
[email-masked]

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 9 Jan 2006 23:37:06 -0500

> be a decent archive format still, but I'm not sure it's going to stay that

Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
be fed into MIB compiler, or reference C code for algorithms like MD5
(RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers and
MIB compilers still use ASCII text as input, and not Word documents or
XML documents.  Maybe part of what is going on is that IETF is getting
populated with people who aren't close to coding as much as before?
You can get perfectly decent text editors for all operating systems,
even Windows.

And even Word can import text (i.e., plain ASCII) documents Just Fine.

							- Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 08:09:10 -0500

It's trivial for a human, but not for a computer.
Many things trivial for humans are not trivial for computers.

The kind of harvesting you are talking about is trivial for a human from any
format as long as your editor can paste while losing formatting.

What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code.  You can't
do that with plain ASCII.

Your statement that the IETF is getting populated with people who don't code
is true.  It's a fact, and we need to adapt.  Most (but not all) of the
people who design protocols these days don't code; they have people who work
with them who do.  Part of that is unavoidable.  The part I regret, which
could be avoided, is the loss of "running code" that we used to care about.
Another thread.

Brian

-----Original Message-----
From: Theodore Ts'o [mailto:[email-masked]] 
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: [email-masked]; 'John C Klensin'; 'Marshall Eubanks'; [email-masked]
Subject: Re: Alternative formats for IDs

							- Ted

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 10 Jan 2006 08:50:07 -0500

Hi,

> do that with plain ASCII.

MIB modules may be a bad example for you to use. All MIB modules start
with a BEGIN character string and end with an END character string.
Plain ASCII works perfectly well for this purpose. Binary formatted
documents, such as MS-Word and PDF, require much more work from the
tools  to find those BEGIN and END statements.

David Harrington
[email-masked]

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, January 10, 2006 8:09 AM
> To: 'Theodore Ts'o'
> > Any format can be used for any purpose, but it might be 
> time to fully
> stand

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 10 Jan 2006 08:58:18 -0500

> do that with plain ASCII.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.00001%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

						- Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2006 14:52:59 +0100

...
> do that with plain ASCII.

You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction than anything visual such as
using multiple fonts.

<code>...</code>

     Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 09:45:41 -0500

Ted

You are arguing that we have been producing documents for a long time with
only primitive tools and we don't need to make any new tools.  You are
losing that argument.   We are increasing the number, and usefulness of
tools, and most of us appreciate these tools and want more of them.  The
range of useful tools we can produce is related to how much meta-data we put
in the source files.  The more meta-data we put in, the more usefulness we
can get out of the data.  There is very little downside to adding meta-data
as long as it's easy to put in.  For most of these things, we have to do
special formatting, so we are already marking the octets in some way.  

Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
if a document has a MIB unless you actually look at the text (although many
have a big hint in the title of the document).  So yes, I believe better MIB
tools would lead to better products, although it would be hard to prove it.

I would like to enable automated testing of ABNF.  I'd like to be able to
cross check the ABNF from one document against its normative references to
see what changes or conflicts.  I'd like to be able to generate a complete
list of SIP error messages a UA may be expected to encounter.  I'd like to
see a lot more hyperlinking of things.  All of these are much easier with
meta-data.

Brian

-----Original Message-----
From: Theodore Ts'o [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: [email-masked]; 'John C Klensin'; 'Marshall Eubanks'; [email-masked]
Subject: Re: Alternative formats for IDs

						- Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 08:57:24 -0500

<sorry, couldn't help it>
You mean, like xml?

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, January 10, 2006 8:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Alternative formats for IDs

...

<code>...</code>

     Brian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jan 2006 08:15:02 -0800

>tools would lead to better products, although it would be hard to prove it.

Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.

As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT <url>". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.

>see a lot more hyperlinking of things.  All of these are much easier with

Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Randy.Dunlap" <[email-masked]>
Date: Tue, 10 Jan 2006 08:31:48 -0800 (PST)

> would work better for automated extraction than anything visual such as

Does the RFC editor accept HTML in plain ASCII RFCs?

-- 
~Randy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 11 Jan 2006 01:53:10 +0100

Paul Hoffman wrote:

> If any of those features came free or very cheap, that
> would be great.

JFTR:  The last xml2rfc version under test (pre3) supported
to validate ABNF on the fly for <artwork type="abnf"> if the
source asks for "strict" processing.

                         Bye, Frank

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 10 Jan 2006 20:13:35 -0500

I'd mostly agree if this was a one off, but it's not; it requires continuous
effort to maintain.  My experience that manual is usually cheapest if it
only has to be done once, and automation is cheapest if it has to be
continuously maintained.  YMMV.

Most of the harvesting of sections of things that are now text that could be
harvested apply to RFCs and not IDs, but things like ABNF checking and even
MIB checking could be part of ID nits.  Hyperlinks apply to both.

There are many ways to put meta-data in files, but I'd rather not invent a
new one.  xml is just fine, thank you.  And we have a nice tool that puts
out text and html, and with a small amount of effort, PDF from xml.  Our
reluctance to use it is mostly:
	The RFC editor has some problems which have not, to my knowledge,
been	enumerated.

	There are currently other ways to produce ASCII output that people
are
	reluctant to give up on.

I suspect we can fix the former.  The question is whether the usefulness of
the harvesting and alternative outputs outweighs the latter, assuming we
accept ASCII output as required and normative.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: [email-masked]
Subject: RE: Alternative formats for IDs

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jan 2006 13:51:11 +0100

> Does the RFC editor accept HTML in plain ASCII RFCs?

They accept ASCII. <code> looks like ASCII to me.
Actually <html> looks like ASCII too :-)

Seriously. If we want to embed metatdata tags in RFCs, we can just do it.

    Brian

    Brian

---

From: Bill Fenner <[email-masked]>
Date: Thu, 12 Jan 2006 09:26:34 -0500

On 1/10/06, Paul Hoffman <[email-masked]> wrote:
> repository that is machine-accessible?

Something like http://www.icir.org/fenner/mibs/mib-index.html and
http://www.icir.org/fenner/mibs/extracted/ ?

  Bill

---

From: Pekka Savola <[email-masked]>
Date: Sun, 15 Jan 2006 19:39:30 +0200 (EET)

> http://www.icir.org/fenner/mibs/extracted/ ?

Now, if there just was somekind of a visual MIB browser on a website 
[1], I'd be very happy.  Maybe something the Tools team could 
investigate...

[1] Based on quick google search, something a bit like:
http://www.freedownloadscenter.com/Network_and_Internet/Network_Management_Tools/Visual_MIBrowser_Pro.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings