Subject: RE: XML2RFC submission (was Re: ASCII art)

From: "Gray, Eric" <[email-masked]>
Date: Tue, 29 Nov 2005 16:53:25 -0500

Dave,

	It looks - to me - as if Bob's post is in response to
Bob's own earlier post.  That should make it difficult to 
construe his more recent post as an "attack." 

	At worst, it's a quick response indirectly aimed at
another quick response.

	One issue with to quickly responding to Bob's earlier
questions is that the XML version - as Christian has already 
said - cannot be the authoritative/normative version of an 
RFC.  I would qualify that someone by allowing that an XML 
version cannot be authoritative/normative unless it is 
completely self contained.  And, by self contained, I mean 
there MUST be an absolute, positively concrete guarantee 
that every time we process it, it will always produce exactly 
the same text.

	If that is the conditions under which it may be useful,
then it is simpler to retain the text.

	The reason for this - as someone else pointed out - is
that the version on which people have agreed is the text 
version that they read at the time when they agreed.  Even 
if the text version was directly produced at that time from 
XML, it is that text that they read at the time that they 
agreed to.

	An analogy of why this is an issue can be seen in why
it is that a pre-merge version of a slew of nearly identical
contracts has no legal value - even if archived with an exact
image of the data used in the merge.  Only a signed contract
has the enforceability of a signed contract.

--
Eric

--> -----Original Message-----
--> From: [email-masked] [mailto:[email-masked]] 
--> On Behalf Of Dave Crocker
--> Sent: Tuesday, November 29, 2005 3:59 PM
--> To: Bob Braden
--> Cc: [email-masked]
--> Subject: Re: XML2RFC submission (was Re: ASCII art)
--> 
--> 
--> 
--> Bob Braden wrote:
--> > It is easy to give glib answers to the following 
--> questions, ignoring
--> > many detailed issues.  Easy, but suspect.
--> 
--> 
--> Bob, it is also easy to ask a set questions and then 
--> dismiss answers to 
--> them.  Easy but suspect.
--> 
--> First of all, if you did not feel that your questions were 
--> sufficient, it 
--> would have been nice for you to have said so.  Evidently 
--> you were looking 
--> for something other than responses, but there is no way to 
--> tell what.
--> 
--> Second of all, if you feel that simple answers to your 
--> directed questions is 
--> not sufficient, perhaps you will respond in a manner that 
--> encourages 
--> exploration, rather than attack.
--> 
--> d/
--> 
--> -- 
--> 
--> Dave Crocker
--> Brandenburg InternetWorking
--> <http://bbiw.net>
--> 
--> _______________________________________________
--> Ietf mailing list
--> [email-masked]
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Nov 2005 11:59:31 -0800

> that every time we process it, it will always produce exactly

The value in retaining input files used to generate the authoritative/ 
normative version of an RFC is to facilitate subsequent updates.   
While the bibliography section could be seen as dynamic for an ID,  
RFC references will provide static results.  Boilerplates provided  
within conversion tools help expedite conformance to current  
requirements.  What problem is created considering the XML version of  
the draft as non-authoritative?  Nevertheless, some effort should be  
made to manage the bibliography reference library related to the  
IETF, to ensure consistent conversions.

An additional benefit could be seen as permitting a larger diversity  
of output formats.  While indeed the current ASCII text RFCs may be  
suitable vehicles for conveying information, they lack convenience  
such as hyper-links to reference information.  The current XML2RFC  
tools provides for both the text and HTML output forms of this  
document.  It would not be difficult to include a PDF output that  
also provides hyper-link capabilities.

Full graphic capabilities may not be a desired goal, as a million  
words may still be required to clarify the intent of a complex  
picture.  In nearly all RFCs, the artwork offering tables describing  
the format of binary structures offers the greatest benefit.  ASCII  
artwork may not draw perfect lines, but this is really a matter of  
character-sets.  Should the IETF consider definitions to cover  
optional characters for drawing table borders and lines?  Does this  
get extended into also allowing international characters for author's  
names?

Clearly an XML input file allows for a greater diversity of outputs.   
Perhaps, with some effort, more than just the text form of the RFC  
can be considered authoritative.  The XML input would not need to be  
considered authoritative to achieve such a goal.  Allowing access to  
these XML documents will reduce the burden on authors attempting to  
make corrections and highlighting what changes are being made, beyond  
the boilerplates and format changes, etc.

-Doug