LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: Re: Machine-parsable specifications from RFCs; RFC errors
From: "Donald E. Eastlake 3rd" <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Fri, 17 Nov 95 12:18:54 EST

text/plain (66 lines)

On Tue, 14 Nov 1995, Einar Stefferud wrote:

> May I suggest that it might be a really neat idea to define a new MIME
> type to contain these machine readable fragements so as to make them
> machine discoverable and machine readable?  If this is done, then the
> proposed delimiters become standard mime delimitors and we can
> eliminate a whole new namespace and class of delimiters.  The object
> typing also becomes mime standard using content-type.

I'd like to strongly second this.  MIME types for C code (as in the MD*
RFCs), DTDs, and even (yuckk-ptooey) ASN.1 would be quite useful...

> I consider such eliminations to be a great service to mankind;-)...
> Perhaps we should also consider creating an RFC Mime type, perhaps
> text/rfc or application/rfc.  Then we might even define a way to
> provide more machineable RFC structures, without significantly
> sacrificing readability.

I'm not nearlly so clear on this.  It has been very beneficial to have
the simplest lowest-common-denominator format for RFC.  I think its
essential to be able to easily print and understand RFCs with the simples
text processors.  But there may be a good way to demark MIME labeled
sections withing them.  A small amount of design may be needed here to
take care of such trivial as being able to automatically excluse the
page header/footers that fall in the midst of otherwise machine 
processable stuff.

> >From your message Tue, 14 Nov 1995 15:18:57 +0100:
> }
> }
> }One possible such syntax is this: Delimit all segements of an
> }MPS within an RFC by a preceding line such as
> }
> }vvv--- mps4567-1.txt #2 (DTD for HTML 5.0) ------------------vvv
> }
> }and a following line
> }
> }^^^----------------------------------------------------------^^^
> }
> }Here "mps4567-1.txt" is the name of the MPS (and the MPS file
> }that can be extracted) and "#2" is the fragment sequence number.
> }
> }By using these delimiters, the MPS can also be protected from
> }interference with the page headers and footers in the RFC. The
> }only limitation on the content of a MPS this would mean is that
> }lines of length 64 starting with "vvv---" and ending with
> }"---vvv" and lines of the form of the terminating line above
> }would be impossible to use.
> }
> }New acronym in this message: MPS = machine-parsable specification
> }
> }/Olle
> }
> }--
> }Olle Jarnefors, Royal Institute of Technology, Stockholm <[log in to unmask]>

Donald E. Eastlake 3rd     +1 508-287-4877(tel)     [log in to unmask]
   318 Acton Street        +1 508-371-7148(fax)     [log in to unmask]
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager