Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Doug Royer wrote: Brian E Carpenter wrote: Doug Royer wrote: ... It does no good to discuss text that almost everyone already knows has problems. ...it was created to ensure that everyone in the room is actually discussing the same thing. Yes. Perhaps something like SVN could be available. I can 'check in' versions and people could quickly diff them. I use http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht very frequently. This of course would make old versions of the draft available which I feel is useful when you do not remember why something is changed. I seem to recall that this list discussed if old draft versions should be removed or kept. Many times... I do not remember the results. There's never been a clear consensus on that, and it would in some interpretations be a formal change to the RFC 2026 standards process. But being a pragmatist, I also use http://tools.ietf.org/id/ very frequently. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
On Monday, November 28, 2005 07:00:43 PM -0800 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Huitema Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. This formatting program is bound to change over time, e.g. when templates change. You want to archive the final result, not the initial input. Why do you think that? What you want to do is to get as close as possible to the original author's intent. False. In a standards document, what you want to do is get as close to possible to the document which was approved by the standards body. Once the standard is approved, publishing something that looks more like the author's original intent and less like what was approved may be actively harmful. People revising the spec will of course want access to the source form, because it makes their lives easier. The same goes for legislative history like mailing list archives, old versions of the document, etc. And of course, implementors may want access to the same information because it may help them understand WTF the authors were thinking or clarify some ambiguous point. BUT, it is the spec as approved that is authoritative, not the source file that was used to generate the spec as approved. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On Monday, November 28, 2005 12:00:44 PM -0800 Bob Braden [EMAIL PROTECTED] wrote: The RFC Editor has experimented with using xml2rfc for this purpose, and found it awkward and inefficent for producing properly formatted ASCII text. But the two issues of primary concern to the IETF should be the acceptable input formats (currently ASCII text and/or RFC 2629 XML) and the desired publication format(s). And, perhaps, the interchange formats used between authors and the RFC Editor during AUTH48. But I think you've made an important point here, and it surprises me somewhat that it needs to be said aloud among people who spend so much time designing network protocols. The formats of documents... - submitted the I-D repository - discussed in working groups - in last call - submitted for publication - exchanged during AUTH48 - published as RFC's ... are all _interchange_ formats. They are network protocol elements, of a sort, and it is approriate to require for them a particular, well-defined format. It's appropriate to require them to use a particular natural language, a particular file format, and particular conventions for document structure, layout, etc. We could use different sets of requirements for each stage of the process, or the same set for all. Currently, we're not at either extreme. We have a fairly loose set of requirements for things submitted to the I-D repository, and somewhat more stringent requirements by the time a document is sent to the RFC Editor. And, the _output_ of the RFC Editor process is yet another format which is slightly different and a lot more stringent. The formats of documents being edited by authors and editors, or by the RFC Editor, are _not_ interchange formats. They are what in protocol design we call implementation details, and they are best left up to the individuals involved, not dictated centrally. We don't tell implementors what language or compiler to use. We don't tell people what MUA they must use to participate in IETF lists. We shouldn't tell authors and editors what tools they must use, either. So, we need to ask ourselves some questions: - What interchange format do we want to use at each stage of the process? - Are there stages at which we want more than one interchange format, and, if so, which one is authoritative? Personally, I think the following are reasonable requirements: - For documents at every stage up to and including RFC-Editor input: - Documents MUST be plain english text, encoded in US-ASCII. - Aside from the required header at the top of the document, no particular formatting is required. - Headers, footers, and page breaks are not required (if people really want them, so be it; I find them of marginal use and a source of much pain in computing diffs, even with good tools). - We can argue about line length limits; I happen to find them convenient, but they probably don't matter much any more. - Documents MAY include references to diagrams, etc., using one of the popular image formats of the day (JPEG? PNG?). However, it MUST be possible to correctly understand the document and to comply with its requirements without referring to the image (this can perhaps be waived early in the process, but I'd certainly want to see it met by last call). - Documents SHOULD include copies of whatever source form the editor is using, to facilitate transfer to a new editor if necessary. The preferred form is WHATEVER THE AUTHOR IS ACTUALLY USING; the idea is to avoid information loss by using something as close as possible to the source. - The document, images, and source are published as a group. IMHO it should be possible to retrieve the whole set or just the text. - For documents published by the RFC Editor: - Plain English text, UTF-8, formatted in some reasonable fashion - Associated images published alongside the text - Presentation form (PDF?) published alongside the text, with images - Structured source in a standard format, suitable for use as a starting point in creating new versions. - Author's original source should be archived and available on request. - Embedded code, MIB's, ASN.1 modules (anything that today would have to compile to get past the IESG) available as separate files. Both during last call and when an RFC is published, the authoritative version should be the plain text version, for several reasons: - It is the most future-proof - Many people will review that version (not the source) anyway - Different people reviewing the document might see something different due to differences in their tools or environment. This inconsistency is problematic when we are trying to get a large number of people to agree on the _same_ text. - It is imperative that the published authoritative version have the same content as the version that was reviewed. This seems most easily achieved by using formats which are similar enough that
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Brian E Carpenter wrote: Doug Royer wrote: ... It does no good to discuss text that almost everyone already knows has problems. ...it was created to ensure that everyone in the room is actually discussing the same thing. Yes. Perhaps something like SVN could be available. I can 'check in' versions and people could quickly diff them. This of course would make old versions of the draft available which I feel is useful when you do not remember why something is changed. I seem to recall that this list discussed if old draft versions should be removed or kept. I do not remember the results. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Making the xml source available is a boon for those working on subsequent revisions of a document. Many of the RFCs and I-Ds I've worked on have been derivative of earlier RFCs, and having an authorative source format available helps that considerably. Since I grok nroff, I've been able to make good use of the nroff source on occasion, and the RFC Editors have sometimes (in non-crunch-time situations) been quite happy to provide that. I'd much prefer having the source files available at all times so I didn't have to ask them, or make do without during those crunch times. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Just as a rough data point and to second Tony's note, I count about 120 active Internet drafts that are labeled '*bis*'. There are probably many more that don't follow this naming convention. All of these are presumably based on earlier published documents. Tony Hansen wrote: Making the xml source available is a boon for those working on subsequent revisions of a document. Many of the RFCs and I-Ds I've worked on have been derivative of earlier RFCs, and having an authorative source format available helps that considerably. Since I grok nroff, I've been able to make good use of the nroff source on occasion, and the RFC Editors have sometimes (in non-crunch-time situations) been quite happy to provide that. I'd much prefer having the source files available at all times so I didn't have to ask them, or make do without during those crunch times. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On Nov 29, 2005, at 1:53 PM, Gray, Eric wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
* occasion, and the RFC Editors have sometimes (in non-crunch-time * situations) been quite happy to provide that. I'd much prefer having the * source files available at all times so I didn't have to ask them, or * make do without during those crunch times. * Tony, As far as we know, the RFC Editor has never failed to promptly provide nroff source for published RFCs to any who request it. Bob Braden for the RFC Editor ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Bob Braden wrote: ... The RFC Editor has experimented with using xml2rfc for this purpose, and found it awkward and inefficent for producing properly formatted ASCII text. But the two issues of primary concern to the IETF should ... Were the results of these experiments communicated to the xml2rfc maintainers? I would guess the problems can be fixed, after all. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Christian Huitema wrote: Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. This formatting program is bound to change over time, e.g. when templates change. You want to archive the final result, not the initial input. ... *I* would want to archive both. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
... Were there still regular use of nroff in the broad community, there might be an argument in favor of continuing to have it as the internal representation of authoritative rfc text. But there isn't. Whereas xml2rfc has been gaining broad (and enthusiastic) adoption. The anonymous survey that I ran a few months ago, in case people have forgotten, appeared to show about 17% preferring nroff and 68% preferring xml2rfc. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
--On Tuesday, 29 November, 2005 12:00 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: ... Were there still regular use of nroff in the broad community, there might be an argument in favor of continuing to have it as the internal representation of authoritative rfc text. But there isn't. Whereas xml2rfc has been gaining broad (and enthusiastic) adoption. The anonymous survey that I ran a few months ago, in case people have forgotten, appeared to show about 17% preferring nroff and 68% preferring xml2rfc. At the risk of stating the obvious, 17% is far too large a number to support the claim that there is no regular use in the broad community. One or two percent might be, but... Disclaimer: Of all of the ways I have composed I-D and RFC text, nroff has never been one of them -- this is just an observation, not an attempt to defend a personal habit. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On Mon, Nov 28, 2005 at 10:38:12AM -0800, Bob Braden wrote: * * - Making XML-RFC versions of existing or new RFCs available to the * public. * * many can be found at http://xml.resource.org/public/rfc/xml/ * * i'm sure that other people have other repositories. * * /mtr Marshall, How is this possible? I went to that URL, picked an RFC older than CRFC2XML and looked at it. I found this comment: !-- ASCII to XML transformation by Invisible Worlds, Inc. http://invisible.net/ Last transformation: 03-Feb-1999, 02:07:49 Cannonical version of this document is at: http://info.internet.isi.edu/in-notes/rfc/files/rfc2001.txt Implementors should verify all content with cannonical version. Failure to do so may result in protocol failures. -- http://invisible.net/ redirects to http://museum.media.org/invisible.net/index.shtml which claims to be run by The Internet Multicasting Service A Nonprofit Public Research Corporation Welcome to the Internet Multicasting Service, a 501(c)(3) nonprofit public research corporation. We build and maintain public works projects on the Internet. So apparently ASCII - rfc2xml is a public works project. Your deleted comments about possible mistakes are all true, but also at least mentioned by the folks at IMS. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpHq7MxEuM8r.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
(1) yes, (2) yes, (3) XML primary, and (4) see (3). (for what its worth) At 07:00 AM 29/11/2005, Bob Braden wrote: * * * Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. * Dave, I am afraid you are injecting confusion. Use nroff for what? The RFC Editor does not publish nroff, it publishes ASCII text. The tool we use to prepare ASCII for publication happens to be nroff, because it is simple, effective, and efficient. The RFC Editor has experimented with using xml2rfc for this purpose, and found it awkward and inefficent for producing properly formatted ASCII text. But the two issues of primary concern to the IETF should be the acceptable input formats (currently ASCII text and/or RFC 2629 XML) and the desired publication format(s). The issues under discussion should be: (1) whether the RFC Editor should publish RFCs in some XML-based structural document descriptor language, (2) whether this should be in particular the DTD defined in RFC 2629, (3) whether an XML version should be co-authoritative with an ASCII version or should be primary or secondary to the ASCII version, (4) if an XML version is to be published as authoritative, how to ensure that it is correct and consistent with the ASCII version, if any. All this is independent of the fact that xml2rfc is a boon to authors. That is true today, but it has little to do with the publication process or the publication format. Bob Braden * Were there still regular use of nroff in the broad community, there might be * an argument in favor of continuing to have it as the internal representation * of authoritative rfc text. * * But there isn't. Whereas xml2rfc has been gaining broad (and enthusiastic) * adoption. * * d/ * * -- * * Dave Crocker * Brandenburg InternetWorking * http://bbiw.net * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
It is easy to give glib answers to the following questions, ignoring many detailed issues. Easy, but suspect. Bob Braden The issues under discussion should be: (1) whether the RFC Editor should publish RFCs in some XML-based structural document descriptor language, (2) whether this should be in particular the DTD defined in RFC 2629, (3) whether an XML version should be co-authoritative with an ASCII version or should be primary or secondary to the ASCII version, (4) if an XML version is to be published as authoritative, how to ensure that it is correct and consistent with the ASCII version, if any. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
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 PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Dave Crocker -- Sent: Tuesday, November 29, 2005 3:59 PM -- To: Bob Braden -- Cc: ietf@ietf.org -- 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 -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
- Making XML-RFC versions of existing or new RFCs available to the public. many can be found at http://xml.resource.org/public/rfc/xml/ i'm sure that other people have other repositories. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Harald Tveit Alvestrand wrote: 1. A problem working group is not fixed by imposing arbitrary rules and 2. Arbitrary rules and deadlines are indiscriminate. They penalize good 3. Rules and deadlines that attack symptoms rather than core requirements ... irony How nice to know that you think so, Dave does that mean that we will have no more suggestions for arbitrarily chopping off working groups that don't meet certain deadlines for delivering useful output? /irony Harald, You think that dealing with the current issue implies some sort of lock-step relationship that determines the correct answer for the earlier topic of working group productivity time-limits? Please consider reading Crimes Against Logic as a remedial effort. It does quite a good job of clarifying the errors in such misguided responses. At the least, please read my comments (and Ned's) more carefully. I said arbitrary. Lest that seem too broad and vague, I'll instead simply use misguided. The earlier discussion was about a problem that has massive effect on the consumption of IETF resources and also seems to correlate with the likelihood of IETF work being successful. In that case, the basis for a working group productivity time-limit rule is tied quite carefully to a real and basic problem and it attacks it directly. By contrast, the arguments in favor of having a posting deadline, as a means of enforcing some working group process requirements, has been demonstrated a) not to work, and b) to hurt efforts with legitimate reasons for issuing drafts late. So, Harald, rather than straining to dismiss the current issue by claiming that there is irony here, please consider responding to the actual points being made. In particular, the line of analysis that seems to dominate the current rule, and the defense of it, is to focus only on a particular fear and a particular symptom, and not on whether the rule is effective and not on whether it has damaging side-effects. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
The point is that the IETF should publish this information itself with at least as great a prominence as the teletype formatted versions. People who insist that they cannot afford a modern computer and are forced to read from the teletype versions should continue to be served. But the authors of RFCs should be able to state that the XML version is the authoritative one and people should be able to find the HTML generated from the XML source easily on the IETF web site. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marshall Rose Sent: Wednesday, November 23, 2005 2:19 PM To: Henning Schulzrinne Cc: ietf@ietf.org Subject: Re: XML2RFC submission (was Re: ASCII art) - Making XML-RFC versions of existing or new RFCs available to the public. many can be found at http://xml.resource.org/public/rfc/xml/ i'm sure that other people have other repositories. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
* * - Making XML-RFC versions of existing or new RFCs available to the * public. * * many can be found at http://xml.resource.org/public/rfc/xml/ * * i'm sure that other people have other repositories. * * /mtr Marshall, How is this possible? AFAIK, XML source for most published RFCs has never been created. Significant content changes do happen during the RFC editorial process, so the authenticity of any XML sources you may have on hand is, to put it mildly, suspect. Bob Braden * * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
How is this possible? AFAIK, XML source for most published RFCs has never been created. Significant content changes do happen during the RFC editorial process, so the authenticity of any XML sources you may have on hand is, to put it mildly, suspect. Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. Were there still regular use of nroff in the broad community, there might be an argument in favor of continuing to have it as the internal representation of authoritative rfc text. But there isn't. Whereas xml2rfc has been gaining broad (and enthusiastic) adoption. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. This formatting program is bound to change over time, e.g. when templates change. You want to archive the final result, not the initial input. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
* * * Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. * Dave, I am afraid you are injecting confusion. Use nroff for what? The RFC Editor does not publish nroff, it publishes ASCII text. The tool we use to prepare ASCII for publication happens to be nroff, because it is simple, effective, and efficient. The RFC Editor has experimented with using xml2rfc for this purpose, and found it awkward and inefficent for producing properly formatted ASCII text. But the two issues of primary concern to the IETF should be the acceptable input formats (currently ASCII text and/or RFC 2629 XML) and the desired publication format(s). The issues under discussion should be: (1) whether the RFC Editor should publish RFCs in some XML-based structural document descriptor language, (2) whether this should be in particular the DTD defined in RFC 2629, (3) whether an XML version should be co-authoritative with an ASCII version or should be primary or secondary to the ASCII version, (4) if an XML version is to be published as authoritative, how to ensure that it is correct and consistent with the ASCII version, if any. All this is independent of the fact that xml2rfc is a boon to authors. That is true today, but it has little to do with the publication process or the publication format. Bob Braden * Were there still regular use of nroff in the broad community, there might be * an argument in favor of continuing to have it as the internal representation * of authoritative rfc text. * * But there isn't. Whereas xml2rfc has been gaining broad (and enthusiastic) * adoption. * * d/ * * -- * * Dave Crocker * Brandenburg InternetWorking * http://bbiw.net * * ___ * Ietf mailing list * Ietf@ietf.org * https://www1.ietf.org/mailman/listinfo/ietf * ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Xml2rfc is a preparation format. so is nroff. The printed result is a combination of the xml2rfc input and a formatting program of some kind. so is the current nroff-produced text. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Bob, I am afraid you are injecting confusion. Use nroff for what? The RFC Editor does not publish nroff, it publishes ASCII text. The tool we use to prepare ASCII for publication happens to be nroff, because it is simple, effective, and efficient. 1. As long as the RFC Editor uses a formatting language that is not in common use, a translation into the format will be required. Translations are never free, even when automated, and they often are problematic. 2. As long as the published version is free-form ascii, then revising a document with tools that assist in document development, with such things as automated formatting, will be problematic at best. Hence, when authors can work on the authoritative text using THE SAME structured form as is used by the RFC Editor, the community will experience two significant benefits: 1. Reduced costs of RFC Editor processing, by virtue of not having to do the translation and being able to have automated submission tools vet the document against basic errors. 2. Reduced costs of document revision, by being able to start with an attribute-rich format, rather than one lacking any attribute information at all. The RFC Editor has experimented with using xml2rfc for this purpose, and found it awkward and inefficent for producing properly formatted ASCII text. I do not recall seeing these problems discussed on the xml2rfc mailing list. Have you attempted to get the problems fixed? But the two issues of primary concern to the IETF should be the acceptable input formats (currently ASCII text and/or RFC 2629 XML) and the desired publication format(s). You left out: The format of the authoritative version that is available for later revision by potentially different authors The issues under discussion should be: (1) whether the RFC Editor should publish RFCs in some XML-based structural document descriptor language, (2) whether this should be in particular the DTD defined in RFC 2629, (3) whether an XML version should be co-authoritative with an ASCII version or should be primary or secondary to the ASCII version, (4) if an XML version is to be published as authoritative, how to ensure that it is correct and consistent with the ASCII version, if any. that looks like a pretty good list, to me. All this is independent of the fact that xml2rfc is a boon to authors. That is true today, but it has little to do with the publication process or the publication format. That is one of my points. The fact that it is independent actually causes problems, as noted above and in previous postings. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
--On 28. november 2005 09:03 -0800 Dave Crocker [EMAIL PROTECTED] wrote: At the least, please read my comments (and Ned's) more carefully. I said arbitrary. Lest that seem too broad and vague, I'll instead simply use misguided. I don't think this discussion is terribly productive, so I'll shut up after this my point, as far as I had one, was that you were making a general statement about arbitrary rules, without reference to any particular set of them. You have claimed that the I-D submission deadline is arbitrary, despite the fact that people have advanced two separate reasons for them (reduced load on staff just before the meetings and giving people time to read). I have claimed that I think your ideas for chopping off working groups that fail to meet fairly rigid deadlines are not useful (because they will be seen as arbiatrary), despite the fact that you think differently. I think we agree that arbitrary rules are not useful. But we have failed to find common ground on which rules fit that characterization. I suggest that we retire accusations of arbitrariness from the discussion, and rather try to discuss real and perceived effects of the rules. Harald pgp7aLqd1NDVC.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Huitema Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. This formatting program is bound to change over time, e.g. when templates change. You want to archive the final result, not the initial input. Why do you think that? What you want to do is to get as close as possible to the original author's intent. Over time the publication media is going to change. In time very idea of 'print' is going to become an anacronism. If you have a large, high speed, high resolution display and the ability to comment on the text paper is a distinctly inferior technology. Electronic documents do not behave in the same way that people imaging paper ones do, but paper documents do behave that way either, get over it. At the end of the day the real authoritative version of the standard is the bits on the wire. Any specification that is not updated on a regular basis - five years or less is going to diverge from reality to a much greater degree than any imaginable difference in formatting templates. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On 28-Nov-2005, at 14:55, Christian Huitema wrote: Hence the desire to have the RFC Editor use xml2rfc, rather than nroff. I don't think publishing the xml2rfc test is such a good idea. Xml2rfc is a preparation format. The printed result is a combination of the xml2rfc input and a formatting program of some kind. It's a small point, but actually xml2rfc is one of those formatting programs. The preparation format is XML using the 2629 DTD (or a subsequently refinement of it). There are other formatting programs. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Doug Royer wrote: Dave Crocker wrote: ... To elaborate: Is is ever valid for a working group to want to post a new draft late in the game, very near -- or even during -- and IETF meeting? The answer is clearly yes, which is why working groups route around the IETF's arbitrary deadline in the manner that Ned cites. So the early deadline rule does not even fix the problem it supposedly attacks. Yes. Often people do not read the drafts until right before an IETF meeting. Most issues are raised right before an IETF meeting. I think it would be great to be able to submit fixes that will make the meeting more productive. It does no good to discuss text that almost everyone already knows has problems. As Eliot pointed out, discussing text that has changed since half the people in the room read it doesn't work either. I really don't believe that the submission deadline was created in order to prevent abuse of process - it was created to ensure that everyone in the room is actually discussing the same thing. Our meetings (unlike those of some standards groups) aren't drafting sessions - the idea is to clarify substantive issues, but wordsmithing and actual consensus happens on the list in our process. A good time to discuss this issue will be when we have an automatic I-D submission tool according to draft-ietf-tools-draft-submission. Until then, we need the deadline in any case, to release staff resources to prepare for the meeting. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
--On 26. november 2005 03:58 -0500 John C Klensin [EMAIL PROTECTED] wrote: Just to clarify: there are no number of lines or number of columns requirements for submitting Internet Drafts. It is acceptable to turn in unpaginated plain text, and the number of columns is only required for ASCII art if you want your Internet Draft to be eventually published as an RFC. Unfortunately, this is no longer true, or wasn't true a year or so ago. Someone (there was no public announcement) decided that I-D announcements needed to contain a page count. The secretariat responded by (quite properly) complaining to individual authors that unpaginated documents made their work much harder and that long lines broke their tools. And, as others have pointed out, we are now operating in a world in which, if one doesn't have the boilerplate, and _exactly_ the right boilerplate, the submissions get bounced. The last requirement (boilerplate) was done on legal advice, and after discussions in the IPR WG that are much too voluminous for me to even remember it may be an unwise decision, but it was a very public one. Note about the requirement for pagecounts: A recent announcement without a pagecount was draft-goldman-ieprep-comparision-00, which came out on Oct 21; on inspection, that draft has an odd method of pagination (formfeed character immediately followed by the header of the page), suggesting that the tool had failed to count pages correctly, but the I-D was still posted. So it doesn't seem to be a policed requirement Harald pgpSahUppEs0G.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Harald Tveit Alvestrand wrote: ... The last requirement (boilerplate) was done on legal advice, and after discussions in the IPR WG that are much too voluminous for me to even remember it may be an unwise decision, but it was a very public one. Judging by the occasional arrival of legal letters related to copyright issues, I think it was a very wise decision. The last thing we need is ambiguity in this area. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Speaking not so much to the deadline in particular, but to the concept of rules versus judgments --On lørdag, november 26, 2005 11:39:22 -0800 Dave Crocker [EMAIL PROTECTED] wrote: To begin: 1. A problem working group is not fixed by imposing arbitrary rules and deadlines on it. 2. Arbitrary rules and deadlines are indiscriminate. They penalize good workers as well as bad. 3. Rules and deadlines that attack symptoms rather than core requirements create an arcane and arbitrary bureaucracy that serves more as a barrier to getting work done that a facilitator. irony How nice to know that you think so, Dave does that mean that we will have no more suggestions for arbitrarily chopping off working groups that don't meet certain deadlines for delivering useful output? /irony unfortunately also: 1. A problem working group always resists getting its issues fixed. 2. A problem working group's first line of defense is we don't have a problem. 3. A problem working group's second line of defense is what rules did we violate. 4. A problem working group's last ditch line of defense is to make the job of fixing its problems so unpleasant for the person who tries to help fix it that that person either burns out or chooses to work on some more rewarding task. (this does not apply only to working groups) In most cases, rules are, in addition to giving guidance, a tool for getting to defense line #4 quickly. viz: - a WG that has problems getting drafts in on time MAY have someone who tries to ramrod things through - OR it may have genuine last-minute changes. - an author who's submitting drafts with improper boilerplate MAY be sloppy and/or unable to get the CLRs right - OR he may be trying to slip something into the IETF system that gives his company leverage later - a WG that consistently misses deadlines and has deadlines 1 year out of date (I chair one of those :-() MAY have a problem with the WG chair's attention bandwidth, the participation, or the style of debate - OR it may be so close to finishing that it's decided it's more important to finish the last set of documents than to update its charter In all cases, I think there's no substitute for really looking at the specifics of the situation and trying to figure out what's going on - and the most important resource we have there is the bandwidth of good people who are willing and able to do the work. Rules are tools. But occasionally we need all the tools we can use. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
--On Friday, November 25, 2005 10:45 AM -0800 Paul Hoffman [EMAIL PROTECTED] wrote: At 9:13 PM -0800 11/24/05, Christian Huitema wrote: An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Just to clarify: there are no number of lines or number of columns requirements for submitting Internet Drafts. It is acceptable to turn in unpaginated plain text, and the number of columns is only required for ASCII art if you want your Internet Draft to be eventually published as an RFC. Unfortunately, this is no longer true, or wasn't true a year or so ago. Someone (there was no public announcement) decided that I-D announcements needed to contain a page count. The secretariat responded by (quite properly) complaining to individual authors that unpaginated documents made their work much harder and that long lines broke their tools. And, as others have pointed out, we are now operating in a world in which, if one doesn't have the boilerplate, and _exactly_ the right boilerplate, the submissions get bounced. How this happened, after what consideration of tradeoffs, and on what authority from the community is another thread, but it certainly has happened. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
At 3:58 AM -0500 11/26/05, John C Klensin wrote: --On Friday, November 25, 2005 10:45 AM -0800 Paul Hoffman [EMAIL PROTECTED] wrote: At 9:13 PM -0800 11/24/05, Christian Huitema wrote: An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Just to clarify: there are no number of lines or number of columns requirements for submitting Internet Drafts. It is acceptable to turn in unpaginated plain text, and the number of columns is only required for ASCII art if you want your Internet Draft to be eventually published as an RFC. Unfortunately, this is no longer true, or wasn't true a year or so ago. Someone (there was no public announcement) decided that I-D announcements needed to contain a page count. The secretariat responded by (quite properly) complaining to individual authors that unpaginated documents made their work much harder and that long lines broke their tools. And, as others have pointed out, we are now operating in a world in which, if one doesn't have the boilerplate, and _exactly_ the right boilerplate, the submissions get bounced. How this happened, after what consideration of tradeoffs, and on what authority from the community is another thread, but it certainly has happened. Wow. I didn't know that because I switched over to XML around that time; before then, I was using plain text without pagination. If it is still true, it is also sad. Forcing people to use non-intuitive formatting tools just so someone can have a page count for Internet Drafts is not conducive to getting good work from volunteer Internet Draft authors. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Folks, In spite of Bert's desire to avoid a lengthy thread, I believe this issue needs serious discussion because it so thoroughly exemplifies the approach the IETF has been taking in the creation of its rules: If a working group is worried about documents getting read, they will impose their own deadlines or they will constrain their agenda. Having the Secretariat use an IETF-wide deadline for this purpose is Procrustean, to say the least. This sort of constraint is a safe guard against run away working group chairs In practive all this does is force groups to distribute drafts via other means. I've seen plenty of cases where the version of a draft discussed at a meeting isn't available as an I-D yet. To begin: 1. A problem working group is not fixed by imposing arbitrary rules and deadlines on it. 2. Arbitrary rules and deadlines are indiscriminate. They penalize good workers as well as bad. 3. Rules and deadlines that attack symptoms rather than core requirements create an arcane and arbitrary bureaucracy that serves more as a barrier to getting work done that a facilitator. To elaborate: Is is ever valid for a working group to want to post a new draft late in the game, very near -- or even during -- and IETF meeting? The answer is clearly yes, which is why working groups route around the IETF's arbitrary deadline in the manner that Ned cites. So the early deadline rule does not even fix the problem it supposedly attacks. Working group rough consensus is supposed to determine decisions within a working group. If the chairs can 'ram through changes by silencing people then there is a much, much deeper problem with the working group that merely having late drafts getting submitted. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Dave Crocker wrote: ... To elaborate: Is is ever valid for a working group to want to post a new draft late in the game, very near -- or even during -- and IETF meeting? The answer is clearly yes, which is why working groups route around the IETF's arbitrary deadline in the manner that Ned cites. So the early deadline rule does not even fix the problem it supposedly attacks. Yes. Often people do not read the drafts until right before an IETF meeting. Most issues are raised right before an IETF meeting. I think it would be great to be able to submit fixes that will make the meeting more productive. It does no good to discuss text that almost everyone already knows has problems. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: EARLY submission deadline (Re: XML2RFC submission (was Re: ASCII art))
Dave, Working group rough consensus is supposed to determine decisions within a working group. If the chairs can 'ram through changes by silencing people then there is a much, much deeper problem with the working group that merely having late drafts getting submitted. I find that rough consensus BARELY works (if it can be said to work at all) for technical matters. I've watched working group chairs abuse their ability to declare rough consensus. The result has been many a camel. Maybe this does indeed point to a deeper problem (who needs so many camels? ;-), but working group chairs should NOT make it up as they go along. They have enough to do. So you need some general rules of behavior, and this falls under that category. It's a bit of a social contract where we say it is reasonable for people to have their drafts in a certain point in advance, and therefore it is reasonable for people who participate in the meetings to have read them. Nothing arbitrary about that. In order to relax the rule, the guy who shows up in the working group who has questions because he has NOT read the draft would have to be accommodated at the expense of the time of everyone else. I think the change would be a bad trade off. Also, having worked with standards bodies who DO NOT have this rule, I can tell you that it's quite frustrating to get into an argument with someone only to discover that each is working off a different version of a draft. It also makes diffs harder when someone actually sends text. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Eliot, This sort of constraint is a safe guard against run away working group chairs attempting to ram through changes by silencing people who have not read the latest draft that came out while people were traveling to the event. The issue is not the reasonableness of the reason for wanting to do it, but rather the unreasonableness of imposing it on all working groups. Fear that some groups might stray is not a good reason for treating all groups with that fear. The IETF used to be quite flexible, permitting many styles of legitimate working group operation. Instead we have let fear of runaway working groups justify more and more burdens. So rather than being a venue that can permit minimal overhead -- where legitimate -- we have become a venue with high overhead for all efforts. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
But the problem, Dave, is that everyone already churns their drafts right before the deadline. It's not like SOME groups would go till the last possible minute- nearly everybody would, and the plane ride's not THAT long... ;-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
At 9:13 PM -0800 11/24/05, Christian Huitema wrote: An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Just to clarify: there are no number of lines or number of columns requirements for submitting Internet Drafts. It is acceptable to turn in unpaginated plain text, and the number of columns is only required for ASCII art if you want your Internet Draft to be eventually published as an RFC. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
At 06:13 25/11/2005, Christian Huitema wrote: XML2RFC submission would be based on an IETF standard, and I understand that many will find that attractive. However, for me, this is problematic. An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Compare that to an XML grammar: we define lines and lines of rules, attributes, sub attributes, and their expected meaning. Guess what: we are engineers, and engineers like to tinker. Given that tinkering with XML grammars is both very easy and very tempting, we can be pretty sure that there will be many revisions. An XML format is going to be much less stable than the current status! As a preparation tool, XML2RFC is probably OK. But it cannot be as stable and future proof as ASCII text as a final product format. Full agreement with this. But are not addressed the two problems I rose: 1. the need of larger than 72 characters lines for some drafts. 2. the need to quote authoritative external non-ASCII drafts and texts. IMHO this only calls for the possibility to quote external texts as authorititative. So the issue is not everything that only way, but this is the default way. When needed otherwise, here is how we proceed. I note that when a BCP must quote an authoritative external document, it is because it applies to usages under that external document, and that the concerned users will be able to read it. Another solution would be to maintain an RFC giving the list of the non-IETF documents, the IETF accepts as authoritative (this would no prevent an ASCII version for information). jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Dave, It is pretty much never a good idea to have the mechanics of a process contain artificial constraints, as a means of implementing higher-level policies. If a working group is worried about documents getting read, they will impose their own deadlines or they will constrain their agenda. Having the Secretariat use an IETF-wide deadline for this purpose is Procrustean, to say the least. This sort of constraint is a safe guard against run away working group chairs attempting to ram through changes by silencing people who have not read the latest draft that came out while people were traveling to the event. In practive all this does is force groups to distribute drafts via other means. I've seen plenty of cases where the version of a draft discussed at a meeting isn't available as an I-D yet. In other words, the constraint doesn't appear to be an effective safeguard in practice. Dave has it right: This is simply a Procrustian annoyance. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
Dave Crocker wrote: This looks like quite a good list. The only thing I would add is an interactive submission tool that validates the xml2rfc document being submitted. Rather than explicitly penalize the text submitters with an earlier date, I'd suggest providing a bonus extension deadline for those submitting via this interactive path, since it would require NO human intervention on the I-D publishing side... after the tool gets built. I don't want to end up in long discussions on IETF list. But one of the reasons for EARLY submission deadline is to ensure that the IETF participants actually get some time to READ/STUDY the documents that need f2f time in IETF WG meetings! Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
W.r.t. - We can say that it's time to require XML2RFC for all drafts. there is a variant of this that i think i like: do not impose this switch onto those submitting, but change the formatting language used by the rfc editor to be xml2rfc. so, submissions in xml2rfc are highly welcome, but pure text is still welcome, with hand-conversion by the editor staff. I appreciate that we (IETF) try to not force everybody into using the same tool. It probably is a productivity booster for many authors if they can continue to work with the tools they normally use in daytime job or have become used/accustomed to over the years. At the other hand, I would want everybody to realize that if we say: ..., but pure text is still welcome, with hand-conversion by the editor staff. that that means a SERIOUS cost. You did all see the numbers at the last Plenary, where (iirc) the rough number for RFC-editor is 1 million dollars for the coming year. The more hand-conversion work we impose on the RFC-Editor, the more that it will cost us (IETF). So I feel that there is a justified pressure for authors to seriously consider to use the tools we (as IETF) choose to focus on. just my 2 cents. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
- Making XML-RFC versions of existing or new RFCs available to the public. absolutely! I see support of this a few times (and that includes me). I think that if you (we) all really mean this, then I think it would be good to see if you can get it accepted as an IETF (consensus) requirement in the TECHSPEC mailing list: [EMAIL PROTECTED] Otherwise, I suspect it will not happen for a long time! The RFC Editors actually have source versions of most existing RFCs, either as nroff or xml. They're just not easily accessible; you have to ask to get a specific copy. I've always been surprised that they haven't been accessible right next to the .txt files. Let me repeat, that as far as I know, the RFC editor does NOT have .xml versions of the FINAL RFC. They always end up generating .nroff files and do some tailoring/editing to the .nroff before the final RFC gets produced (from .nroff). See also my earlier posting. I personally think that is unacceptable... but that is just that, my personal opinion. If we (IETF) want it changed, then we better express the need/requirement in the techspec activity as I said above. Bert Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Wijnen, Bert (Bert) wrote: But one of the reasons for EARLY submission deadline is to ensure that the IETF participants actually get some time to READ/STUDY the documents that need f2f time in IETF WG meetings! Indeed. The idea is that since XML-RFC-formatted drafts can be vetted automatically, we can cut down on the interval between the I-D deadline and when the draft is actually announced and available. This time interval seems to be as large as three or four days, given the hundreds of last-minute submissions received by the secretariat. Thus, if we were to give XML-RFC formatted drafts one additional day, they'd still appear several days earlier than drafts do today. This obviously presumes the existence of the automated I-D submission tool that is being discussed. Bert ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
In message [EMAIL PROTECTED] om, Wijnen, Bert (Bert) writes: Let me repeat, that as far as I know, the RFC editor does NOT have .xml versions of the FINAL RFC. They always end up generating .nroff files and do some tailoring/editing to the .nroff before the final RFC gets produced (from .nroff). I'd sure like to see some comments from the RFC editor on what they'd like, and what it would mean to them if everything came in in XML. I've written all of my RFCs in nroff, though I've been contemplating switching to XML. If we adopt some new format, though, I think we really need the ability to generate diffs of different versions of the same document. Today, I use wdiff; the RFC editor also uses wdiff during the auth48 period. I've never seen a pdfdiff; we might want a tool that takes two XML input documents and generates a diff.XML file that, when rendered, shows something like wdiff produces today. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
But one of the reasons for EARLY submission deadline is to ensure that the IETF participants actually get some time to READ/STUDY the documents that need f2f time in IETF WG meetings! When TCP was improved enough so that it could saturate a ethernet (jumping from a max of 2Mbps to more than 9) there were serious proposals not to implement the improvements, the improvements would permit unfair use of the LAN. It is pretty much never a good idea to have the mechanics of a process contain artificial constraints, as a means of implementing higher-level policies. If a working group is worried about documents getting read, they will impose their own deadlines or they will constrain their agenda. Having the Secretariat use an IETF-wide deadline for this purpose is Procrustean, to say the least. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
At the other hand, I would want everybody to realize that if we say: ..., but pure text is still welcome, with hand-conversion by the editor staff. that that means a SERIOUS cost. right. that is why we should have moved to an automated submission process long ago. the issue, now, is transition. we need to make the change in a way that does not impose traumatic effect on existing practise. therefore we have to continue to accept free-text drafts. at some point, in the future, we can consider ending this practise. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On 11/24/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: If we adopt some new format, though, I think we really need the ability to generate diffs of different versions of the same document. The solution that comes to mind for diffs is to format the old version (to text), format the new version, and use the existing tools (htmlwdiff, rfcdiff, or others). There's no sensible way to do a diff of a graphic so I think diffing the text form is sensible. If it's to be the input of wdiff, it's be feasible to create an XSL transform that generates text (it's tough to wrap to 72 columns and add headers and footers in XSL, but wdiff would (might) make that unimportant), so that diff generation isn't reliant on an installed xml2rfc. I have a transform that I wrote when I was first learning xsl that translates to nroff -- not particularly useful in this context but a proof of concept for going to some textual form. (FOP's txt renderer looks attractive, except that it gets the spacing wrong - I just tried it with Julian's FO scripts and got The three-stageIETF standardizationprocessisdescribed inBCP 9,RFC 2026 [RFC2026]. Inbrief,thethree stagesofInternetstandardizationareProposed (which requiresa wellwritten,openly reviewed specification), Draft(which requiresProposed status,multipleimplementations and some operationalexperience),and full InterneStandard (which requiresDraft statuand more extensi veoperationalexperience).Historically, increasedrequirements,originallydocumented inRFC 1264 [R FC1264], have been appliedto protocols produced withinthe Routing Area. ) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
On Wed, 2005-11-23 at 20:31 -0500, John C Klensin wrote: Folks, not to be a stick-in-the-mud, but one of the things that has made the RFC Editor process attractive for authors is that it is possible to design and use the right format for a particular presentation. Sometimes that means interesting page layouts and indentations. An extension in the XML2RFC conversion permits better control of the formating. figure title= artwork name= type= height= width= xml:space=preserve ASCII artwork or fixed formatting (with XML characters escaped). i.e. lt; or gt; Of course quot; is needed elsewhere as well. /artwork /figure Is there something prohibiting the IETF from controlling the RFC2XML and XML2RFC process? Perhaps XML2RFC could be improved with schemas as better guides authors using more modern (OS independent) editors. Following the web2 trend, there could be a web based application to further simply this process, perhaps even allowing entry of an text RFC. Some suggested PDF or or PS. These represent the output of the document and not the input, meaning subsequent changes would be difficult. At least with XML, moving ASCII back into a document is not too cumbersome. With a XML as an input, then including links or references within various spiffy outputs would not be problematic. As with anything, there is a learning curve. Including links and references would be improved by having access to the source document rather than amorphous output text that requires a display application before it can be understood. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
In message [EMAIL PROTECTED], Bill Fenner writes: On 11/24/05, Steven M. Bellovin [EMAIL PROTECTED] wrote: If we adopt some new format, though, I think we really need the ability to generate diffs of different versions of the same document. The solution that comes to mind for diffs is to format the old version (to text), format the new version, and use the existing tools (htmlwdiff, rfcdiff, or others). There's no sensible way to do a diff of a graphic so I think diffing the text form is sensible. That's certainly one reasonable approach. My concern was if we decided that PDF was the right way to publish RFCs -- we'd have no easy way to do diffs, since some people would use XML, some Word, some OpenOffice, etc. Put another way, I'm primarily stating a requirement. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Steven M. Bellovin smb at cs dot columbia dot edu wrote: That's certainly one reasonable approach. My concern was if we decided that PDF was the right way to publish RFCs -- we'd have no easy way to do diffs, since some people would use XML, some Word, some OpenOffice, etc. Put another way, I'm primarily stating a requirement. Adobe Acrobat can do three different types of diffs between PDF documents. Yes, yes, I know Acrobat is proprietary (and expensive), and I'm not at all suggesting it be required equipment for the IETF or RFC authors. But if Acrobat can do it, maybe some freely available software will be able to do the same in the future. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
XML2RFC submission would be based on an IETF standard, and I understand that many will find that attractive. However, for me, this is problematic. An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Compare that to an XML grammar: we define lines and lines of rules, attributes, sub attributes, and their expected meaning. Guess what: we are engineers, and engineers like to tinker. Given that tinkering with XML grammars is both very easy and very tempting, we can be pretty sure that there will be many revisions. An XML format is going to be much less stable than the current status! As a preparation tool, XML2RFC is probably OK. But it cannot be as stable and future proof as ASCII text as a final product format. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
An interesting part of the current text format is that it is defined in a very simple way: so many lines, so many columns, that's about it. Christian, The format has never been that simple and it has gotten increasingly complex in recent years. The format requirements include lines/page, headers, boilerplate, author and title information in specific forms, citations in two sets(!), a security section, and probably a few more. ALL OF THESE ARE PART OF THE FORMAT! Getting them correct is proving increasingly difficult in free-text. In xml2rfc it is vastly easier. For us to require that a simple ascii representation always be available makes quite a lot of sense. To retain it as the purported input form does not, especially when it is not really the input form. What we really are talking about here is moving from nroff to xml2rfc. The fact that the nroff component can be kept out of the sight of authors is one of the reasons our publication costs are about US$ 1M/year. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
- We can say that it's time to require XML2RFC for all drafts. there is a variant of this that i think i like: do not impose this switch onto those submitting, but change the formatting language used by the rfc editor to be xml2rfc. so, submissions in xml2rfc are highly welcome, but pure text is still welcome, with hand-conversion by the editor staff. so i guess the bit that would be visible to submitters is permitting ONLY pure text or xml2rfc submission formats. no submissions in 1970's formatting languages... d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
I personally would welcome any pragmatic approach that maximizes the long-term usefulness of our output. I hope we have general agreement that a structured document format is better long-term than any unstructured, presentation-oriented format, be it ASCII, Word or PDF. The latter all lose information that then has to be manually added later or guessed, with some probability of error, by tools. Beyond that, we can be pragmatic and rather than fight a small, but determined, minority, hope that almost all drafts will be available in a content-oriented format that can be easily transformed. That certainly beats another round of IETF list philosophy discussions and 0% availability. As a community, we need to distinguish what works for the vast majority of contributors and for our customers (implementors, readers) from what's convenient for some subset of authors. Good organizations serve their customers and their long-term interests, not primarily the convenience of their own staff. I'd much rather move now to some version of strong encouragement of XML submission. This encouragement can take multiple forms: For example, I see nothing wrong with a WG or area deciding that all of their WG drafts will be kept in XML, since they might value the long-term usability of their output. (Drafts now routinely cycle through bis stages and the original editor may not be the bis editor. Thus, having the convenience of the current editor outweigh the long-term cost to the working group just doesn't seem right.) Summary of suggestions: - Official statement of encouragement from the IESG that WG drafts submitted for IESG action SHOULD be in XML-RFC format when being submitted (but can be in any format the working group feels like and the I-D editor accepts during the early stages). - Allow submission of XML-RFC format to the I-D editor, as part of the automation of that part of our process. - (Semi-serious) Have an earlier IETF cut-off date for I-Ds in ASCII, since it takes longer to automatically check them for compliance. This will solve our format problem in one IETF round :-) - Making XML-RFC versions of existing or new RFCs available to the public. Henning Spencer Dawkins wrote: (With some hesitation, but if we're discussing a specific proposal, I guess this is more than just cycling) I would find this problematic. I often submit in the final form because I started in the final form. I have no *roff or XML form to submit. Well, this can go a few different ways: - the authors must submit XML2RFC or plain text, where what you submit is what's used as the canonical source, or - We can assume that an author of any draft that genrates any interest can dragoon someone among the thousands of IETF participants to spin plain text as XML2RFC, at some point in time (note that we practice the reverse art today; anyone wanting to modify a specification will often start out with the plain text of an I-D or an RFC and reverse-engineer it into XML2RFC, or into nroff, or into MS-Word, so the burden is already out there, and we're just talking about whether we inflict it on the original author, or on subsequent authors), or - We can say that it's time to require XML2RFC for all drafts. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Henning Schulzrinne wrote: Summary of suggestions: - Official statement of encouragement from the IESG that WG drafts submitted for IESG action SHOULD be in XML-RFC format when being submitted (but can be in any format the working group feels like and the I-D editor accepts during the early stages). - Allow submission of XML-RFC format to the I-D editor, as part of the automation of that part of our process. - (Semi-serious) Have an earlier IETF cut-off date for I-Ds in ASCII, since it takes longer to automatically check them for compliance. This will solve our format problem in one IETF round :-) I love it! - Making XML-RFC versions of existing or new RFCs available to the public. absolutely! The RFC Editors actually have source versions of most existing RFCs, either as nroff or xml. They're just not easily accessible; you have to ask to get a specific copy. I've always been surprised that they haven't been accessible right next to the .txt files. Tony Hansen [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Summary of suggestions: This looks like quite a good list. The only thing I would add is an interactive submission tool that validates the xml2rfc document being submitted. Rather than explicitly penalize the text submitters with an earlier date, I'd suggest providing a bonus extension deadline for those submitting via this interactive path, since it would require NO human intervention on the I-D publishing side... after the tool gets built. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
This looks like quite a good list. The only thing I would add is an interactive submission tool that validates the xml2rfc document being submitted. If the Proto Tools group hasn't already started on such a thing, it's only because they are already working on something that we need more, but I thought Henrik and I have already discussed this (so it's only a matter of time). Rather than explicitly penalize the text submitters with an earlier date, I'd suggest providing a bonus extension deadline for those submitting via this interactive path, since it would require NO human intervention on the I-D publishing side... after the tool gets built. We don't create text in face-to-face meetings, but we do have discussions that affect text; a submission tool that runs on autopilot would allow us to submit updated drafts based on discussions, and make sure we got it right while we still have face-to-face time with people. I note that we are now publishing drafts during IETF week; the tool would simply make this easier for the secretariat. And if the tool only runs on autopilot for xml2rfc inputs, that could be OK with me... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Henning Schulzrinne wrote: I personally would welcome any pragmatic approach that maximizes the long-term usefulness of our output. I hope we have general agreement that a structured document format is better long-term than any unstructured, presentation-oriented format, be it ASCII, Word or PDF. The latter all lose information that then has to be manually added later or guessed, with some probability of error, by tools. The nice thing about ASCII is that you don't need Word or a PostScript viewer -- or for that matter a graphical O/S to read them. And it's stable. VERY stable. Show me something that is vendor neutral for five years AND A REAL REASON TO GO TO IT, and I'm mostly there. On the other hand, here's a reason to NOT go away from ASCII. As someone mentioned to me today, ASCII art forces people to think about conciseness and complexity. If you can't reasonably depict it in ASCII art perhaps you have a problem with one or the other. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
That's helpful - maybe the tools team can start a more centralized collection. As I noted in another context, the problem today is that changes during AUTH48 often don't make it into the author (XML) version since the editing is based on the RFC editor's ASCII and the OLD/NEW batch editor. It would be really bad if a collection of XML were to show the state just before AUTH48 (and maybe even before any IESG notes to the RFC editor). Marshall Rose wrote: - Making XML-RFC versions of existing or new RFCs available to the public. many can be found at http://xml.resource.org/public/rfc/xml/ i'm sure that other people have other repositories. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Henning Schulzrinne wrote: It would be really bad if a collection of XML were to show the state just before AUTH48 (and maybe even before any IESG notes to the RFC editor). that is why the core to any format change needs to be the format the editor uses. moving them from nroff to xml2rfc is key to any strategic improvement in things. they probably would not mind being moved from a simple text editor, that requires they get all the formatting commands exactly right, so some that is format-aware and can help, or even entirely do, the formatting... d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
on 2005-11-23 19:50 Dave Crocker said the following: Summary of suggestions: This looks like quite a good list. The only thing I would add is an interactive submission tool that validates the xml2rfc document being submitted. The tool has been specified (draft-ietf-tools-draft-submission) and approved by the IESG (the document is in the RFC editor's queue). The Tools Team has requested that implementing this be placed high on the list of things to be taken on by the secretariat once the contract with the new service provider is in place. Rather than explicitly penalize the text submitters with an earlier date, I'd suggest providing a bonus extension deadline for those submitting via this interactive path, since it would require NO human intervention on the I-D publishing side... after the tool gets built. I agree. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
Folks, not to be a stick-in-the-mud, but one of the things that has made the RFC Editor process attractive for authors is that it is possible to design and use the right format for a particular presentation. Sometimes that means interesting page layouts and indentations. Sometimes it means cross-references within a document to, e.g., numbered paragraphs or list elements within a section (and those are different, at least in the ways that the RFC Editor has been willing to format them in the past). Sometimes it means reference forms that are consistent with library or scholarly standards for the materials being referenced, rather than forms that are optimized for RFC-style references. Attractive for authors _is_ important: while it is all very well to say that the goal is the end user (which the authors would typically agree with), if we make things unpleasant or uncomfortable enough for the authors --who are, by and large, volunteers-- we will lose some of them. That isn't healthy for the IETF either. It is possible to do any of the things I've mentioned above in the xml2rfc context. However, sometimes it requires external formatting followed by the use of artwork elements, which can defeat the whole purpose of content-oriented markup. Other times it requires tricking the processor into doing the right thing by use of annotation elements or clever and undocumented uses of seriesInfo and/or format elements. These things are not often necessary. But they are, I would suggest, necessary as often (or more so) than fancy graphics are. Of the I-Ds and RFCs I have out there, some have been developed and edited by working directly on the ASCII text. At least two or three were developed in Word and then (painfully) converted. One was initially developed, long ago, in SGML (!) markup but then forced into ASCII text and continued that way. For the last year or three, I've been using XML2RFC almost exclusively, but I have had to make a few compromises that the RFC Editor ultimately had to straighten out in nroff or that made the relevant documents much harder to read and understand (as one example, find the document-within-a-document examples of ISDs in draft-klensin-newtrk-sample-isd-00.txt). In addition, for I-Ds at least, making the XML generally available raises some of the IPR rights reserved for the author except insofar as the IETF needs them for standards-related work issues raised on the IPR list -- where copyrights are concerned, presentation formats are important. (Issues about whether those rights are important and what they are belong on another list.) So, while I'm generally in favor of the submit XML and keep XML trends and discussions, I think we need to be quite careful that XML2RFC and its format conventions and limitations don't become a Procrustean bed into which authors and documents either need to fit or to find somewhere to do work besides the IETF. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
