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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Sep 2003 11:06:20 -0400

I proposed allowing XML format of Internet Drafts be made available
if they exist.  Period.

I specifically DO NOT propose changing the RFC process in any way.
I specifically DO NOT propose anything but an OPTIONAL submission
of xml; ASCII text must always be submitted, as it is now.
If you have xml, send it, and we'll post it.  That's it.
I think I have consistently argued against expanding this
proposal. 

Yeah, I know about camel's noses, but I agree with John that the
proposal useful and harmless.  

Brian

> -----Original Message-----
> From: Vernon Schryver [mailto:[email-masked]]
> Sent: Wednesday, September 03, 2003 6:51 PM
> To: [email-masked]
> Subject: RE: A modest proposal - allow the ID repository to hold xml
> 
> 
> > From: John C Klensin <[email-masked]>
> 
> > ...
> > (1) As an/the authoritative format, plain ASCII text, plus 
> > whatever additional format(s) the RFC Editor decides to permit 
> > to support drawings, etc., should almost certainly remain the 
> > target for the reasons you identify. ...
> 
> > (2) If a group of people, such as a WG, are collaborating on the 
> > development of a document, having the working format (whatever 
> > it is) readily available would seem to be an advantage.  This 
> > should not make that format authoritative, or attach any special 
> > importance or validation to it relative to other formats.
> 
> That sounds fine or at least tolerable.
> 
> > Now I think that all that Brian proposed originally was that the 
> > XML format of Internet Drafts be made available when it happened 
> > to exist.   Even though that might be letting the proverbial 
> > camel's nose into the tent, it strikes me as basically harmless 
> > and probably useful.
> 
> yes.
> 
> > Did I misunderstand him?  Do we disagree about part of the above 
> > and, if so, which part?
> 
> My possibly mistaken impression of Brian's most recent position is
> that he would support XML for the official documents.  Regardless of
> his position, other people have clearly come out in favor XML for the
> official format.  The frequently mentioned hyperlinks among documents
> such as for authors would be rather boring if the links are only among
> documents that expire after 6 months.  More powerful searching among
> I-Ds would be useful, but the real power would be searching among
> RFCs.  Several people have written about converting old RFCs to XML.
> 
> 
> Vernon Schryver    [email-masked]
> 
> _______________________________________________
> 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: Michael Thomas <[email-masked]>
Date: Thu, 4 Sep 2003 09:59:55 -0700 (PDT)

Er, if you're going to do that, why don't you just
accept any source format?

	   Mike

---

From: Melinda Shore <[email-masked]>
Date: Thu, 4 Sep 2003 13:22:30 -0400

On Thursday, September 4, 2003, at 12:59 PM, Michael Thomas wrote:
> accept any source format

It depends what problem you're trying to solve.  I really dislike the
use of XML for representing protocol elements and I still use nroff and
troff for producing most of my documents (not just internet drafts), but
I can see where including XML marked-up documents in the repository
would be a win *for archival purposes*.  How working groups want to
handle making document source available is a related but substantially
different matter.

Melinda

---

From: Michael Thomas <[email-masked]>
Date: Thu, 4 Sep 2003 10:42:42 -0700 (PDT)

> handle making document source available is a related but substantially

I haven't been paying to much attention to this
thread, but my underinformed take was that there
were two largish things:

1) Source availability
2) Better cross referencing

For (1), just being agnostic and telling people to
just deal with whatever source format the author
(or wg) decided they felt most comfortable editing
in gets you most of the way toward the XML goal
without having to deal the religion problem. I
don't think it's unreasonable to put the onus on
the people who want source to deal with what the
author wanted to use. The original editor's life
(or lack thereof) seems more important, IMO.

For (2), somebody has graciously pointed out that
draft/rfc->html mungers already exist.

So as a more modest proposal:

On the drafts and RFC's repository have two new
options:

1) Source in whatever format it came in
2) The .txt sent through the .html grinder

	    Mike

---

From: Melinda Shore <[email-masked]>
Date: Thu, 4 Sep 2003 13:55:15 -0400

> 2) Better cross referencing

3) Structured text allows for better retrieval capabilities (which is
related to 2, actually).  What we've got right now is pretty crude.  As 
I
mentioned earlier, I don't see any reason why working groups shouldn't 
continue
to do as they will for their own purposes, but how working groups manage
document source is not the same question as providing better search and
retrieval (or document management, for that matter) capabilities within 
document
archives.  I wouldn't want to see nroff or Word source archived for the 
long
term.

Melinda

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Sep 2003 12:20:13 -0600 (MDT)

> From: Michael Thomas <[email-masked]>

> 2) The .txt sent through the .html grinder

As stated that would be a disaster of inviting not just the camel's
nose but the whole herd into the tent.  For I-Ds, redistributing
whatever the authors submitted is mostly harmless and potentially
valuable to working groups.  It's also potentially dangerous if a
working group tolerates attempts to "steal" documents, but let's put
that worry asside.

The catastrophy would be keeping anything except .txt for RFCs
anywhere remotely official.

The obvious issue of in any sense publishing more than .txt is how
you handle unavoidable conflicts between .txt and the format of the
same document.  Just repeating "The .txt is normative" is not enough.
Unless you are merely a legalistic stadnrads lawyer, you care about
more fostering interoperability than avoiding liabilities.  That
requires preventing misunderstandings instead of telling the mislead
"you should have read the .txt document."

