RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
As we have announced at several plenary reports (does anyone ever pay attention??), the RFC Editor has been trying to work with the xml2rfc fraternity to make xml2rfc into an effective document formatting tool. It has not been quick or easy. I just checked with one of our editors, Alice Hagens, who uses xml2rfc regularly. She tells me that she entered several issues into the xml2rfc tracker, but she does not think anyone is looking at it any more. [YJS] I have heard it several times. But when I say that we have a problem in developing the document handling tools, people on this list tell me that we aren't even doing any development, that this is just a groupd of volunteers, and that their progress in no way effects the process. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
How about people volunteer to help the effort or how about we fund the RFC Editor to work with the XML2RFC people? Simply having a working group does NOT produce running code. Let's not have committees unless we have an answer to this question. Eliot The simple answer is that the IETF should be developing neither a document creation tool nor a tracking tool, nor funding the creation or such tools, nor setting up committees to develop specifications for such tools. There are perfectly good document creation and tracking tools available. When are we going to get back to work relevant to the IETF? RFC 3935 is effectively a charter for the IETF as a whole. It states The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. I believe that some people are mis-interpreting this statement. I propose adding as explicit non-goals * the developing of new document creation tools * the developing of new version tracking tools * the development of new document archival processes Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Ned, What would be useful - in even more than this context - would be if there was a peer-level directory where source for all RFCs would be kept adjacent to the RFCs derived from them. In addition to giving us some concrete evidence of how many RFCs use each source format, it would greatly simplify the process of writing new drafts... -- Eric --[SNIP]-- -- The thing I'd like to have that isn't already there is a way to get -- the xml2rfc sources the RFC editor used back for comparison purposes. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
-- The thing I'd like to have that isn't already there is a way to get -- the xml2rfc sources the RFC editor used back for comparison purposes. What would be useful - in even more than this context - would be if there was a peer-level directory where source for all RFCs would be kept adjacent to the RFCs derived from them. Quite true. But as long as the RFC Editor finds it necessary to use a multi-stage process to produce RFCs with hand tweaking of the output at different stages, I doubt that they will be willing to do this because the input document will not in fact reproduce what's in the RFC. This is why tool improvement to eliminate the need for hand tweaking is so important. But in the meantime, I would hope the RFC Editor would be willing to hand back the xml2rfc source to the author. It's a stopgap, but a useful stopgap. I don't know what needs to be done to make xml2rfc better, but I sure wish the RFC Editor would spend whatever time it takes with the folks who work on xml2rfc to accomplish this. In addition to giving us some concrete evidence of how many RFCs use each source format, it would greatly simplify the process of writing new drafts... Sure - a central repository makes it easy for anyone to come along and produce a document revision. Depending on authors preserving input sources is not nearly as flexible. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
* * What would be useful - in even more than this context - * would be if there was a peer-level directory where source for * all RFCs would be kept adjacent to the RFCs derived from them. The RFC Editor provides nroff source for any RFC upon request, and has always done so. * * Quite true. But as long as the RFC Editor finds it necessary to use a * multi-stage process to produce RFCs with hand tweaking of the output at * different stages, I doubt that they will be willing to do this because the * input document will not in fact reproduce what's in the RFC. This is why tool * improvement to eliminate the need for hand tweaking is so important. But * in the meantime, I would hope the RFC Editor would be willing to hand back * the xml2rfc source to the author. It's a stopgap, but a useful stopgap. We are willing to do so, and have been doing so. You just have to ask. In the current process we have to include a disclaimer that the final AUTH48 corrections and formatting niceties may not be included in the XML source we give back. However, it is still useful as a starting point for later documents. Note that this is potentially a little dangerous, though, because people might start archiving the almost-correct XML and later regenerate an almost-correct copy of the document. * * I don't know what needs to be done to make xml2rfc better, but I sure wish the * RFC Editor would spend whatever time it takes with the folks who work on * xml2rfc to accomplish this. As we have announced at several plenary reports (does anyone ever pay attention??), the RFC Editor has been trying to work with the xml2rfc fraternity to make xml2rfc into an effective document formatting tool. It has not been quick or easy. I just checked with one of our editors, Alice Hagens, who uses xml2rfc regularly. She tells me that she entered several issues into the xml2rfc tracker, but she does not think anyone is looking at it any more. There is unfortunately a fundamental disconnect: philosophically, the xml2rfc folks don't WANT it to be an effective markup language, which is essentially what is needed. Bob Braden * * In addition to giving us some concrete evidence of how * many RFCs use each source format, it would greatly simplify * the process of writing new drafts... * * Sure - a central repository makes it easy for anyone to come along and produce * a document revision. Depending on authors preserving input sources is not * nearly as flexible. * *Ned * * ___ * 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: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 6/20/06, Ned Freed [EMAIL PROTECTED] wrote: I don't know what needs to be done to make xml2rfc better, but I sure wish the RFC Editor would spend whatever time it takes with the folks who work on xml2rfc to accomplish this. Note that the next release will contain several features/changes that the RFC Editor asked for based on their experiences trying to use it for final document production. There are still some requests outstanding, since some of them would be quite difficult to implement and some were bug reports that nobody could replicate, but progress is definitely being made on this front. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On 6/20/06, Bob Braden [EMAIL PROTECTED] wrote: [Alice] tells me that she entered several issues into the xml2rfc tracker, but she does not think anyone is looking at it any more. This is parly my fault - I picked the wrong technology for the tracker and it doesn't notify interested parties upon changes. I'm still interested in working on these problems but I'm so interrupt-driven that I don't often have a chance to poll the tracker. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On Jun 20, 2006, at 12:25 PM, Carl Malamud wrote: May I make a suggestion to both the office of the RFC Editor and to the IESG? This sounds like a classic case for leadership. How about starting up a working group? Give it a capable chair, support from the AD (Brian), and twist some arms I'd find some cycles for such a project. -Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
On Jun 20, 2006, at 11:02 AM, Bob Braden wrote: * Quite true. But as long as the RFC Editor finds it necessary to use a * multi-stage process to produce RFCs with hand tweaking of the output at * different stages, I doubt that they will be willing to do this because the * input document will not in fact reproduce what's in the RFC. This is why tool * improvement to eliminate the need for hand tweaking is so important. But * in the meantime, I would hope the RFC Editor would be willing to hand back * the xml2rfc source to the author. It's a stopgap, but a useful stopgap. We are willing to do so, and have been doing so. You just have to ask. Yes, but what you get back doesn't correspond to the RFC, because of the downstream edits. A volunteer just went through a fairly laborious process to reconstruct the XML version of RFC4287 so that an HTML version could be made available (Yes, I know only the ASCII version is normative). To me it seems that this work should not be necessary.-Tim In the current process we have to include a disclaimer that the final AUTH48 corrections and formatting niceties may not be included in the XML source we give back. However, it is still useful as a starting point for later documents. Note that this is potentially a little dangerous, though, because people might start archiving the almost-correct XML and later regenerate an almost-correct copy of the document. * * I don't know what needs to be done to make xml2rfc better, but I sure wish the * RFC Editor would spend whatever time it takes with the folks who work on * xml2rfc to accomplish this. As we have announced at several plenary reports (does anyone ever pay attention??), the RFC Editor has been trying to work with the xml2rfc fraternity to make xml2rfc into an effective document formatting tool. It has not been quick or easy. I just checked with one of our editors, Alice Hagens, who uses xml2rfc regularly. She tells me that she entered several issues into the xml2rfc tracker, but she does not think anyone is looking at it any more. There is unfortunately a fundamental disconnect: philosophically, the xml2rfc folks don't WANT it to be an effective markup language, which is essentially what is needed. Bob Braden * * In addition to giving us some concrete evidence of how * many RFCs use each source format, it would greatly simplify * the process of writing new drafts... * * Sure - a central repository makes it easy for anyone to come along and produce * a document revision. Depending on authors preserving input sources is not * nearly as flexible. * * Ned * * ___ * 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: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Carl, May I make a suggestion to both the office of the RFC Editor and to the IESG? This sounds like a classic case for leadership. How about starting up a working group? Give it a capable chair, support from the AD (Brian), and twist some arms to get good people to participate. I know this is a radical suggestion, but it just might work. How about people volunteer to help the effort or how about we fund the RFC Editor to work with the XML2RFC people? Simply having a working group does NOT produce running code. Let's not have committees unless we have an answer to this question. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
