Subject: A modest proposal - allow the ID repository to hold xml

From: wang liang <[email-masked]>
Date: Tue, 2 Sep 2003 19:46:05 -0700 (PDT)

Rosen, Brian wrote:
>Allow the submission of an xml file meeting the requirements of RFC2629
>along with the text file (and optional ps file) for an Internet Draft.
 
  I totally agree with it.RFC2629 may be something need improvement.Now some protocols are completely written in XML schema,like UDDI. Even now I have to find how to use the nroff.I can't find its window version.It just give us some inconvenience.
  you will find search in XML is easier than in any other formats,if you have ever made some programs about it.XML may be the most efficient method to describe a protocol,how can we refuse it.

---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Sep 2003 09:35:47 -0400

Lyndon

You make some good points.
However, I have not proposed that we change the RFC process,
and I've been very carefull to propose that we only accept xml
optionally, retaining the requirement to 'send text'.  I did so
quite deliberately, and I'd really appreciate it if we could
take this one small step, rather than changing the entire process,
which has served us well for so long.  We get a very large bang
for such a small, incremental addition.  Can we just try this
step and see what happens?

Brian  

> -----Original Message-----
> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 5:24 AM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: A modest proposal - allow the ID repository to hold xml
> 
> 
> On Wed, 3 Sep 2003, Jari Arkko wrote:
> 
> > I'd very much like to allow the submission of XML to the
> > I-D directories.
> 
> > However, in addition I'd like to actually allow the
> > submission of HTML, generated by xml2rfc. Why? Because
> > I'd really like to browse most drafts through my browser,
> > jump to sections,  find the references easily etc. And without
> > performing any extra steps by myself.
> 
> One of the primary reasons for proposing XML as the canonical 
> RFC format
> is that these other formats (ASCII text, HTML, PDF/Postscript,
> refer/indxbib, SQL, Tektronix 4013) can be derived from the 
> XML source.
> 
> Presumably the RFC editor would publish the XML document as the
> authoritative version, and would also generate and publish 
> (from the XML)
> alternative copies in the ASCII text, PDF, and HTML formats.
> 
> This satisfies the "plain ASCII text rules" bigots (in which camp I am
> still firmly entrenched) while taking advantage of the markup 
> and linking
> facilities provided by PDF and HTML. (I've completely given 
> up hope that
> Microsoft will ever acknowledge that non-flowed text/plain must be
> rendered with a mono-spaced font, fifty years of prior art be 
> damned, eh?)
> 
> > (It may be that this is possible via XML as well -- I'm
> > not expert in XML so I can't tell if its readily supported
> > by everyone's browser without loading lots of DTDs. Does
> > someone know?)
> 
> The point of XML is that you don't have to be able to read 
> it. Given an
> XML DTD for RFCs, tools can be written that express the XML 
> in pretty much
> any format you like. HTML would certainly be one of those 
> formats. (And
> for guys like me who live and die by grep, even *I* would buy into an
> xmlrfcgrep program that provided grep functionality against 
> "XML-RFC-DTD"
> files.)
> 
> > And all of these submission formats should be allowed if
> > and only there's a text version to go with it.
> 
> Let me go out on a limb and say "No they shouldn't; only XML 
> submissions
> should be allowed."
> 
> 
> 
> Now that the shrapnel has stopped whizzing past my head, let 
> me explain
> why.
> 
> The traditional way of writing RFCs is with nroff, typically using a
> minimal subset of the -ms macros. In recent years Microsoft 
> Word (along
> with other WYSIAWYG software) has invaded the traditional 
> UNIX typesetting
> tools workspace to a certain degree (in the context of writing
> IETF-related documents). Regardless, other than the 
> occasional Loonie who
> formats this stuff purely by hand, we are all already using markup
> languages to create these documents. That being the case, XML 
> isn't a new
> way of writing these documents, it's just a different one. 
> The current RFC
> DTD isn't complicated, and -- as long as it's kept simple[*] 
> -- I don't
> see any excuse for people not to use it. Then again, I've 
> been using troff
> exclusively for 20 years now, to the point where I can 
> _almost_ see the
> consistency of its syntax ...
> 
> While there isn't a whole lot I *can't* accomplish in troff, 
> my experience
> with using it to write I-Ds suggests that those documents are so
> structured that I really just want to write a simple set of macros
> tailored for that task. I shudder to think what the Word crowd goes
> through in this regard. WYS might be WYG, but the path 
> between the two (in
> my very limited experience) is one whose mana will suck the 
> very sanity
> from your living soul.
> 
> There is no argument to be made against the suitability of XML as the
> canonical format for authoring RFCs and drafts. Writing the 
> raw XML might
> not be pleasant, but neither is writing raw 'roff (or MS 
> Word) for many
> people. Let's embrace this as an opportunity. If we can get 
> the marketing
> twits to concentrate on selling GUI XML RFC authoring tools, 
> we just might
> be able to distract them from contaminating the actual working groups.
> 
> --lyndon
> 
> [*] The critical aspect is that the DTD *must* be kept 
> simple. If the DTD
> evolves into a Turing machine with Perl-like syntax we can just
> acknowledge that it's time to shut down the IETF and go home. 
> I cling to
> the forlorn hope that people still know - and more importantly,
> understand - what the 'E' in IETF stands for.
> 
> _______________________________________________
> This message was passed through 
> [email-masked], which is a sublist of 
> [email-masked]. Not all messages are passed. Decisions on what 
> to pass are made solely by Raffaele D'Albenzio.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Sep 2003 13:22:21 -0400