There will be differences between the two formats.  A major point of
non-.txt is to have diferences in presentation.  Presentation matters
and affects the perceived semantics.  We have experimental proof of
this in the PostScript RFCs, and that despite the fact that the
presentation of PostScript is fixed compared to XML.  This week we've
heard complaints that pagination and line-breaking in the .txt RFCs
is rigid, as if that were a bug instead of a vital feature.

Consider the problem of answering the question "Is the RFC on my screen
or printer the same as your document?  Was either version edited by
someone or something?"

Then there is the IETF political problem.  As is standard in these
recurring discussions, there have already been plenty of claims that
.txt is not powerful enough for searching, linking, pictures, editing,
and reformating.  As soon as there are XML RFCs there will be irresistable
pressures to make them normative.  I think PostScript RFCs are not
normative only because Jon Postel autocratically said "No" to the
similar pressures then.  The pressures would be stronger now, and we
don't have Jon Postel to order the tide to retreat.

Then no matter what DTD verifiers the RFC Editor runs, we will have
people saying "RFC 98765432 says blah de blah right here on this
sheet of paper" because they printed it with a User Friendly XML
printer that fixes spelling errors and deletes bits that infringe on
Microsoft's business plans and the RIAA's intellectual property.

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 4 Sep 2003 13:12:47 -0600 (MDT)

> Microsoft's business plans and the RIAA's intellectual property.

Vernon, if you honestly believe this to be true, then the only format you
could possibly advocate is printed hardcopy locked up in a vault.

Even ASCII documents are subject to bit rot, be it on media, during
transmission, while in memory, etc.

--lyndon

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Sep 2003 16:14:03 -0600 (MDT)

> From: Lyndon Nerenberg <[email-masked]>

> could possibly advocate is printed hardcopy locked up in a vault.

Yes I honestly belive this to be true.  The only format I'm really
happy with for normative RFCs is paper.  (Well, I'd prefer etchings
on stainless steel.)  However, .txt is close enough because .txt's do
get converted to write-once paper that anyone can compare with any
other purported copy.

> transmission, while in memory, etc.

Yes, everything including paper rots.  However, XML is not only designed
to be malleable, but most if not all of its proponents in this cycle
of this old argument have touted that characteristic as if it were
desirable feature instead of terrible bug.  With XML (as with HTML),
you must assume that someone or something has edited your copy
differently than anyone else's copy.

As I said, the presentation or form of a document matters.  Changing
pagination often changes what people understand of a document.

The purposes of RFCs do not include being easy to edit.  Everything
including the convenience of people with ambitions to produce
RFC 987654321.ter must be subservient to the real purposes of RFCs.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 4 Sep 2003 17:48:50 -0500

On 9/4/03 at 12:20 PM -0600, Vernon Schryver wrote:

>This week we've heard complaints that pagination and line-breaking 
>in the .txt RFCs is rigid, as if that were a bug instead of a vital 
>feature.
>
>Consider the problem of answering the question "Is the RFC on my 
>screen or printer the same as your document?  Was either version 
>edited by someone or something?"

So when I read an RFC on my Palm and all of the line breaks are in 
different places, or when Sam Hartman listens to an RFC with a 
text-to-speech engine, the fact that it is not the "same" as your 
document (for your implied values of "same") is seen as a "vital 
feature" and not a bug? I'm sorry, Vern, but this argument is utter 
nonsense. Though I do oppose immediately converting the RFC archive 
to XML for all sorts of reasons, the fact that a markup language 
allows you to output identical content in different formats is not 
one of those reasons.

*If* a restricted form of XML (or any markup language) could be shown 
to reliably preserve semantic content of a standard (and pagination 
and line-breaks should never be a part of semantic content) but could 
produce output for different environments, I'd consider that a big 
feature. The problem is that it will take some serious work to get an 
appropriately restricted form of such a markup language to make it 
reasonable as the canonical form of standards documents. But I think 
this small step of making XML available in the I-Ds is a good thing 
for other reasons and might give us enough info to tell whether XML 
would be viable in the long run for RFCs.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Sep 2003 17:09:37 -0600 (MDT)

> From: Pete Resnick <[email-masked]>

> nonsense. 

We're even because I think it's at bset nosense to talk about knowingly
and willfully locally rewriting a .txt document as if it were similar
to the automagic reformating of XML and HTML .  You and Sam Hartman
know what you're doing to an RFC, or at least that you're doing it.
No use of a browser really knows anything about what went into the 
rendering engine.

>           Though I do oppose immediately converting the RFC archive 
> and line-breaks should never be a part of semantic content) 

In theory pagination and line-breaks are not parts of semantic content,
but as with most superfical, simplistic theories, practice differs.

And I'm not talking about the obvious effects on packet and state
diagrams of pagination or line length changes.

>                                                             but could 

Showing that two different presenations of a document have the same
semantic value sounds close to a Halting Problem, unless you define
"semantic content" vacuously.  Just defining what you mean by semantics
is hard.

Take your text-to-speech or Palm examples.  Are you really claiming
that a protocol RFC with packet and state diagrams stripped from its
XML source by a "user friendly" browser has its intended meaning?

No one can predict what any XML or HTML browser will do with XLM in
all likely evironments, no matter how restricted the DTD.  The only
way you could hope to make such predictions is to so restict the
enviroment of the rendering system that you would have the equivalent
of .txt, while carrying around the bugs in the million of lines of
code in an IE or Mozilla.