I think there are quite a few reasons.  Mine are:
1) Ability to render in alternate ways to improve
	readability and accessibility
2) Ability to cross reference documents
3) More uniformity in, e.g. references

Brian

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Tuesday, September 02, 2003 1:06 PM
> To: Rosen, Brian; [email-masked]'
> At 6:15 PM -0400 8/27/03, Rosen, Brian wrote:
> >I therefore have a modest proposal:
> >
> You didn't say what the additional value would be. We know the 
> additional value of a .ps file (drawings that don't translate to 
> ASCII art). What is the value of XML? It certainly isn't 
> searchability or readability.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 4 Sep 2003 16:24:26 +0200

I agree. ASCII is a big pain. For example, graphics/pictures can clarify a lot the text and with ASCII is painful and not so clear.
 
We should support format that are easy to edit, formats that support control of changes and so on.

I will agree to support for example a PDF as the final document, instead of TXT.

Regards,
Jordi
 
> ----- Original Message ----- 
> From: "Iljitsch van Beijnum" <[email-masked]>
> To: "Vernon Schryver" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, September 04, 2003 12:36 PM
> > On woensdag, sep 3, 2003, at 23:34 Europe/Amsterdam, Vernon Schryver 
> > wrote:
> > 
> > > It is just plain ***WRONG!*** to even start to consider anything but
> > > ASCII for the official documents.  As hard as it is for the unscared
> > > to believe, even XML will fade away completely and be replaced by
> > > something else even more wonderful, user friendly, easier for convicted
> > > monopolies to embrace and extend, and so forth.  When that happens,
> > > there will be a new calls for "reform."
> > 
> > It's all very simple. The ASCII format in which RFCs are published is a 
> > huge pain, because it puts whitespace, linebreaks, headers, footers and 
> > page breaks in fixed places. So anyone who doesn't use the same printer 
> > as the RFC editor is inconvenienced.
> > 
> > For just reading the RFC this isn't a huge deal as after the first 
> > hundred or so you get used to it. But for editing an existing document, 
> > it is much more painful.
> > 
> > Personally, I'd like to see all the extra stuff that isn't pure ASCII 
> > with a line break after a paragraph go, but I guess this is different 
> > for everyone. But there is one thing I'm pretty sure of: nobody edits 
> > IDs or RFC in their native format. So why not simply make the format 
> > used by the author available in a structured way? This isn't guaranteed 
> > to help (the original format may only be decipherable by no longer 
> > existing tools) but at least there is potential for more efficiency, if 
> > the original format can stilll be read and converted.
> >

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Sep 2003 13:40:21 +0200

IANAXE*, so I may be saying something stupid here, but...

Wouldn't it be possible to come up with a DTD that makes it possible to 
tag all the different parts of a draft or an RFC to enable all the 
automated processing we love so much, but in such a way that when all 
the <.*> sequences are removed, the document in current RFC format 
emerges?

This wouldn't lead to authoritativeness problems, and it should allow 
taking a draft or RFC and covert it back to an editable document 
without making the draft/RFC itself irresistibly editable. And it 
doesn't make any assumptions about the format of RFCs, so it shouldn't 
be a problem to bring older RFCs under this regime.

* I am not an XML expert