From housley@vigilsec.com Wed Sep 15 12:04:22 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0C53A6A00 for ; Wed, 15 Sep 2010 12:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AIa6DX2FmDz for ; Wed, 15 Sep 2010 12:04:22 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id E1DDE3A69B4 for ; Wed, 15 Sep 2010 12:04:21 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E514EF24034; Wed, 15 Sep 2010 15:05:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id cv6g6iFjVgdD; Wed, 15 Sep 2010 15:04:36 -0400 (EDT) Received: from [192.168.1.228] (e5.c4b7d1.client.atlantech.net [209.183.196.229]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 194159A472F; Wed, 15 Sep 2010 15:05:02 -0400 (EDT) Message-ID: <4C9118CF.2040500@vigilsec.com> Date: Wed, 15 Sep 2010 15:04:47 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: xml2rfc-dev@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Sep 2010 13:05:25 -0700 Cc: Ray Pelletier , Russ Housley Subject: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 19:04:23 -0000 xml2rfc is a critical tool. As a result, we need to figure out how to migrate it to a place where paid IT folks are able to keep it working. I need your help to develop a plan to make that happen. I do not even know if it is easy or hard. I know that several people have been talking about the improvements needed to fully implement the recent headers and boilerplate changes. Should that happen before the migration or after? I know that several people have been talking about rewriting the tool. I assume that will happen after the migration. Is that a reasonable assumption? Russ From julian.reschke@gmx.de Wed Sep 15 13:45:49 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F603A6995 for ; Wed, 15 Sep 2010 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.684 X-Spam-Level: X-Spam-Status: No, score=-103.684 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCGc4tKfZXLx for ; Wed, 15 Sep 2010 13:45:47 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 771D33A693A for ; Wed, 15 Sep 2010 13:45:45 -0700 (PDT) Received: (qmail invoked by alias); 15 Sep 2010 20:46:10 -0000 Received: from p508FB302.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.179.2] by mail.gmx.net (mp018) with SMTP; 15 Sep 2010 22:46:10 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+gEKwYGbegIJs04MwVB9UgbUQ7jSUjNc01Dl+FW9 7syL+Bym+u87wV Message-ID: <4C913086.80605@gmx.de> Date: Wed, 15 Sep 2010 22:45:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> In-Reply-To: <4C9118CF.2040500@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 20:45:49 -0000 On 15.09.2010 21:04, Russ Housley wrote: > xml2rfc is a critical tool. As a result, we need to figure out how to > migrate it to a place where paid IT folks are able to keep it working. I > need your help to develop a plan to make that happen. I do not even > know if it is easy or hard. I think it depends how ambitious you are. We moved everything to tools.ietf.org a few months ago, see . It has a SVN repository and test cases, and can generate the files for xml.resourc.org. What's missing is people working on the open issues. > I know that several people have been talking about the improvements > needed to fully implement the recent headers and boilerplate changes. -> > Should that happen before the migration or after? Depends a bit on the RFC-Editor's requirements. My gut feeling is: - do the boilerplate changes in the current code - then figure out a mid-term strategy Also, don't move it. Maintain it in-place. > I know that several people have been talking about rewriting the tool. > I assume that will happen after the migration. Is that a reasonable > assumption? I'm not sure any migration is needed (after the work we did in March). So how *should* the mid-term look like? - We do have a somewhat working TCL code base, which is hard to maintain, and lacks people understanding TCL. It also suffers from a prehistoric non-conforming XML-parser-like thingy being part of it. - There is an XSLT implementation that transforms conforming source code to (X)HTML. This one has been maintained by me for many years, and will continue to be maintained. Formatting to TXT is tricky, and involves understanding the XML format, the boilerplate issues, and also line-breaking, page-breaking and table formatting. For everything *except* the TXT-specific there is working XSLT code. I'd recommend writing a post-processor that takes its XHTML output, and reformats that as plain text. To make this work well, we might have to augment the XHTML with a few extensions (hard-wired class names maybe), but I think that's superior to redoing the first part from scratch. If I would need to do that, I'd probably use Java. But any language that can parse an XHTML document and which has decent string processing should do. Best regards, Julian From housley@vigilsec.com Sun Sep 26 10:35:13 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9DF43A6B7E for ; Sun, 26 Sep 2010 10:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFqAVx9pbkag for ; Sun, 26 Sep 2010 10:35:12 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 694783A69A2 for ; Sun, 26 Sep 2010 10:35:12 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 031019A4793; Sun, 26 Sep 2010 13:35:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2STUopxafezX; Sun, 26 Sep 2010 13:35:47 -0400 (EDT) Received: from [192.168.2.104] (pool-96-231-149-87.washdc.fios.verizon.net [96.231.149.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id EDBDB9A4790; Sun, 26 Sep 2010 13:35:54 -0400 (EDT) Message-ID: <4C9F847B.5070007@vigilsec.com> Date: Sun, 26 Sep 2010 13:35:55 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Julian Reschke References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> In-Reply-To: <4C913086.80605@gmx.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 17:35:13 -0000 My question generated much less discussion than I expected. I gather that the current code is stored on tools.ietf.org, but that there are some things that need to be handled in the current implementation before any further action is considered. I have not heard a plan to make them happen. Is anyone working on the TCL code base to fix ? It appears that no action has been taken in the last 5 months. We should also discuss a few things that Julian said: > - We do have a somewhat working TCL code base, which is hard to > maintain, and lacks people understanding TCL. It also suffers from a > prehistoric non-conforming XML-parser-like thingy being part of it. If ticket 6 is an indication, we have a serious maintenance problem. > - There is an XSLT implementation that transforms conforming source code > to (X)HTML. This one has been maintained by me for many years, and will > continue to be maintained. > > Formatting to TXT is tricky, and involves understanding the XML format, > the boilerplate issues, and also line-breaking, page-breaking and table > formatting. > > For everything *except* the TXT-specific there is working XSLT code. I'd > recommend writing a post-processor that takes its XHTML output, and > reformats that as plain text. To make this work well, we might have to > augment the XHTML with a few extensions (hard-wired class names maybe), > but I think that's superior to redoing the first part from scratch. > > If I would need to do that, I'd probably use Java. But any language that > can parse an XHTML document and which has decent string processing > should do. Is this a direction that makes sense to others? This leads to an architecture that produces the TXT file by: XML --> (X)HTML --> TXT Would it b just as easy to produce PDF? XML --> (X)HTML --> PDF Or, would we continue to produce the PDF from the TXT? Russ From julian.reschke@gmx.de Sun Sep 26 10:52:29 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C8E3A6B74 for ; Sun, 26 Sep 2010 10:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.803 X-Spam-Level: X-Spam-Status: No, score=-103.803 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYLZYdO3QKmS for ; Sun, 26 Sep 2010 10:52:24 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id AC43E3A6B66 for ; Sun, 26 Sep 2010 10:52:17 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2010 17:52:53 -0000 Received: from p508FDB30.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.219.48] by mail.gmx.net (mp050) with SMTP; 26 Sep 2010 19:52:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18mreUvmI4mHdpWCgVeLroq0Cmf9+wBlE7cO0Lkcz 85kBiNDE8mc+8G Message-ID: <4C9F8873.4070306@gmx.de> Date: Sun, 26 Sep 2010 19:52:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4C9F847B.5070007@vigilsec.com> In-Reply-To: <4C9F847B.5070007@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 17:52:30 -0000 On 26.09.2010 19:35, Russ Housley wrote: > My question generated much less discussion than I expected. It wasn't unexpected to me; the original xml2rfc mailing list is a much bigger audience, see ; maybe we should restart the thread over there. > I gather that the current code is stored on tools.ietf.org but that > there are some things that need to be handled in the current > implementation before any further action is considered. I have not > heard a plan to make them happen. I don't think there's anything that *needs* to be done. We (mainly Tony Hansen and myself) generated a release last April. Since then nothing major has happened, in particular the changes for the new RFC boilerplate (as of Jan 2010) haven't been implemented yet. > Is anyone working on the TCL code base to fix > ? > It appears that no action has been taken in the last 5 months. That's a correct observation (Tony did some work during the last code sprint, but that's it). The time I invest goes into rfc2629.xslt (which *does* have the boilerplate changes implemented), but only generates HTML/XHTML, not plain text. > We should also discuss a few things that Julian said: > >> - We do have a somewhat working TCL code base, which is hard to >> maintain, and lacks people understanding TCL. It also suffers from a >> prehistoric non-conforming XML-parser-like thingy being part of it. > > If ticket 6 is an indication, we have a serious maintenance problem. > >> - There is an XSLT implementation that transforms conforming source code >> to (X)HTML. This one has been maintained by me for many years, and will >> continue to be maintained. >> >> Formatting to TXT is tricky, and involves understanding the XML format, >> the boilerplate issues, and also line-breaking, page-breaking and table >> formatting. >> >> For everything *except* the TXT-specific there is working XSLT code. I'd >> recommend writing a post-processor that takes its XHTML output, and >> reformats that as plain text. To make this work well, we might have to >> augment the XHTML with a few extensions (hard-wired class names maybe), >> but I think that's superior to redoing the first part from scratch. >> >> If I would need to do that, I'd probably use Java. But any language that >> can parse an XHTML document and which has decent string processing >> should do. > > Is this a direction that makes sense to others? This leads to an > architecture that produces the TXT file by: > > XML --> (X)HTML --> TXT Correct. > Would it b just as easy to produce PDF? > > XML --> (X)HTML --> PDF > > Or, would we continue to produce the PDF from the TXT? Producing PDF is a more or less (*) solved problem already, see for instructions, and for an example. That being said: I'm not sure that we should invest time and money to produce PDF..., good HTML seems to be way more important to me. Best regards, Julian (*) There are a few edge cases that do not work well yet, but with sufficient energy this probably could be fixed. From johnl@taugh.com Sun Sep 26 11:15:53 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856363A6B52 for ; Sun, 26 Sep 2010 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.802 X-Spam-Level: X-Spam-Status: No, score=-10.802 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idyCRUXCbtxu for ; Sun, 26 Sep 2010 11:15:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 045EF3A6B50 for ; Sun, 26 Sep 2010 11:15:51 -0700 (PDT) Received: (qmail 71885 invoked from network); 26 Sep 2010 18:16:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=k1009; bh=XZxEK9xQs4pLoocPPaFoj5PV2Ia6dB+YvZYrmoECquY=; b=ArnY7yuBLFJgBQlrRw9wD8Jz0o5XavJYPR8QU6vCf49I7d929/VuyJkC8q0rm33uur6DpcBfvLm9+0l/GaiVC3e6Jux5cjPE2qtlcKJrL4X27nYvCUVh4cz/XGJOz4ummfjg+qYXsTu/XNRSAAzja5HlZhUrWMfgs55Mw7cdXjs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=k1009; bh=XZxEK9xQs4pLoocPPaFoj5PV2Ia6dB+YvZYrmoECquY=; b=oDgOkJ/WgYtSyXZDoLf2Q4iBWluUGcUL0l6LouX+bFG1EEwmXQXrvEbHxAT0w0Q0TGCrK6gj7lmuOScQhjxfZ0qC/lcvphrKO7DPwa0J6/nRFSowCVI5y7H5E7c/D5rb/Rjcf3eaJtV6BqM812f2iVvbl3Xjf4aV9VnJ8vu+izY= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Sep 2010 18:16:06 -0000 Date: 26 Sep 2010 14:16:27 -0400 Message-ID: From: "John R Levine" To: xml2rfc-dev@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 18:15:53 -0000 >> - We do have a somewhat working TCL code base, which is hard to >> maintain, and lacks people understanding TCL. It also suffers from a >> prehistoric non-conforming XML-parser-like thingy being part of it. > > If ticket 6 is an indication, we have a serious maintenance problem. No kidding. It's a quick hack that passed its best-before date many years ago. >> For everything *except* the TXT-specific there is working XSLT code. I'd >> recommend writing a post-processor that takes its XHTML output, and >> reformats that as plain text. To make this work well, we might have to >> augment the XHTML with a few extensions (hard-wired class names maybe), >> but I think that's superior to redoing the first part from scratch. It's hard to say whether it's easier to intuit the necessary semantics from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think an important goal needs to be that it can produce output that the RFC editor can use without post editing. If it can't, they'll probably still want it to produce nroff. >> If I would need to do that, I'd probably use Java. But any language that >> can parse an XHTML document and which has decent string processing >> should do. Sure. My preference would be perl, but anything with suitable libraries and string processing would be fine. > XML --> (X)HTML --> TXT > > Would it be just as easy to produce PDF? > > XML --> (X)HTML --> PDF > > Or, would we continue to produce the PDF from the TXT? That's more a political than a technical question. A PDF made from the TXT produces a printable version of the canonical text. A PDF made from the XHTML makes a document that's a lot easier to read. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor Please consider the environment before sending this e-mail. From julian.reschke@gmx.de Sun Sep 26 12:14:34 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04B83A6A36 for ; Sun, 26 Sep 2010 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.791 X-Spam-Level: X-Spam-Status: No, score=-103.791 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ9ex3WU+1oK for ; Sun, 26 Sep 2010 12:14:33 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 399533A69D4 for ; Sun, 26 Sep 2010 12:14:32 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2010 19:15:08 -0000 Received: from p508FDB30.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.219.48] by mail.gmx.net (mp035) with SMTP; 26 Sep 2010 21:15:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18H6QcNy1MHFZnsCYF9tYOdBKmQkCon2IRXUoA9kt WmkDqD8CusB7Y3 Message-ID: <4C9F9BB9.4020003@gmx.de> Date: Sun, 26 Sep 2010 21:15:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "John R. Levine" References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4C9F847B.5070007@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org, Russ Housley Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 19:14:34 -0000 On 26.09.2010 20:14, John R. Levine wrote: > ... > It's hard to say whether it's easier to intuit the necessary semantics > from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think The step from XML->XHTML already does everything *except* formatting into plain text, this includes computing the boilerplate, doing the various reference and list formats, etc. > an important goal needs to be that it can produce output that the RFC > editor can use without post editing. If it can't, they'll probably still > want it to produce nroff. Indeed. The problem is that the RFC production center apparently likes the ability to micromanage vertical space and line breaks. That is a problem. I'm not convinced that they'd switch to any tool that gives them less control than nroff does today. >>> If I would need to do that, I'd probably use Java. But any language that >>> can parse an XHTML document and which has decent string processing >>> should do. > > Sure. My preference would be perl, but anything with suitable libraries > and string processing would be fine. > >> XML --> (X)HTML --> TXT >> >> Would it be just as easy to produce PDF? >> >> XML --> (X)HTML --> PDF >> >> Or, would we continue to produce the PDF from the TXT? > > That's more a political than a technical question. A PDF made from the > TXT produces a printable version of the canonical text. A PDF made from > the XHTML makes a document that's a lot easier to read. Right. Just keep in mind that we already have a way to produce a printable version from TXT (via Henrik's rfcmarkup tool). Best regards, Julian From johnl@taugh.com Sun Sep 26 13:16:28 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B303A6B90 for ; Sun, 26 Sep 2010 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.859 X-Spam-Level: X-Spam-Status: No, score=-10.859 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPIDGo5OwCvE for ; Sun, 26 Sep 2010 13:16:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D65F33A6B85 for ; Sun, 26 Sep 2010 13:16:24 -0700 (PDT) Received: (qmail 9189 invoked from network); 26 Sep 2010 20:17:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=k1009; bh=ZlEgj8Kr3RPz7T2Q5LAtAc824RDK7DE5FP0KgQ5hiiI=; b=Gn44VHEgM4+XMQk0jmpsA8AQfNA0rvQlXnIfT/pBomRZQyMr5xX78wrjhgX1cDF+VDHcZC9xTGccT71LtFaf8UIqySJrC6rt3KtU+TdD9b0eZeFsz7Y9GzwwSmBEXcQfla+7PSRtGCY8HF+F6iED3f+Gp1A2U3eaRyrFsCn2O/Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=k1009; bh=ZlEgj8Kr3RPz7T2Q5LAtAc824RDK7DE5FP0KgQ5hiiI=; b=OGijG2EEADOYiqgxpAdune7lHYD/JeYc+uTUg9Ru4/WS0uBnNf6UGTa75/MRSH0AP9tmi+nVR6gCnxLrzlBLhqPT7dOQ8cTl7J3C0JFNzoy+zUOlyvYA5FJBsLWcr+MlI6CCfSsT6F/5DQ+mE0cAUj+LOWWr7h/Z6ZNCxDCbiAU= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Sep 2010 20:16:39 -0000 Date: 26 Sep 2010 16:17:00 -0400 Message-ID: From: "John R Levine" To: xml2rfc-dev@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 20:16:28 -0000 >> It's hard to say whether it's easier to intuit the necessary semantics >> from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think > > The step from XML->XHTML already does everything *except* formatting into > plain text, this includes computing the boilerplate, doing the various > reference and list formats, etc. That should be fine so long as the tagging in the XHTML is adequate to recognize what each kind of feature is. > Indeed. The problem is that the RFC production center apparently likes the > ability to micromanage vertical space and line breaks. That is a problem. I'm > not convinced that they'd switch to any tool that gives them less control > than nroff does today. Well, if we hire someone to rewrite it, there's something to put in their checklist. It would probably be possible to use stylized comments to give it hints to control line spacing or whatever else they're fussing about while not screwing up the semantics of the XML. Based on the experiments Paul H and I did when we were applying to be the RFC Ed, it shouldn't be hard to make the tool smart enough to get the spacing right on its own, although it would take a long time for the RFC Ed to believe that. >>> XML --> (X)HTML --> TXT >>> Would it be just as easy to produce PDF? >>> XML --> (X)HTML --> PDF >>> Or, would we continue to produce the PDF from the TXT? >> >> That's more a political than a technical question. A PDF made from the >> TXT produces a printable version of the canonical text. A PDF made from >> the XHTML makes a document that's a lot easier to read. > > Right. > > Just keep in mind that we already have a way to produce a printable version > from TXT (via Henrik's rfcmarkup tool). Huh? rfcmarkup creates simple minded html with clickable links, not PDF. If you want to turn paginated text into PDF that looks like the paginated text, you can easily use enscript or a2ps to produce postscript, and ps2pdf (a wrapper around ghostscript) to turn it into PDF. The more interesting path is from XHTML to PDF, with pages formatted like what a browser does with XHTML. R's, John From julian.reschke@gmx.de Sun Sep 26 14:07:21 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3293A6BBA for ; Sun, 26 Sep 2010 14:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.779 X-Spam-Level: X-Spam-Status: No, score=-103.779 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOL6LIaf9QHP for ; Sun, 26 Sep 2010 14:07:19 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 93FA83A69D9 for ; Sun, 26 Sep 2010 14:07:18 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2010 21:07:54 -0000 Received: from p508FDB30.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.219.48] by mail.gmx.net (mp001) with SMTP; 26 Sep 2010 23:07:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX184HN5/kcs4ELHpUeAQMqWqcFTb0iQ3/XYkZQevC3 oEIl5gLb6g1oNn Message-ID: <4C9FB626.6070708@gmx.de> Date: Sun, 26 Sep 2010 23:07:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: John R Levine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 21:07:21 -0000 On 26.09.2010 22:17, John R Levine wrote: >>> It's hard to say whether it's easier to intuit the necessary semantics >>> from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think >> >> The step from XML->XHTML already does everything *except* formatting >> into plain text, this includes computing the boilerplate, doing the >> various reference and list formats, etc. > > That should be fine so long as the tagging in the XHTML is adequate to > recognize what each kind of feature is. Yes. We could add this when we need it (hardwired class names, extension attributes, or PIs). >> Indeed. The problem is that the RFC production center apparently likes >> the ability to micromanage vertical space and line breaks. That is a >> problem. I'm not convinced that they'd switch to any tool that gives >> them less control than nroff does today. > > Well, if we hire someone to rewrite it, there's something to put in > their checklist. It would probably be possible to use stylized comments > to give it hints to control line spacing or whatever else they're > fussing about while not screwing up the semantics of the XML. Based on > the experiments Paul H and I did when we were applying to be the RFC Ed, > it shouldn't be hard to make the tool smart enough to get the spacing > right on its own, although it would take a long time for the RFC Ed to > believe that. That's what I fear. Giving up control never is easy :-). >>>> XML --> (X)HTML --> TXT >>>> Would it be just as easy to produce PDF? >>>> XML --> (X)HTML --> PDF >>>> Or, would we continue to produce the PDF from the TXT? >>> >>> That's more a political than a technical question. A PDF made from the >>> TXT produces a printable version of the canonical text. A PDF made from >>> the XHTML makes a document that's a lot easier to read. >> >> Right. >> >> Just keep in mind that we already have a way to produce a printable >> version from TXT (via Henrik's rfcmarkup tool). > > Huh? rfcmarkup creates simple minded html with clickable links, not PDF. It creates HTML that prints like the original TXT was intended to print. That being said; printing is totally overrated, and we really should focus on what matters today (reflowable text, accessibility, display on ebooks come to mind). > ... Best regards, Julian From housley@vigilsec.com Mon Sep 27 07:19:48 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5F13A6BAF for ; Mon, 27 Sep 2010 07:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEY8nwQHoukf for ; Mon, 27 Sep 2010 07:19:47 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 005D93A6AFF for ; Mon, 27 Sep 2010 07:19:47 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 48538F24051; Mon, 27 Sep 2010 10:20:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id HP8BlFr45Ig6; Mon, 27 Sep 2010 10:20:24 -0400 (EDT) Received: from [69.50.101.149] (69-50-101-149.pingtone.net [69.50.101.149]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3C288F2403B; Mon, 27 Sep 2010 10:20:28 -0400 (EDT) Message-ID: <4CA0A82F.8000508@vigilsec.com> Date: Mon, 27 Sep 2010 10:20:31 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Julian Reschke References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4C9F847B.5070007@vigilsec.com> <4C9F8873.4070306@gmx.de> In-Reply-To: <4C9F8873.4070306@gmx.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 14:19:48 -0000 Julian: >> My question generated much less discussion than I expected. > > It wasn't unexpected to me; the original xml2rfc mailing list is a much > bigger audience, see > ; maybe we > should restart the thread over there. This is where the people that volunteered to maintain the code hang out, so this is the place we need to hold the discussion. If we need to invite others to join the list, that is fine. >> I gather that the current code is stored on tools.ietf.org but that >> there are some things that need to be handled in the current >> implementation before any further action is considered. I have not >> heard a plan to make them happen. > > I don't think there's anything that *needs* to be done. We (mainly Tony > Hansen and myself) generated a release last April. Since then nothing > major has happened, in particular the changes for the new RFC > boilerplate (as of Jan 2010) haven't been implemented yet. I would like to see the boilerplate updated as soon as possible. Does anyone have a feel for the level of effort to do it? >> Is anyone working on the TCL code base to fix >> ? >> It appears that no action has been taken in the last 5 months. > > That's a correct observation (Tony did some work during the last code > sprint, but that's it). > > The time I invest goes into rfc2629.xslt (which *does* have the > boilerplate changes implemented), but only generates HTML/XHTML, not > plain text. > >> We should also discuss a few things that Julian said: >> >>> - We do have a somewhat working TCL code base, which is hard to >>> maintain, and lacks people understanding TCL. It also suffers from a >>> prehistoric non-conforming XML-parser-like thingy being part of it. >> >> If ticket 6 is an indication, we have a serious maintenance problem. >> >>> - There is an XSLT implementation that transforms conforming source code >>> to (X)HTML. This one has been maintained by me for many years, and will >>> continue to be maintained. >>> >>> Formatting to TXT is tricky, and involves understanding the XML format, >>> the boilerplate issues, and also line-breaking, page-breaking and table >>> formatting. >>> >>> For everything *except* the TXT-specific there is working XSLT code. I'd >>> recommend writing a post-processor that takes its XHTML output, and >>> reformats that as plain text. To make this work well, we might have to >>> augment the XHTML with a few extensions (hard-wired class names maybe), >>> but I think that's superior to redoing the first part from scratch. >>> >>> If I would need to do that, I'd probably use Java. But any language that >>> can parse an XHTML document and which has decent string processing >>> should do. >> >> Is this a direction that makes sense to others? This leads to an >> architecture that produces the TXT file by: >> >> XML --> (X)HTML --> TXT > > Correct. Obviously you think this is a good idea. You proposed it. I really need to hear from others too. >> Would it b just as easy to produce PDF? >> >> XML --> (X)HTML --> PDF >> >> Or, would we continue to produce the PDF from the TXT? > > Producing PDF is a more or less (*) solved problem already, see > > for instructions, and for > an example. > > That being said: I'm not sure that we should invest time and money to > produce PDF..., good HTML seems to be way more important to me. Well, the RFC Editor and the tools site both offer PDF. I do not know if the two sites use the same tools to make the PDF files. Russ From julian.reschke@gmx.de Mon Sep 27 07:36:27 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0713A6D2B for ; Mon, 27 Sep 2010 07:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.842 X-Spam-Level: X-Spam-Status: No, score=-104.842 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XsnXHN3XfCB for ; Mon, 27 Sep 2010 07:36:25 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 174BD3A6D21 for ; Mon, 27 Sep 2010 07:36:24 -0700 (PDT) Received: (qmail invoked by alias); 27 Sep 2010 14:37:02 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.146]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 27 Sep 2010 16:37:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/OfZhaxRXO1ZhJZ8kDNdOZE2Hleaky9WaRGiDQkW 8n5RqkwfDzn8wf Message-ID: <4CA0AC0C.4060903@gmx.de> Date: Mon, 27 Sep 2010 16:37:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4C9F847B.5070007@vigilsec.com> <4C9F8873.4070306@gmx.de> <4CA0A82F.8000508@vigilsec.com> In-Reply-To: <4CA0A82F.8000508@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 14:36:27 -0000 On 27.09.2010 16:20, Russ Housley wrote: > ... >> I don't think there's anything that *needs* to be done. We (mainly Tony >> Hansen and myself) generated a release last April. Since then nothing >> major has happened, in particular the changes for the new RFC >> boilerplate (as of Jan 2010) haven't been implemented yet. > > I would like to see the boilerplate updated as soon as possible. Does > anyone have a feel for the level of effort to do it? > ... I think it'll take something like 3 days (which would include not only making the changes but also adding/reviewing test cases (*) and checking for regressions). One issue with the boilerplate change is that the new top left hand field for the stream source can be wider than what used to be accepted by xml2rfc without wrapping. If I recall correctly, I hacked the TCL code to make the left-hand side a few characters wider, but of course that will cause more wrapping on the right-hand side. Not sure whether this is acceptable, anything else (like a new balancing algorithm) will require more TCL skills than the other changes... > ... > Well, the RFC Editor and the tools site both offer PDF. I do not know > if the two sites use the same tools to make the PDF files. > ... As far as I recall, all tools that generate PDF today do that based on the TXT version, so if we change the way the TXT gets generated this will have zero effect. That being said, producing PDF from the TXT version is pretty pointless, except to make it possible to print. Producing PDF that actually takes advantage of the PDF format would be much more interesting, and is what "my" approach does... Best regards, Julian (*) Test cases may already be present from the work in spring. From tony@att.com Tue Sep 28 17:09:09 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27AD3A6E51 for ; Tue, 28 Sep 2010 17:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.367 X-Spam-Level: X-Spam-Status: No, score=-106.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFH1Oma89hzP for ; Tue, 28 Sep 2010 17:09:07 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 07C593A6E53 for ; Tue, 28 Sep 2010 17:08:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1285718964!27007956!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 21115 invoked from network); 29 Sep 2010 00:09:25 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 00:09:25 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8T09fvm025035 for ; Tue, 28 Sep 2010 20:09:41 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8T09dxV025016 for ; Tue, 28 Sep 2010 20:09:39 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8T09M5J024092 for ; Tue, 28 Sep 2010 20:09:22 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8T09Hci023986 for ; Tue, 28 Sep 2010 20:09:17 -0400 Received: from [135.70.228.42] (vpn-135-70-228-42.vpn.east.att.com[135.70.228.42]) by maillennium.att.com (mailgw1) with ESMTP id <20100929000916gw100ei1v7e> (Authid: tony); Wed, 29 Sep 2010 00:09:17 +0000 X-Originating-IP: [135.70.228.42] Message-ID: <4CA283AB.9090404@att.com> Date: Tue, 28 Sep 2010 20:09:15 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Julian Reschke References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> In-Reply-To: <4C913086.80605@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org, Russ Housley Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 00:09:09 -0000 My thoughts: Having paid people to work on the tools would be "a good thing". Moving the source code to yet another place is not needed: the current SVN repository is fine. We already have full source control. Moving the web address from xml.resource.org is not needed: it's already pointing at our servers. I think we will need two continuing advisory teams: one on coding issues and one on the xml2rfc input language issues. Some things we could do: Potentially move the web server to a different set of machines. I don't think it's necessary, but it's a possibility. Take Henrik out of the loop for approving releases before they get pushed out or make it possible for more people to approve releases so there's no single bottle neck. For the code: I like the idea of eliminating the TCL code base, particularly since no one in the current set of volunteers is a TCL guru. I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. No one's mentioned the generation of nroff -- I have problems gauging how important that is still. I think it's going to be mandatory until we get enough richness in the XML2RFC language for the RFC editor to be happy to eliminate nroff as their intermediary language. I'd be happy to talk about this in Beijing. Should we set up a meeting, say for Sunday afternoon? Or if people arrive early enough, during or after the code sprint? Tony On 9/15/2010 4:45 PM, Julian Reschke wrote: > On 15.09.2010 21:04, Russ Housley wrote: >> xml2rfc is a critical tool. As a result, we need to figure out how to >> migrate it to a place where paid IT folks are able to keep it working. I >> need your help to develop a plan to make that happen. I do not even >> know if it is easy or hard. > > I think it depends how ambitious you are. > > We moved everything to tools.ietf.org a few months ago, see > . > > It has a SVN repository and test cases, and can generate the files for > xml.resourc.org. > > What's missing is people working on the open issues. > >> I know that several people have been talking about the improvements >> needed to fully implement the recent headers and boilerplate changes. > > -> > >> Should that happen before the migration or after? > > Depends a bit on the RFC-Editor's requirements. > > My gut feeling is: > > - do the boilerplate changes in the current code > > - then figure out a mid-term strategy > > Also, don't move it. Maintain it in-place. > >> I know that several people have been talking about rewriting the tool. >> I assume that will happen after the migration. Is that a reasonable >> assumption? > > I'm not sure any migration is needed (after the work we did in March). > > So how *should* the mid-term look like? > > - We do have a somewhat working TCL code base, which is hard to > maintain, and lacks people understanding TCL. It also suffers from a > prehistoric non-conforming XML-parser-like thingy being part of it. > > - There is an XSLT implementation that transforms conforming source > code to (X)HTML. This one has been maintained by me for many years, > and will continue to be maintained. > > Formatting to TXT is tricky, and involves understanding the XML > format, the boilerplate issues, and also line-breaking, page-breaking > and table formatting. > > For everything *except* the TXT-specific there is working XSLT code. > I'd recommend writing a post-processor that takes its XHTML output, > and reformats that as plain text. To make this work well, we might > have to augment the XHTML with a few extensions (hard-wired class > names maybe), but I think that's superior to redoing the first part > from scratch. > > If I would need to do that, I'd probably use Java. But any language > that can parse an XHTML document and which has decent string > processing should do. > > Best regards, Julian > > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev From tony@att.com Tue Sep 28 19:09:20 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB8CE3A6BFC for ; Tue, 28 Sep 2010 19:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.376 X-Spam-Level: X-Spam-Status: No, score=-106.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj+Hi-r2BWBk for ; Tue, 28 Sep 2010 19:09:19 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 4D7293A6BF8 for ; Tue, 28 Sep 2010 19:09:19 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1285726200!37779541!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 2702 invoked from network); 29 Sep 2010 02:10:01 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 02:10:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8T2AHEM011799 for ; Tue, 28 Sep 2010 22:10:17 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8T2AEm8011786 for ; Tue, 28 Sep 2010 22:10:15 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8T29vwS030424 for ; Tue, 28 Sep 2010 22:09:57 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8T29tZC030407 for ; Tue, 28 Sep 2010 22:09:56 -0400 Received: from [135.70.228.42] (vpn-135-70-228-42.vpn.east.att.com[135.70.228.42]) by maillennium.att.com (mailgw1) with ESMTP id <20100929020954gw100ei1vhe> (Authid: tony); Wed, 29 Sep 2010 02:09:55 +0000 X-Originating-IP: [135.70.228.42] Message-ID: <4CA29FED.7020107@att.com> Date: Tue, 28 Sep 2010 22:09:49 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "John R. Levine" References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , Russ Housley , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 02:09:20 -0000 From my conversations with various rfc-editor people, the biggest thing they tweak in the nroff output is for widow and orphan control. That is, they may move a single line end of a paragraph that would otherwise show up by itself at the beginning of the next page (widow) to the end of the previous page. Or they may move a single line beginning of a paragraph that would otherwise show up by itself at the end of a page (orphan) to the beginning of the next page. I don't know if tweak anything to prevent orphan words (single word lines at the end of a paragraph). A random sampling of recent RFCs indicates that they don't. This would actually be a good feature for xml2rfc in general -- and if it did a good job at it, I think there would be less need for post processing tweaks. Alice, what other post processing tweaks are typical? Tony On 9/28/2010 9:56 PM, John R. Levine wrote: >> My thoughts: > > Executive summary: +1 > >> I like the idea of eliminating the TCL code base, particularly >> since no one in the current set of volunteers is a TCL guru. > > TCL was designed to be an application extension language, and doesn't > have characteristics like namespaces and modularity you want if your > application is going to be maintainable. Reasonable languages with > string handling, modularity, and well-maintained XML libraries include > perl, python, ruby, and Java. I'd suggest putting the priority on > finding suitable candidates for rewriting and ongoing maintenance, and > let them use whichever of those languages they are best at. > >> No one's mentioned the generation of nroff -- I have problems >> gauging how important that is still. I think it's going to be >> mandatory until we get enough richness in the XML2RFC language for >> the RFC editor to be happy to eliminate nroff as their intermediary >> language. > > I'd rather that the rewritten version not produce nroff, but instead > we have our rewriters engage the RFC Ed and find out what they > actually do with nroff and have the rewritten tool do it, too. I'd be > surprised if it were much more than forcing page breaks, inserting or > deleting blank lines, and perhaps line breaks. If we can get them to > do that, as we go forward we'll have definitive XML source for RFCs > which I hope people agree would be a good idea. > > R's, > John From johnl@iecc.com Tue Sep 28 18:56:11 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25443A6BBD for ; Tue, 28 Sep 2010 18:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.707 X-Spam-Level: X-Spam-Status: No, score=-109.707 tagged_above=-999 required=5 tests=[AWL=1.492, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jmYRLXY+uQR for ; Tue, 28 Sep 2010 18:56:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id CC1543A6AD8 for ; Tue, 28 Sep 2010 18:56:09 -0700 (PDT) Received: (qmail 3892 invoked from network); 29 Sep 2010 01:56:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1009; bh=S5koq10U3C4FSrN0rDgksSJEkrRa7BbfeLGEpt4tTRM=; b=Ebg0IhOCQ1bmM9AsMcTNtEuxRyNKnNCwn+Hg4b7lSXP2tMW2w7Zg802+T6fGCk6t0txdOdiysrMJEIRQKc0MH1pUGcNyptFhp6Vn3ENdwVAzmvPWficpZTXWDKcpwBDYY/NsEU5ThKdj+CvJcm/POAiszk43i+mJQODRvCCTYW0= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Sep 2010 01:56:28 -0000 Date: 28 Sep 2010 21:56:49 -0400 Message-ID: From: "John R. Levine" To: "Tony Hansen" In-Reply-To: <4CA283AB.9090404@att.com> References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 28 Sep 2010 19:13:44 -0700 Cc: Ray Pelletier , Russ Housley , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 01:56:11 -0000 > My thoughts: Executive summary: +1 > I like the idea of eliminating the TCL code base, particularly since no > one in the current set of volunteers is a TCL guru. TCL was designed to be an application extension language, and doesn't have characteristics like namespaces and modularity you want if your application is going to be maintainable. Reasonable languages with string handling, modularity, and well-maintained XML libraries include perl, python, ruby, and Java. I'd suggest putting the priority on finding suitable candidates for rewriting and ongoing maintenance, and let them use whichever of those languages they are best at. > No one's mentioned the generation of nroff -- I have problems gauging how > important that is still. I think it's going to be mandatory until we get > enough richness in the XML2RFC language for the RFC editor to be happy to > eliminate nroff as their intermediary language. I'd rather that the rewritten version not produce nroff, but instead we have our rewriters engage the RFC Ed and find out what they actually do with nroff and have the rewritten tool do it, too. I'd be surprised if it were much more than forcing page breaks, inserting or deleting blank lines, and perhaps line breaks. If we can get them to do that, as we go forward we'll have definitive XML source for RFCs which I hope people agree would be a good idea. R's, John From julian.reschke@gmx.de Wed Sep 29 00:09:38 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083883A6B23 for ; Wed, 29 Sep 2010 00:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.733 X-Spam-Level: X-Spam-Status: No, score=-103.733 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AbT2kmrI+5i for ; Wed, 29 Sep 2010 00:09:37 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A2D5F3A69F9 for ; Wed, 29 Sep 2010 00:09:36 -0700 (PDT) Received: (qmail invoked by alias); 29 Sep 2010 07:10:16 -0000 Received: from p508FB0B7.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.176.183] by mail.gmx.net (mp004) with SMTP; 29 Sep 2010 09:10:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19RtLM5F6RR8AaLOlJo3NMl/KUU8Frkz9ZUiILBeR SbI4mZ55oPiWNB Message-ID: <4CA2E653.8080009@gmx.de> Date: Wed, 29 Sep 2010 09:10:11 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Tony Hansen References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> In-Reply-To: <4CA283AB.9090404@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org, Russ Housley Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 07:09:38 -0000 On 29.09.2010 02:09, Tony Hansen wrote: > My thoughts: > > Having paid people to work on the tools would be "a good thing". In particular if we're talking about work that is solely done for the RFC Editor, like the remaining outstanding boilerplate changes. > ... > For the code: > > I like the idea of eliminating the TCL code base, particularly since no > one in the current set of volunteers is a TCL guru. > > I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. > > No one's mentioned the generation of nroff -- I have problems gauging > how important that is still. I think it's going to be mandatory until we > get enough richness in the XML2RFC language for the RFC editor to be > happy to eliminate nroff as their intermediary language. > ... Right. I keep forgetting about this. It's additional work, but may not be that much. As far as I recall, xml2rfc doesn't use nroff features for things like TOC or tables, so it's probably the same as the text output, with a few nroff directives added. > I'd be happy to talk about this in Beijing. Should we set up a meeting, > say for Sunday afternoon? Or if people arrive early enough, during or > after the code sprint? I may be able to participate remotely. Best regards, Julian From housley@vigilsec.com Wed Sep 29 06:12:57 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2EEC3A6B8E for ; Wed, 29 Sep 2010 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNEnERbjhYYM for ; Wed, 29 Sep 2010 06:12:55 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id EF3FF3A6833 for ; Wed, 29 Sep 2010 06:12:54 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 49854F24083; Wed, 29 Sep 2010 09:13:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id P4j7l-RG0BYa; Wed, 29 Sep 2010 09:13:36 -0400 (EDT) Received: from [192.168.27.115] (mail.pir.org [72.44.190.134]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D344EF24081; Wed, 29 Sep 2010 09:13:36 -0400 (EDT) Message-ID: <4CA33B81.8050206@vigilsec.com> Date: Wed, 29 Sep 2010 09:13:37 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Julian Reschke References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA2E653.8080009@gmx.de> In-Reply-To: <4CA2E653.8080009@gmx.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:12:57 -0000 Julian and Tony: >> I like the idea of eliminating the TCL code base, particularly since no >> one in the current set of volunteers is a TCL guru. >> >> I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. >> >> No one's mentioned the generation of nroff -- I have problems gauging >> how important that is still. I think it's going to be mandatory until we >> get enough richness in the XML2RFC language for the RFC editor to be >> happy to eliminate nroff as their intermediary language. >> ... > > Right. I keep forgetting about this. > > It's additional work, but may not be that much. As far as I recall, > xml2rfc doesn't use nroff features for things like TOC or tables, so > it's probably the same as the text output, with a few nroff directives > added. Are we really saying: XSLT -> XHMTL -> NROFF -> TXT Russ From julian.reschke@gmx.de Wed Sep 29 06:21:08 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 636DB3A6B9C for ; Wed, 29 Sep 2010 06:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.87 X-Spam-Level: X-Spam-Status: No, score=-104.87 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5iNjPzVo3e8 for ; Wed, 29 Sep 2010 06:21:07 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 00FBE3A6C63 for ; Wed, 29 Sep 2010 06:21:06 -0700 (PDT) Received: (qmail invoked by alias); 29 Sep 2010 13:21:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.146]) [217.91.35.233] by mail.gmx.net (mp018) with SMTP; 29 Sep 2010 15:21:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/D9WpY8KHDNWhuL7qbOat2vJGm5m++ZLN6vPHgzU 1fXkUOwd3bTC9L Message-ID: <4CA33D68.90101@gmx.de> Date: Wed, 29 Sep 2010 15:21:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA2E653.8080009@gmx.de> <4CA33B81.8050206@vigilsec.com> In-Reply-To: <4CA33B81.8050206@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 13:21:08 -0000 On 29.09.2010 15:13, Russ Housley wrote: > Julian and Tony: > >>> I like the idea of eliminating the TCL code base, particularly since no >>> one in the current set of volunteers is a TCL guru. >>> >>> I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. >>> >>> No one's mentioned the generation of nroff -- I have problems gauging >>> how important that is still. I think it's going to be mandatory until we >>> get enough richness in the XML2RFC language for the RFC editor to be >>> happy to eliminate nroff as their intermediary language. >>> ... >> >> Right. I keep forgetting about this. >> >> It's additional work, but may not be that much. As far as I recall, >> xml2rfc doesn't use nroff features for things like TOC or tables, so >> it's probably the same as the text output, with a few nroff directives >> added. > > Are we really saying: XSLT -> XHMTL -> NROFF -> TXT I think what we *should* do is stop at XHTML :-). There's little what *we* can do to change how the RFC Production Center works, maybe except forcing them to stop wasting time & money on micro-optimizations. *If* a tool would be written that re-uses the existing XSLT code, it could be an internal processing step, by default invisible. The user wouldn't even know it happened. Would it make sense to do a proof-of-concept, just implementing, let's say, paragraphs and section titles? Best regards, Julian From ahagens@amsl.com Wed Sep 29 07:25:47 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD6B3A6D08 for ; Wed, 29 Sep 2010 07:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKRXcltRN-q8 for ; Wed, 29 Sep 2010 07:25:46 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 9A3C03A6C36 for ; Wed, 29 Sep 2010 07:25:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 910F6E08C2 for ; Wed, 29 Sep 2010 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH-UWJKKiYVk for ; Wed, 29 Sep 2010 07:26:29 -0700 (PDT) Received: from tledinh-temp.pir.com (mail.pir.org [72.44.190.134]) by c1a.amsl.com (Postfix) with ESMTPSA id 4E437E08A3 for ; Wed, 29 Sep 2010 07:26:26 -0700 (PDT) From: Alice Hagens Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Sep 2010 10:26:27 -0400 References: To: XML Developer List Message-Id: <6BA1C5E4-6CEF-4607-8F76-59B8A6365D43@amsl.com> Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [xml2rfc-dev] Fwd: Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:25:47 -0000 [Forwarding because held by moderator.] Begin forwarded message: > From: Sandy Ginoza > Date: September 29, 2010 10:22:36 AM EDT > To: xml2rfc-dev@ietf.org > Cc: RSE , RFC Editor > Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org >=20 > Greetings All, >=20 > In reviewing this thread on the xml2rfc-dev list, we're sending = replies to various discussion points. Below is the summary of what we = think we've seen so far. Please see comments below for more detail. >=20 > Summary >=20 > Short term actions: >=20 > 1. update xml2rfc to handle Status of This Memo text and updated = header format >=20 > 2. RFC Editor continues to create and archive .nroff files=20 >=20 >=20 > Long term community discussion and RSE consideration: >=20 > 1. is there agreement to abandon .nroff files as the official archival = source file?=20 >=20 > 2. is .txt or .html output more important? i.e., focus on producing = printable docs vs online docs? >=20 > Thanks, > Sandy and Alice >=20 > --------------- >=20 > Julian Reschke wrote: >=20 >> So how *should* the mid-term look like? >>=20 >>=20 >> - We do have a somewhat working TCL code base, which is hard to = maintain, and lacks people understanding TCL. It also suffers from a = prehistoric non-conforming XML-parser-like thingy being part of it. >> - There is an XSLT implementation that transforms conforming source = code to (X)HTML. This one has been maintained by me for many years, and = will continue to be maintained. >> Formatting to TXT is tricky, and involves understanding the XML = format, the boilerplate issues, and also line-breaking, page-breaking = and table formatting. >> For everything *except* the TXT-specific there is working XSLT code. = I'd recommend writing a post-processor that takes its XHTML output, and = reformats that as plain text. To make this work well, we might have to = augment the XHTML with a few extensions (hard-wired class names maybe), = but I think that's superior to redoing the first part from scratch. >> If I would need to do that, I'd probably use Java. But any language = that can parse an XHTML document and which has decent string processing = should do. >=20 > Please note that the RFC Editor continues to archive .nroff files. We = understand that NROFF was chosen because it is a stable and simple = source format for all RFCs. Currently all RFCs have an archived NROFF = file; if the new xml2rfc does not generate NROFF, then there will not be = a uniform type of source file archived for all RFCs (since XML files = have not been used to create approximately 50% of the I-Ds that are = approved for publication as RFCs). >=20 >=20 > Julian Reschke wrote: >>> Are we really saying: XSLT -> XHMTL -> NROFF -> TXT >>=20 >> I think what we *should* do is stop at XHTML :-). >>=20 >> There's little what *we* can do to change how the RFC Production = Center works, maybe except forcing them to stop wasting time & money on = micro-optimizations. >>=20 >=20 > Could you provide examples? Perhaps you are referring to past = development of the rfcedstyle PI? >=20 > =46rom our point of view, the current requests for updates to handle = Status of This Memo text and headers per RFC 5741 and to insert page = breaks in decent locations are essential to creating the final text = output. >=20 >=20 >> *If* a tool would be written that re-uses the existing XSLT code, it = could be an internal processing step, by default invisible. The user = wouldn't even know it happened. >=20 > Meaning the nroff as an internal processing step, but available to the = RFC Editor for archival purposes? >=20 >=20 > Julian Reschke wrote:=20 >=20 >> Producing PDF is a more or less (*) solved problem already, see >> = = for instructions, and = for an example. >> That being said: I'm not sure that we should invest time and money to >> produce PDF..., good HTML seems to be way more important to me.=20 >=20 > The RFC Editor began to (and will continue to) post PDF files was so = users could print the files easily. We agree that the HTML versions = (created by rfcmarkup) that print nicely fill this need, but believe = it's still useful to provide PDF files. >=20 >=20 > John Levine wrote: >=20 >> It's hard to say whether it's easier to intuit the necessary = semantics from the XML or the XHTML. If we get someone to rewrite = xml2rfc, I think an important goal needs to be that it can produce = output that the RFC editor can use without post editing. If it can't, = they'll probably still want it to produce nroff. >=20 > Correct, if we cannot get the text correct without post-editing, we = will tweak the .nroff file to get the final output. We have been lucky = that xml2rfc creates .nroff files, as we would have experienced a = significant slowdown in production with the multiple boilerplate changes = and the yet-to-be-updated header format. Also, without an .nroff file, = the archived source file (.xml) would not have matched the published = document. >=20 >=20 > Julian Reschke wrote:=20 >=20 >> Indeed. The problem is that the RFC production center apparently = likes the ability to micromanage vertical space and line breaks. That is = a problem. I'm not convinced that they'd switch to any tool that gives = them less control than nroff does today.=20 >=20 > Controlling vertical space and line breaks is necessary to get nicely = formatted documents and avoid bad page and line breaks. We would be = willing to test and switch to a newer tool if the tool could easily = provide a means to insert page and line breaks. However, this = discussion ignores the question of whether we're moving away from the = historical archiving of .nroff files, as mentioned above. NROFF files = are the official source files of RFCs; the text files can be recreated = by the .nroff files verbatim. If the thought here is to eliminate = .nroff as the official source file, this portion of the discussion = should probably be moved to the rfc-interest list. =20 >=20 >=20 > John Levine wrote: >=20 >> Based on the experiments Paul H and I did when we were applying to be = the RFC Ed, it shouldn't be hard to make the tool smart enough to get = the spacing right on its own, although it would take a long time for the = RFC Ed to believe that.=20 >=20 > Again, we would be willing to test new tools available to us. We = would also be willing to switch tools if community consensus is reached = that .nroff is obsolete. >=20 >=20 > Julian Reshke wrote: >=20 >> That being said; printing is totally overrated, and we really should = focus on what matters today (reflowable text, accessibility, display on = ebooks come to mind).=20 >=20 > This seems to be a topic that requires community input. >=20 > As an fyi, we still receive requests for text files via email. There = are RFC readers that do not have such easy access to the online versions = of documents nor easy access to e-readers. >=20 >=20 > Russ Housley wrote: >> I would like to see the boilerplate updated as soon as possible. = Does >> anyone have a feel for the level of effort to do it?=20 >=20 > We agree; we would like to see xml2rfc updated to handle the new = header requirements and Status of This Memo text. >=20 >=20 > Russ Housley wrote: >=20 >> Well, the RFC Editor and the tools site both offer PDF. I do not = know >> if the two sites use the same tools to make the PDF files. >=20 > We use an in-house script to create the .pdf files; we believe Henrik = uses his own script. >=20 >=20 > Julian Reschke wrote: >=20 >> As far as I recall, all tools that generate PDF today do that based = on the TXT version, so if we change the way the TXT gets generated this = will have zero effect. >=20 > This is correct afaik. >=20 >=20 > Julian Reschke wrote: >=20 >> That being said, producing PDF from the TXT version is pretty = pointless, except to make it possible to print.=20 >=20 > Right - as mentioned, exactly the reason why the RFC Editor began to = produce the .pdf files was for printing purposes. >=20 >=20 > Tony Hansen wrote: >=20 >> No one's mentioned the generation of nroff -- I have problems gauging = how important that is still. I think it's going to be mandatory until we = get enough richness in the XML2RFC language for the RFC editor to be = happy to eliminate nroff as their intermediary language. >=20 > Eliminating the use of .nroff seems to require discussion with the = RSE, RSAG, and community. > (Rather than "intermediary", nroff is currently the archival source = format.)=20 >=20 >=20 > John Levine wrote:=20 >=20 >> I'd rather that the rewritten version not produce nroff, but instead = we have our rewriters engage the RFC Ed and find out what they actually = do with nroff and have the rewritten tool do it, too. I'd be surprised = if it were much more than forcing page breaks, inserting or deleting = blank lines, and perhaps line breaks. If we can get them to do that, as = we go forward we'll have definitive XML source for RFCs which I hope = people agree would be a good idea.=20 >=20 > We would be happy to work with the developer to define the formatting = parameters. Typically, the post-xml2rfc updates would be minimal. = However, with the headers and boilerplate changes, the post-xml2rfc = updates has been significant for every document published. In the = future, it would be nice to coordinate tool updates with the required = changes. From sginoza@amsl.com Wed Sep 29 07:22:10 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D804B3A6CEB for ; Wed, 29 Sep 2010 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNyUpGNJibzJ for ; Wed, 29 Sep 2010 07:22:07 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id B9A083A696D for ; Wed, 29 Sep 2010 07:22:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id B0B37E08B0; Wed, 29 Sep 2010 07:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0swBisKKhyyf; Wed, 29 Sep 2010 07:22:51 -0700 (PDT) Received: from isoclt-06.isoc.local (e5.c4b7d1.client.atlantech.net [209.183.196.229]) by c1a.amsl.com (Postfix) with ESMTPA id D1142E08A3; Wed, 29 Sep 2010 07:22:50 -0700 (PDT) From: Sandy Ginoza Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Sep 2010 07:22:36 -0700 Message-Id: To: xml2rfc-dev@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 29 Sep 2010 07:28:05 -0700 Cc: RSE , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:22:10 -0000 Greetings All, In reviewing this thread on the xml2rfc-dev list, we're sending replies = to various discussion points. Below is the summary of what we think = we've seen so far. Please see comments below for more detail. Summary Short term actions: 1. update xml2rfc to handle Status of This Memo text and updated header = format 2. RFC Editor continues to create and archive .nroff files=20 Long term community discussion and RSE consideration: 1. is there agreement to abandon .nroff files as the official archival = source file?=20 2. is .txt or .html output more important? i.e., focus on producing = printable docs vs online docs? Thanks, Sandy and Alice --------------- Julian Reschke wrote: > So how *should* the mid-term look like? >=20 >=20 > - We do have a somewhat working TCL code base, which is hard to = maintain, and lacks people understanding TCL. It also suffers from a = prehistoric non-conforming XML-parser-like thingy being part of it. > - There is an XSLT implementation that transforms conforming source = code to (X)HTML. This one has been maintained by me for many years, and = will continue to be maintained. > Formatting to TXT is tricky, and involves understanding the XML = format, the boilerplate issues, and also line-breaking, page-breaking = and table formatting. > For everything *except* the TXT-specific there is working XSLT code. = I'd recommend writing a post-processor that takes its XHTML output, and = reformats that as plain text. To make this work well, we might have to = augment the XHTML with a few extensions (hard-wired class names maybe), = but I think that's superior to redoing the first part from scratch. > If I would need to do that, I'd probably use Java. But any language = that can parse an XHTML document and which has decent string processing = should do. Please note that the RFC Editor continues to archive .nroff files. We = understand that NROFF was chosen because it is a stable and simple = source format for all RFCs. Currently all RFCs have an archived NROFF = file; if the new xml2rfc does not generate NROFF, then there will not be = a uniform type of source file archived for all RFCs (since XML files = have not been used to create approximately 50% of the I-Ds that are = approved for publication as RFCs). Julian Reschke wrote: >> Are we really saying: XSLT -> XHMTL -> NROFF -> TXT >=20 > I think what we *should* do is stop at XHTML :-). >=20 > There's little what *we* can do to change how the RFC Production = Center works, maybe except forcing them to stop wasting time & money on = micro-optimizations. >=20 Could you provide examples? Perhaps you are referring to past = development of the rfcedstyle PI? =46rom our point of view, the current requests for updates to handle = Status of This Memo text and headers per RFC 5741 and to insert page = breaks in decent locations are essential to creating the final text = output. > *If* a tool would be written that re-uses the existing XSLT code, it = could be an internal processing step, by default invisible. The user = wouldn't even know it happened. Meaning the nroff as an internal processing step, but available to the = RFC Editor for archival purposes? Julian Reschke wrote:=20 > Producing PDF is a more or less (*) solved problem already, see > = = for instructions, and = for an example. > That being said: I'm not sure that we should invest time and money to > produce PDF..., good HTML seems to be way more important to me.=20 The RFC Editor began to (and will continue to) post PDF files was so = users could print the files easily. We agree that the HTML versions = (created by rfcmarkup) that print nicely fill this need, but believe = it's still useful to provide PDF files. John Levine wrote: > It's hard to say whether it's easier to intuit the necessary semantics = from the XML or the XHTML. If we get someone to rewrite xml2rfc, I think = an important goal needs to be that it can produce output that the RFC = editor can use without post editing. If it can't, they'll probably still = want it to produce nroff. Correct, if we cannot get the text correct without post-editing, we will = tweak the .nroff file to get the final output. We have been lucky that = xml2rfc creates .nroff files, as we would have experienced a significant = slowdown in production with the multiple boilerplate changes and the = yet-to-be-updated header format. Also, without an .nroff file, the = archived source file (.xml) would not have matched the published = document. Julian Reschke wrote:=20 > Indeed. The problem is that the RFC production center apparently likes = the ability to micromanage vertical space and line breaks. That is a = problem. I'm not convinced that they'd switch to any tool that gives = them less control than nroff does today.=20 Controlling vertical space and line breaks is necessary to get nicely = formatted documents and avoid bad page and line breaks. We would be = willing to test and switch to a newer tool if the tool could easily = provide a means to insert page and line breaks. However, this = discussion ignores the question of whether we're moving away from the = historical archiving of .nroff files, as mentioned above. NROFF files = are the official source files of RFCs; the text files can be recreated = by the .nroff files verbatim. If the thought here is to eliminate = .nroff as the official source file, this portion of the discussion = should probably be moved to the rfc-interest list. =20 John Levine wrote: > Based on the experiments Paul H and I did when we were applying to be = the RFC Ed, it shouldn't be hard to make the tool smart enough to get = the spacing right on its own, although it would take a long time for the = RFC Ed to believe that.=20 Again, we would be willing to test new tools available to us. We would = also be willing to switch tools if community consensus is reached that = .nroff is obsolete. Julian Reshke wrote: > That being said; printing is totally overrated, and we really should = focus on what matters today (reflowable text, accessibility, display on = ebooks come to mind).=20 This seems to be a topic that requires community input. As an fyi, we still receive requests for text files via email. There = are RFC readers that do not have such easy access to the online versions = of documents nor easy access to e-readers. Russ Housley wrote: > I would like to see the boilerplate updated as soon as possible. Does > anyone have a feel for the level of effort to do it?=20 We agree; we would like to see xml2rfc updated to handle the new header = requirements and Status of This Memo text. Russ Housley wrote: > Well, the RFC Editor and the tools site both offer PDF. I do not know > if the two sites use the same tools to make the PDF files. We use an in-house script to create the .pdf files; we believe Henrik = uses his own script. Julian Reschke wrote: > As far as I recall, all tools that generate PDF today do that based on = the TXT version, so if we change the way the TXT gets generated this = will have zero effect. This is correct afaik. Julian Reschke wrote: > That being said, producing PDF from the TXT version is pretty = pointless, except to make it possible to print.=20 Right - as mentioned, exactly the reason why the RFC Editor began to = produce the .pdf files was for printing purposes. Tony Hansen wrote: > No one's mentioned the generation of nroff -- I have problems gauging = how important that is still. I think it's going to be mandatory until we = get enough richness in the XML2RFC language for the RFC editor to be = happy to eliminate nroff as their intermediary language. Eliminating the use of .nroff seems to require discussion with the RSE, = RSAG, and community. (Rather than "intermediary", nroff is currently the archival source = format.)=20 John Levine wrote:=20 > I'd rather that the rewritten version not produce nroff, but instead = we have our rewriters engage the RFC Ed and find out what they actually = do with nroff and have the rewritten tool do it, too. I'd be surprised = if it were much more than forcing page breaks, inserting or deleting = blank lines, and perhaps line breaks. If we can get them to do that, as = we go forward we'll have definitive XML source for RFCs which I hope = people agree would be a good idea.=20 We would be happy to work with the developer to define the formatting = parameters. Typically, the post-xml2rfc updates would be minimal. = However, with the headers and boilerplate changes, the post-xml2rfc = updates has been significant for every document published. In the = future, it would be nice to coordinate tool updates with the required = changes.= From julian.reschke@gmx.de Wed Sep 29 07:41:01 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4185C3A6B5E for ; Wed, 29 Sep 2010 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.229 X-Spam-Level: X-Spam-Status: No, score=-104.229 tagged_above=-999 required=5 tests=[AWL=-2.870, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIPVhR+Na+dx for ; Wed, 29 Sep 2010 07:41:00 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A28323A6CEB for ; Wed, 29 Sep 2010 07:40:59 -0700 (PDT) Received: (qmail invoked by alias); 29 Sep 2010 14:41:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.146]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 29 Sep 2010 16:41:42 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/la4R1vbrl51cbIDJjDckGEiGKel0qFX9Rt55O5r 80NLEFEHobs73J Message-ID: <4CA35020.40205@gmx.de> Date: Wed, 29 Sep 2010 16:41:36 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Sandy Ginoza References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: RSE , xml2rfc-dev@ietf.org, RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 14:41:01 -0000 Hi Sandy, thanks for the feedback and welcome to the list... On 29.09.2010 16:22, Sandy Ginoza wrote: > Greetings All, > > In reviewing this thread on the xml2rfc-dev list, we're sending replies to various discussion points. Below is the summary of what we think we've seen so far. Please see comments below for more detail. > > Summary > > Short term actions: > > 1. update xml2rfc to handle Status of This Memo text and updated header format > > 2. RFC Editor continues to create and archive .nroff files Note that xml2rfc (experimental) already handles the updated header format, with the caveat that the balancing of the columns was ...tweaked, because the publication stream can now get very wide. It would be interesting to know whether the current solution (making the left-hand-side wider) is acceptable. > Long term community discussion and RSE consideration: > > 1. is there agreement to abandon .nroff files as the official archival source file? Who can decide this? > 2. is .txt or .html output more important? i.e., focus on producing printable docs vs online docs? HTML prints better than TXT already. > ... > Could you provide examples? Perhaps you are referring to past development of the rfcedstyle PI? > ... Also compact/subcompact. In my latest RFC, this affected the indentations for Normative and Informative References. Also, I recall that a line break was moved somewhere else. >> From our point of view, the current requests for updates to handle Status of This Memo text and headers per RFC 5741 and to insert page breaks in decent locations are essential to creating the final text output. > > >> *If* a tool would be written that re-uses the existing XSLT code, it could be an internal processing step, by default invisible. The user wouldn't even know it happened. > > Meaning the nroff as an internal processing step, but available to the RFC Editor for archival purposes? No, the tool I'm thinking of would produce either (X)HTML, TXT or NROFF, and whatever it does so to get there would be hidden from the regular user (this was just to clarify that usually, people wouldn't need to know what's going on internally). > Julian Reschke wrote: > >> Indeed. The problem is that the RFC production center apparently likes the ability to micromanage vertical space and line breaks. That is a problem. I'm not convinced that they'd switch to any tool that gives them less control than nroff does today. > > Controlling vertical space and line breaks is necessary to get nicely formatted documents and avoid bad page and line breaks. We would be willing to test and switch to a newer tool if the tool could easily provide a means to insert page and line breaks. However, this discussion ignores the question of whether we're moving away from the historical archiving of .nroff files, as mentioned above. NROFF files are the official source files of RFCs; the text files can be recreated by the .nroff files verbatim. If the thought here is to eliminate .nroff as the official source file, this portion of the discussion should probably be moved to the rfc-interest list. I think this is part of the problem. Few people read RFCs in paginated form. We are optimizing for a minority. > Julian Reshke wrote: > >> That being said; printing is totally overrated, and we really should focus on what matters today (reflowable text, accessibility, display on ebooks come to mind). > > This seems to be a topic that requires community input. > > As an fyi, we still receive requests for text files via email. There are RFC readers that do not have such easy access to the online versions of documents nor easy access to e-readers. People having email, but not a web browser? Best regards, Julian From johnl@iecc.com Wed Sep 29 08:13:37 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7BD3A6EE0 for ; Wed, 29 Sep 2010 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.714 X-Spam-Level: X-Spam-Status: No, score=-109.714 tagged_above=-999 required=5 tests=[AWL=1.485, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2usx2Q6+zth for ; Wed, 29 Sep 2010 08:13:12 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 2D21D3A6B36 for ; Wed, 29 Sep 2010 08:13:11 -0700 (PDT) Received: (qmail 25465 invoked from network); 29 Sep 2010 15:13:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1009; bh=rGPhVMNCS5yk0z3yBGgD4aWtu8U4BxhG4IBwGupY49o=; b=zUENhPOH/uYJKDtS0BkmOE2UmAmWlIRVJILzIjUJcwIF3nCaa/fI4vJMVaptYr5rOxqTEH0H5GCrpduc1zqO3/k0i+C65013rrSlE7bVo3CpaVaMacbGwgtxyo22AM7SyFQgMOOJ1XYn/6WaOi5D83itG9xc0zd8CJL95fhW8HI= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Sep 2010 15:13:32 -0000 Date: 29 Sep 2010 11:13:53 -0400 Message-ID: From: "John R. Levine" To: "Russ Housley" In-Reply-To: <4CA33B81.8050206@vigilsec.com> References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA2E653.8080009@gmx.de> <4CA33B81.8050206@vigilsec.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:13:38 -0000 >> It's additional work, but may not be that much. As far as I recall, >> xml2rfc doesn't use nroff features for things like TOC or tables, so >> it's probably the same as the text output, with a few nroff directives >> added. > > Are we really saying: XSLT -> XHMTL -> NROFF -> TXT I hope not. nroff is a large chunk of code to insert for what is for most people negligible gain. Even worse, there are different versions of nroff that produce slightly different results. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor Please consider the environment before sending this e-mail. From tony@att.com Wed Sep 29 08:47:10 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42E63A6B38 for ; Wed, 29 Sep 2010 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.293 X-Spam-Level: X-Spam-Status: No, score=-106.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQKjKP1DYwM for ; Wed, 29 Sep 2010 08:47:09 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9FC653A6B2F for ; Wed, 29 Sep 2010 08:47:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1285775270!54641418!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 32563 invoked from network); 29 Sep 2010 15:47:51 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 15:47:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TFm7Ff003758 for ; Wed, 29 Sep 2010 11:48:07 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TFm0N0003652 for ; Wed, 29 Sep 2010 11:48:00 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8TFlh7u026494 for ; Wed, 29 Sep 2010 11:47:43 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8TFlcdx026405 for ; Wed, 29 Sep 2010 11:47:38 -0400 Received: from [135.91.110.251] (ds135-91-110-251.dhcps.ugn.att.com[135.91.110.251]) by maillennium.att.com (mailgw1) with ESMTP id <20100929154738gw100ei10oe> (Authid: tony); Wed, 29 Sep 2010 15:47:38 +0000 X-Originating-IP: [135.91.110.251] Message-ID: <4CA35F99.5090601@att.com> Date: Wed, 29 Sep 2010 11:47:37 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA2E653.8080009@gmx.de> <4CA33B81.8050206@vigilsec.com> In-Reply-To: <4CA33B81.8050206@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 15:47:10 -0000 On 9/29/2010 9:13 AM, Russ Housley wrote: > Are we really saying: XSLT -> XHMTL -> NROFF -> TXT Heavens forfend! Certainly not for the majority of users. The RFC editor uses nroff in order to do the final tweaking because it offers finer grained control. For example, if you set the page length to 100 lines but force the page breaks with .bp where you want the page breaks, then you can shorten or extend pages as needed to deal with widows and orphans. But normal users should never need nroff. Adding augmentations to the xml2rfc language that allow that finer grained control would be a useful addition, so that the RFC editor didn't *need* the nroff step. Tony From Glenn@RiverOnce.com Wed Sep 29 10:24:50 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4D73A6D5B for ; Wed, 29 Sep 2010 10:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.819 X-Spam-Level: X-Spam-Status: No, score=-101.819 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvD4I6AhhpRH for ; Wed, 29 Sep 2010 10:24:48 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by core3.amsl.com (Postfix) with ESMTP id C541F3A6D32 for ; Wed, 29 Sep 2010 10:24:48 -0700 (PDT) Received: from [10.0.1.2] (c-68-51-253-30.hsd1.fl.comcast.net [68.51.253.30]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id o8THPIx6029508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 10:25:20 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Glenn Kowack In-Reply-To: Date: Wed, 29 Sep 2010 13:25:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <356AB764-DD41-4667-87BE-B2DBFEEDE331@RiverOnce.com> References: To: Sandy Ginoza X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Wed, 29 Sep 2010 10:25:21 -0700 (PDT) X-Mailman-Approved-At: Wed, 29 Sep 2010 10:30:33 -0700 Cc: RSE , xml2rfc-dev@ietf.org, RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:24:50 -0000 Sandy et al, As this discussion develops, let's be sure review this internally = within the RFC Editor, say at our next meeting, before this goes too far = along toward looking like a decision. It may be appropriate to carry = this to the RSAG. More below. On Sep 29, 2010, at 10:22 AM, Sandy Ginoza wrote: > Greetings All, >=20 > In reviewing this thread on the xml2rfc-dev list, we're sending = replies to various discussion points. Below is the summary of what we = think we've seen so far. Please see comments below for more detail. >=20 > Summary >=20 > Short term actions: >=20 > 1. update xml2rfc to handle Status of This Memo text and updated = header format >=20 > 2. RFC Editor continues to create and archive .nroff files=20 >=20 >=20 > Long term community discussion and RSE consideration: >=20 > 1. is there agreement to abandon .nroff files as the official archival = source file? Phrasing a long-term discussion as "is there agreement to abandon?" = presupposes moving in this direction. Was that intended and do you = really think we're that far along? thanks, Glenn __ > 2. is .txt or .html output more important? i.e., focus on producing = printable docs vs online docs? >=20 > Thanks, > Sandy and Alice >=20 > --------------- >=20 > Julian Reschke wrote: >=20 >> So how *should* the mid-term look like? >>=20 >>=20 >> - We do have a somewhat working TCL code base, which is hard to = maintain, and lacks people understanding TCL. It also suffers from a = prehistoric non-conforming XML-parser-like thingy being part of it. >> - There is an XSLT implementation that transforms conforming source = code to (X)HTML. This one has been maintained by me for many years, and = will continue to be maintained. >> Formatting to TXT is tricky, and involves understanding the XML = format, the boilerplate issues, and also line-breaking, page-breaking = and table formatting. >> For everything *except* the TXT-specific there is working XSLT code. = I'd recommend writing a post-processor that takes its XHTML output, and = reformats that as plain text. To make this work well, we might have to = augment the XHTML with a few extensions (hard-wired class names maybe), = but I think that's superior to redoing the first part from scratch. >> If I would need to do that, I'd probably use Java. But any language = that can parse an XHTML document and which has decent string processing = should do. >=20 > Please note that the RFC Editor continues to archive .nroff files. We = understand that NROFF was chosen because it is a stable and simple = source format for all RFCs. Currently all RFCs have an archived NROFF = file; if the new xml2rfc does not generate NROFF, then there will not be = a uniform type of source file archived for all RFCs (since XML files = have not been used to create approximately 50% of the I-Ds that are = approved for publication as RFCs). >=20 >=20 > Julian Reschke wrote: >>> Are we really saying: XSLT -> XHMTL -> NROFF -> TXT >>=20 >> I think what we *should* do is stop at XHTML :-). >>=20 >> There's little what *we* can do to change how the RFC Production = Center works, maybe except forcing them to stop wasting time & money on = micro-optimizations. >>=20 >=20 > Could you provide examples? Perhaps you are referring to past = development of the rfcedstyle PI? >=20 >> =46rom our point of view, the current requests for updates to handle = Status of This Memo text and headers per RFC 5741 and to insert page = breaks in decent locations are essential to creating the final text = output. >=20 >=20 >> *If* a tool would be written that re-uses the existing XSLT code, it = could be an internal processing step, by default invisible. The user = wouldn't even know it happened. >=20 > Meaning the nroff as an internal processing step, but available to the = RFC Editor for archival purposes? >=20 >=20 > Julian Reschke wrote:=20 >=20 >> Producing PDF is a more or less (*) solved problem already, see >> = = for instructions, and = for an example. >> That being said: I'm not sure that we should invest time and money to >> produce PDF..., good HTML seems to be way more important to me.=20 >=20 > The RFC Editor began to (and will continue to) post PDF files was so = users could print the files easily. We agree that the HTML versions = (created by rfcmarkup) that print nicely fill this need, but believe = it's still useful to provide PDF files. >=20 >=20 > John Levine wrote: >=20 >> It's hard to say whether it's easier to intuit the necessary = semantics from the XML or the XHTML. If we get someone to rewrite = xml2rfc, I think an important goal needs to be that it can produce = output that the RFC editor can use without post editing. If it can't, = they'll probably still want it to produce nroff. >=20 > Correct, if we cannot get the text correct without post-editing, we = will tweak the .nroff file to get the final output. We have been lucky = that xml2rfc creates .nroff files, as we would have experienced a = significant slowdown in production with the multiple boilerplate changes = and the yet-to-be-updated header format. Also, without an .nroff file, = the archived source file (.xml) would not have matched the published = document. >=20 >=20 > Julian Reschke wrote:=20 >=20 >> Indeed. The problem is that the RFC production center apparently = likes the ability to micromanage vertical space and line breaks. That is = a problem. I'm not convinced that they'd switch to any tool that gives = them less control than nroff does today.=20 >=20 > Controlling vertical space and line breaks is necessary to get nicely = formatted documents and avoid bad page and line breaks. We would be = willing to test and switch to a newer tool if the tool could easily = provide a means to insert page and line breaks. However, this = discussion ignores the question of whether we're moving away from the = historical archiving of .nroff files, as mentioned above. NROFF files = are the official source files of RFCs; the text files can be recreated = by the .nroff files verbatim. If the thought here is to eliminate = .nroff as the official source file, this portion of the discussion = should probably be moved to the rfc-interest list. =20 >=20 >=20 > John Levine wrote: >=20 >> Based on the experiments Paul H and I did when we were applying to be = the RFC Ed, it shouldn't be hard to make the tool smart enough to get = the spacing right on its own, although it would take a long time for the = RFC Ed to believe that.=20 >=20 > Again, we would be willing to test new tools available to us. We = would also be willing to switch tools if community consensus is reached = that .nroff is obsolete. >=20 >=20 > Julian Reshke wrote: >=20 >> That being said; printing is totally overrated, and we really should = focus on what matters today (reflowable text, accessibility, display on = ebooks come to mind).=20 >=20 > This seems to be a topic that requires community input. >=20 > As an fyi, we still receive requests for text files via email. There = are RFC readers that do not have such easy access to the online versions = of documents nor easy access to e-readers. >=20 >=20 > Russ Housley wrote: >> I would like to see the boilerplate updated as soon as possible. = Does >> anyone have a feel for the level of effort to do it?=20 >=20 > We agree; we would like to see xml2rfc updated to handle the new = header requirements and Status of This Memo text. >=20 >=20 > Russ Housley wrote: >=20 >> Well, the RFC Editor and the tools site both offer PDF. I do not = know >> if the two sites use the same tools to make the PDF files. >=20 > We use an in-house script to create the .pdf files; we believe Henrik = uses his own script. >=20 >=20 > Julian Reschke wrote: >=20 >> As far as I recall, all tools that generate PDF today do that based = on the TXT version, so if we change the way the TXT gets generated this = will have zero effect. >=20 > This is correct afaik. >=20 >=20 > Julian Reschke wrote: >=20 >> That being said, producing PDF from the TXT version is pretty = pointless, except to make it possible to print.=20 >=20 > Right - as mentioned, exactly the reason why the RFC Editor began to = produce the .pdf files was for printing purposes. >=20 >=20 > Tony Hansen wrote: >=20 >> No one's mentioned the generation of nroff -- I have problems gauging = how important that is still. I think it's going to be mandatory until we = get enough richness in the XML2RFC language for the RFC editor to be = happy to eliminate nroff as their intermediary language. >=20 > Eliminating the use of .nroff seems to require discussion with the = RSE, RSAG, and community. > (Rather than "intermediary", nroff is currently the archival source = format.)=20 >=20 >=20 > John Levine wrote:=20 >=20 >> I'd rather that the rewritten version not produce nroff, but instead = we have our rewriters engage the RFC Ed and find out what they actually = do with nroff and have the rewritten tool do it, too. I'd be surprised = if it were much more than forcing page breaks, inserting or deleting = blank lines, and perhaps line breaks. If we can get them to do that, as = we go forward we'll have definitive XML source for RFCs which I hope = people agree would be a good idea.=20 >=20 > We would be happy to work with the developer to define the formatting = parameters. Typically, the post-xml2rfc updates would be minimal. = However, with the headers and boilerplate changes, the post-xml2rfc = updates has been significant for every document published. In the = future, it would be nice to coordinate tool updates with the required = changes. From Glenn@RiverOnce.com Wed Sep 29 10:51:02 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCDBD3A6BAE for ; Wed, 29 Sep 2010 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.777 X-Spam-Level: X-Spam-Status: No, score=-101.777 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLa0RrfxQMZN for ; Wed, 29 Sep 2010 10:51:01 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by core3.amsl.com (Postfix) with ESMTP id C1B3B3A6F1A for ; Wed, 29 Sep 2010 10:49:47 -0700 (PDT) Received: from [10.0.1.2] (c-68-51-253-30.hsd1.fl.comcast.net [68.51.253.30]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id o8THo5Tw029905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 10:50:09 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Glenn Kowack In-Reply-To: <4CA35020.40205@gmx.de> Date: Wed, 29 Sep 2010 13:50:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> References: <4CA35020.40205@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Wed, 29 Sep 2010 10:50:10 -0700 (PDT) Cc: RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:51:02 -0000 On Sep 29, 2010, at 10:41 AM, Julian Reschke wrote: > Hi Sandy, >=20 > thanks for the feedback and welcome to the list... >=20 > On 29.09.2010 16:22, Sandy Ginoza wrote: >> Greetings All, >>=20 >> In reviewing this thread on the xml2rfc-dev list, we're sending = replies to various discussion points. Below is the summary of what we = think we've seen so far. Please see comments below for more detail. >>=20 >> Summary >>=20 >> Short term actions: >>=20 >> 1. update xml2rfc to handle Status of This Memo text and updated = header format >>=20 >> 2. RFC Editor continues to create and archive .nroff files >=20 > Note that xml2rfc (experimental) already handles the updated header = format, with the caveat that the balancing of the columns was = ...tweaked, because the publication stream can now get very wide. >=20 > It would be interesting to know whether the current solution (making = the left-hand-side wider) is acceptable. >=20 >> Long term community discussion and RSE consideration: >>=20 >> 1. is there agreement to abandon .nroff files as the official = archival source file? >=20 > Who can decide this? Very important question. Not just who, but how. Sandy and Alice put = the right tone on this: long-term community discussion and RSE = consideration. Nroff has been around so long, we should be both very = deliberate and be sure the community has a chance to review and be = comfortable with this. If we were to go in this direction (which is = still hypothetical), we'd need to do something like this, after further = discussion: 1) RFC Editor (PC staff and RSE) should make a summary assessment and = recommendation after RSAG input. This should be transparent so the = community can provide input. An RSE committee (like the Citations = committee) is probably overkill, but if required, then we'd set one up. = We would invite community members to participate. 2) Sign-off by the RSE after full RSAG review. (I would expect their = broad support for this, or it's back to the drawing board.) 3) Posting for community review and feedback. 4) If it looks like a consensus is reached, then implement the changes = and defined, and call it out on the RFC-Editor site and current = practice. The IAB will be in the loop in case they want to review process or = consensus. The RSE should lead this process to be sure all important inputs and = voices are heard. Executing these steps might be 'lighter' than all = these steps imply; we'll make them as light or heavy as warranted. Thoughts? regards, Glenn ___ >=20 >> 2. is .txt or .html output more important? i.e., focus on producing = printable docs vs online docs? >=20 > HTML prints better than TXT already. >=20 >> ... >> Could you provide examples? Perhaps you are referring to past = development of the rfcedstyle PI? >> ... >=20 > Also compact/subcompact. In my latest RFC, this affected the = indentations for Normative and Informative References. Also, I recall = that a line break was moved somewhere else. >=20 >>> =46rom our point of view, the current requests for updates to handle = Status of This Memo text and headers per RFC 5741 and to insert page = breaks in decent locations are essential to creating the final text = output. >>=20 >>=20 >>> *If* a tool would be written that re-uses the existing XSLT code, it = could be an internal processing step, by default invisible. The user = wouldn't even know it happened. >>=20 >> Meaning the nroff as an internal processing step, but available to = the RFC Editor for archival purposes? >=20 > No, the tool I'm thinking of would produce either (X)HTML, TXT or = NROFF, and whatever it does so to get there would be hidden from the = regular user (this was just to clarify that usually, people wouldn't = need to know what's going on internally). >=20 >> Julian Reschke wrote: >>=20 >>> Indeed. The problem is that the RFC production center apparently = likes the ability to micromanage vertical space and line breaks. That is = a problem. I'm not convinced that they'd switch to any tool that gives = them less control than nroff does today. >>=20 >> Controlling vertical space and line breaks is necessary to get nicely = formatted documents and avoid bad page and line breaks. We would be = willing to test and switch to a newer tool if the tool could easily = provide a means to insert page and line breaks. However, this = discussion ignores the question of whether we're moving away from the = historical archiving of .nroff files, as mentioned above. NROFF files = are the official source files of RFCs; the text files can be recreated = by the .nroff files verbatim. If the thought here is to eliminate = .nroff as the official source file, this portion of the discussion = should probably be moved to the rfc-interest list. >=20 > I think this is part of the problem. Few people read RFCs in paginated = form. We are optimizing for a minority. >=20 >> Julian Reshke wrote: >>=20 >>> That being said; printing is totally overrated, and we really should = focus on what matters today (reflowable text, accessibility, display on = ebooks come to mind). >>=20 >> This seems to be a topic that requires community input. >>=20 >> As an fyi, we still receive requests for text files via email. There = are RFC readers that do not have such easy access to the online versions = of documents nor easy access to e-readers. >=20 > People having email, but not a web browser? >=20 > Best regards, Julian From housley@vigilsec.com Wed Sep 29 10:57:58 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAEA3A6C57 for ; Wed, 29 Sep 2010 10:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4Yyt8jeXxcf for ; Wed, 29 Sep 2010 10:57:57 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 4A9E93A6D14 for ; Wed, 29 Sep 2010 10:57:57 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 44668F2406F; Wed, 29 Sep 2010 13:58:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id fYmdYk4ZUkSc; Wed, 29 Sep 2010 13:58:35 -0400 (EDT) Received: from [192.168.27.115] (mail.pir.org [72.44.190.134]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 62199F2406A; Wed, 29 Sep 2010 13:58:56 -0400 (EDT) Message-ID: <4CA37E51.1060005@vigilsec.com> Date: Wed, 29 Sep 2010 13:58:41 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Tony Hansen References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> In-Reply-To: <4CA283AB.9090404@att.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 17:57:58 -0000 Tony: > My thoughts: > > Having paid people to work on the tools would be "a good thing". > > Moving the source code to yet another place is not needed: the > current SVN repository is fine. We already have full source control. > > Moving the web address from xml.resource.org is not needed: it's > already pointing at our servers. > > I think we will need two continuing advisory teams: one on coding > issues and one on the xml2rfc input language issues. I see that xml.resource.org is being redirected to tools.ietf.org. We can move it again if needed. Ultimately, we want it on a server that is operated by the Secretariat. They have availability requirements from the IAOC. I agree with the design advice structure that you suggest. > Some things we could do: > > Potentially move the web server to a different set of machines. I > don't think it's necessary, but it's a possibility. > > Take Henrik out of the loop for approving releases before they get > pushed out or make it possible for more people to approve releases so > there's no single bottle neck. I do not see Henrik as blocking, but rather facilitating. My view is that Henrik helped us get the tool moved off of xml.resource.org. That was really important and helpful. > For the code: > > I like the idea of eliminating the TCL code base, particularly since > no one in the current set of volunteers is a TCL guru. I agree. > I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. > > No one's mentioned the generation of nroff -- I have problems > gauging how important that is still. I think it's going to be mandatory > until we get enough richness in the XML2RFC language for the RFC editor > to be happy to eliminate nroff as their intermediary language. I see this a something that needs broader community discussion. We have several ways of generating HTML versions of RFCs, and the features that we get from rfcmarkup seem to be very useful for folks that read online. Obviously, offline reading is important too. Many eBook readers need paginated output. > I'd be happy to talk about this in Beijing. Should we set up a meeting, > say for Sunday afternoon? Or if people arrive early enough, during or > after the code sprint? Tony, do you have the cycles to make the boilerplate changes to the experimental version? Russ From tony@att.com Wed Sep 29 11:38:13 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990793A6DF1 for ; Wed, 29 Sep 2010 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.321 X-Spam-Level: X-Spam-Status: No, score=-106.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H7MN7THC9RX for ; Wed, 29 Sep 2010 11:38:05 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 4FAD83A6D71 for ; Wed, 29 Sep 2010 11:38:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-8.tower-161.messagelabs.com!1285785527!41818441!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 10539 invoked from network); 29 Sep 2010 18:38:48 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 18:38:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TId4Xd014324 for ; Wed, 29 Sep 2010 14:39:04 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TId2mk014277 for ; Wed, 29 Sep 2010 14:39:02 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8TIcjNk007640 for ; Wed, 29 Sep 2010 14:38:45 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o8TIcdbd007521 for ; Wed, 29 Sep 2010 14:38:40 -0400 Received: from [135.91.110.251] (ds135-91-110-251.dhcps.ugn.att.com[135.91.110.251]) by maillennium.att.com (mailgw1) with ESMTP id <20100929183839gw100ei11se> (Authid: tony); Wed, 29 Sep 2010 18:38:39 +0000 X-Originating-IP: [135.91.110.251] Message-ID: <4CA387AD.7090705@att.com> Date: Wed, 29 Sep 2010 14:38:37 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA37E51.1060005@vigilsec.com> In-Reply-To: <4CA37E51.1060005@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 18:38:13 -0000 On 9/29/2010 1:58 PM, Russ Housley wrote: > Tony: > >> My thoughts: >> >> Having paid people to work on the tools would be "a good thing". >> >> Moving the source code to yet another place is not needed: the >> current SVN repository is fine. We already have full source control. >> >> Moving the web address from xml.resource.org is not needed: it's >> already pointing at our servers. >> >> I think we will need two continuing advisory teams: one on coding >> issues and one on the xml2rfc input language issues. >> > I see that xml.resource.org is being redirected to tools.ietf.org. We > can move it again if needed. Ultimately, we want it on a server that is > operated by the Secretariat. They have availability requirements from > the IAOC. > I'd like to see things changed to be more of the model used by the datatracker.ietf.org. I agree that the DNS can be moved again. > I agree with the design advice structure that you suggest. > >> Some things we could do: >> >> Potentially move the web server to a different set of machines. I >> don't think it's necessary, but it's a possibility. >> >> Take Henrik out of the loop for approving releases before they get >> pushed out or make it possible for more people to approve releases so >> there's no single bottle neck. >> > I do not see Henrik as blocking, but rather facilitating. > > My view is that Henrik helped us get the tool moved off of > xml.resource.org. That was really important and helpful. > You misunderstand. Henrik is a wonderful facilitator, and was extremely helpful in getting the xml.resource.org tree consolidated on tools.ietf.org and put into svn. However, he *is* in the loop as the sole final approver for pushing new releases out to the web server, and it shouldn't be just him. >> For the code: >> >> I like the idea of eliminating the TCL code base, particularly since >> no one in the current set of volunteers is a TCL guru. >> > I agree. > > >> I find the idea of XSLT -> XHMTL -> TXT to be an intriguing idea. >> >> No one's mentioned the generation of nroff -- I have problems >> gauging how important that is still. I think it's going to be mandatory >> until we get enough richness in the XML2RFC language for the RFC editor >> to be happy to eliminate nroff as their intermediary language. >> > I see this a something that needs broader community discussion. We have > several ways of generating HTML versions of RFCs, and the features that > we get from rfcmarkup seem to be very useful for folks that read online. > Obviously, offline reading is important too. > > Many eBook readers need paginated output. > I think the only thing that needs broader community discussion is to find out if *anyone* other than the RFC editor uses the nroff output ability from xml2rfc. The use of the nroff format as the "master archive source format" has always been an internal matter within the RFC editor. Nowadays they keep the xml2rfc version if it's available, the nroff generated from that with subsequent tweaks to fix things like widows and orphans, and the text generated from the nroff. If they can generate the desired text directly from the xml2rfc source, they've told me they would be happy to just store the xml2rfc version and skip the tweaked nroff version. >> I'd be happy to talk about this in Beijing. Should we set up a meeting, >> say for Sunday afternoon? Or if people arrive early enough, during or >> after the code sprint? >> > Tony, do you have the cycles to make the boilerplate changes to the > experimental version? > We've been trying to get Syed to do so. If he is still unable to do so, doing it might be a good project for the code sprint day. Tony From julian.reschke@gmx.de Wed Sep 29 12:35:27 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DF73A6CB9 for ; Wed, 29 Sep 2010 12:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.711 X-Spam-Level: X-Spam-Status: No, score=-103.711 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O99TCHtu1GG for ; Wed, 29 Sep 2010 12:35:26 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6440D3A6C81 for ; Wed, 29 Sep 2010 12:35:25 -0700 (PDT) Received: (qmail invoked by alias); 29 Sep 2010 19:36:08 -0000 Received: from p508FB0B7.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.176.183] by mail.gmx.net (mp061) with SMTP; 29 Sep 2010 21:36:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9+IdgJ/29zPS/uK7pVaZ+Bkltwy+WMVEDbg1vui KrGM4KWbe3sEOY Message-ID: <4CA39521.3080606@gmx.de> Date: Wed, 29 Sep 2010 21:36:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Glenn Kowack References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> In-Reply-To: <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:35:27 -0000 On 29.09.2010 19:50, Glenn Kowack wrote: > Very important question. Not just who, but how. Sandy and Alice put the right tone on this: long-term community discussion and RSE consideration. Nroff has been around so long, we should be both very deliberate and be sure the community has a chance to review and be comfortable with this. If we were to go in this direction (which is still hypothetical), we'd need to do something like this, after further discussion: > > 1) RFC Editor (PC staff and RSE) should make a summary assessment and recommendation after RSAG input. This should be transparent so the community can provide input. An RSE committee (like the Citations committee) is probably overkill, but if required, then we'd set one up. We would invite community members to participate. > 2) Sign-off by the RSE after full RSAG review. (I would expect their broad support for this, or it's back to the drawing board.) > 3) Posting for community review and feedback. > 4) If it looks like a consensus is reached, then implement the changes and defined, and call it out on the RFC-Editor site and current practice. > > The IAB will be in the loop in case they want to review process or consensus. > The RSE should lead this process to be sure all important inputs and voices are heard. Executing these steps might be 'lighter' than all these steps imply; we'll make them as light or heavy as warranted. > > Thoughts? This sounds like an extremely expensive process for deciding on something that should be a matter specific to the RFC production center. Was there ever a community consensus that NROFF has any official role? Best regards, Julian From julian.reschke@gmx.de Wed Sep 29 12:40:24 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 431EB3A6D53 for ; Wed, 29 Sep 2010 12:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.701 X-Spam-Level: X-Spam-Status: No, score=-103.701 tagged_above=-999 required=5 tests=[AWL=-1.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxOddrMQTtB6 for ; Wed, 29 Sep 2010 12:40:23 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 9178B3A6CFC for ; Wed, 29 Sep 2010 12:40:22 -0700 (PDT) Received: (qmail invoked by alias); 29 Sep 2010 19:41:04 -0000 Received: from p508FB0B7.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.176.183] by mail.gmx.net (mp057) with SMTP; 29 Sep 2010 21:41:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18gAjg1by4gXsmgwzemUNWXWROfZzIU9jErh4gIk3 rvofRN5SkbA7RT Message-ID: <4CA3964A.1030504@gmx.de> Date: Wed, 29 Sep 2010 21:40:58 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Russ Housley References: <4C9118CF.2040500@vigilsec.com> <4C913086.80605@gmx.de> <4CA283AB.9090404@att.com> <4CA37E51.1060005@vigilsec.com> In-Reply-To: <4CA37E51.1060005@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Ray Pelletier , xml2rfc-dev@ietf.org Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:40:24 -0000 On 29.09.2010 19:58, Russ Housley wrote: > ... > I see this a something that needs broader community discussion. We have > several ways of generating HTML versions of RFCs, and the features that > we get from rfcmarkup seem to be very useful for folks that read online. > Obviously, offline reading is important too. > > Many eBook readers need paginated output. > ... Sorry? ePub is just (X)HTML + metadata in a ZIP container. >> I'd be happy to talk about this in Beijing. Should we set up a meeting, >> say for Sunday afternoon? Or if people arrive early enough, during or >> after the code sprint? > > Tony, do you have the cycles to make the boilerplate changes to the > experimental version? > ... If anybody wants to try that: the XSLT implementation already has this; it "just" needs to be translated into TCL: This memo documents an Internet Best Current Practice. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This document is not an Internet Standards Track specification; it is published for the historical record. This memo describes a historic protocol for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This is an Internet Standards Track document. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This document is not an Internet Standards Track specification; it is published for informational purposes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. UNSUPPORTED CATEGORY. This document defines an Experimental Protocol for the Internet community. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). It has been approved for publication by the Internet Engineering Steering Group (IESG). This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Research Group of the Internet Research Task Force (IRTF). This RFC represents the individual opinion(s) of one or more members of the Research Group of the Internet Research Task Force (IRTF). This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Further information on BCPs is available in Section 2 of RFC 5741. Further information on Internet Standards is available in Section 2 of RFC 5741. Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. IAB IRSG RFC Editor Documents approved for publication by the are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc. Best regards, Julian From Glenn@RiverOnce.com Wed Sep 29 12:51:25 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92013A6C7B for ; Wed, 29 Sep 2010 12:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSLofZvM5yAS for ; Wed, 29 Sep 2010 12:51:24 -0700 (PDT) Received: from sbh11.songbird.com (sbh11.songbird.com [72.52.113.11]) by core3.amsl.com (Postfix) with ESMTP id 99C9C3A6A94 for ; Wed, 29 Sep 2010 12:51:24 -0700 (PDT) Received: from [10.0.1.2] (c-68-51-253-30.hsd1.fl.comcast.net [68.51.253.30]) (authenticated bits=0) by sbh11.songbird.com (8.13.8/8.13.8) with ESMTP id o8TJpsSw032220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Sep 2010 12:51:55 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Glenn Kowack In-Reply-To: <4CA39521.3080606@gmx.de> Date: Wed, 29 Sep 2010 15:51:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh11.songbird.com [72.52.113.11]); Wed, 29 Sep 2010 12:51:56 -0700 (PDT) Cc: RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 19:51:26 -0000 On Sep 29, 2010, at 3:36 PM, Julian Reschke wrote: > On 29.09.2010 19:50, Glenn Kowack wrote: >> Very important question. Not just who, but how. Sandy and Alice put = the right tone on this: long-term community discussion and RSE = consideration. Nroff has been around so long, we should be both very = deliberate and be sure the community has a chance to review and be = comfortable with this. If we were to go in this direction (which is = still hypothetical), we'd need to do something like this, after further = discussion: >>=20 >> 1) RFC Editor (PC staff and RSE) should make a summary assessment = and recommendation after RSAG input. This should be transparent so the = community can provide input. An RSE committee (like the Citations = committee) is probably overkill, but if required, then we'd set one up. = We would invite community members to participate. >> 2) Sign-off by the RSE after full RSAG review. (I would expect = their broad support for this, or it's back to the drawing board.) >> 3) Posting for community review and feedback. >> 4) If it looks like a consensus is reached, then implement the = changes and defined, and call it out on the RFC-Editor site and current = practice. >>=20 >> The IAB will be in the loop in case they want to review process or = consensus. >> The RSE should lead this process to be sure all important inputs and = voices are heard. Executing these steps might be 'lighter' than all = these steps imply; we'll make them as light or heavy as warranted. >>=20 >> Thoughts? >=20 > This sounds like an extremely expensive process for deciding on = something that should be a matter specific to the RFC production center. >=20 > Was there ever a community consensus that NROFF has any official role? >=20 > Best regards, Julian Julian, Good point - the process is potentially weighty. However, the test = of how heavy to make the process is to see if anyone cares. If there's = no community interest or disagreement, then it goes very quickly and we = can drop particular steps. If not, we make the process correspondingly = extensive and deliberate. So, the right (short?) way forward is = available within my "soup to nuts" superset process. That said, what = does anyone on this thread think about nroff? Does anyone care? Re past community consensus about NROFF's role, I wasn't here for much = of that and would again like to here what anyone knows about the = history. thanks, Glenn From tony@att.com Wed Sep 29 13:13:36 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EFD3A6B49 for ; Wed, 29 Sep 2010 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+qa1gMwLdrF for ; Wed, 29 Sep 2010 13:13:34 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 0C08A3A6AF4 for ; Wed, 29 Sep 2010 13:13:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1285791256!39336237!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 14312 invoked from network); 29 Sep 2010 20:14:17 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 20:14:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TKDg9j020213 for ; Wed, 29 Sep 2010 16:13:42 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TKDcYV020115 for ; Wed, 29 Sep 2010 16:13:38 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o8TKECt7015340 for ; Wed, 29 Sep 2010 15:14:12 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o8TKE7ML015267 for ; Wed, 29 Sep 2010 15:14:07 -0500 Received: from [135.91.110.251] (ds135-91-110-251.dhcps.ugn.att.com[135.91.110.251]) by maillennium.att.com (mailgw1) with ESMTP id <20100929201406gw100ei12de> (Authid: tony); Wed, 29 Sep 2010 20:14:07 +0000 X-Originating-IP: [135.91.110.251] Message-ID: <4CA39E0E.5010202@att.com> Date: Wed, 29 Sep 2010 16:14:06 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Glenn Kowack References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: RSE , xml2rfc-dev@ietf.org, Sandy Ginoza , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:13:37 -0000 When talking about nroff, you have to be *very* specific as to which role you're referring to. 1) There are people who happily use nroff today to *generate* I-D's to give to the RFC Editor. I'm co-author on one doc where my co-author prefers it. This use is not affected by what we're discussing. 2) He should be able to send the nroff input to the RFC Editor, although I don't know that the RFC Editor has ever accepted nroff source files from random users. Sandy? Alice? If nroff source *is* accepted from users, this use should not be not affected by what we're discussing. 3) The RFC Editor stores a couple of source forms of the RFC as part of its archive. This has traditionally been the nroff source, but in recent years they've stored the XML2RFC source plus the tweaked version of the nroff. For RFCs that were not written in XML, I believe they also convert the text version into nroff and then back again in order to have the nroff version available. It's only use case #3 that is being discussed here -- the use of nroff by the RFC Editor as a required-internal archive format. Tony On 9/29/2010 3:51 PM, Glenn Kowack wrote: > On Sep 29, 2010, at 3:36 PM, Julian Reschke wrote: > > >> On 29.09.2010 19:50, Glenn Kowack wrote: >> >>> Very important question. Not just who, but how. Sandy and Alice put the right tone on this: long-term community discussion and RSE consideration. Nroff has been around so long, we should be both very deliberate and be sure the community has a chance to review and be comfortable with this. If we were to go in this direction (which is still hypothetical), we'd need to do something like this, after further discussion: >>> >>> 1) RFC Editor (PC staff and RSE) should make a summary assessment and recommendation after RSAG input. This should be transparent so the community can provide input. An RSE committee (like the Citations committee) is probably overkill, but if required, then we'd set one up. We would invite community members to participate. >>> 2) Sign-off by the RSE after full RSAG review. (I would expect their broad support for this, or it's back to the drawing board.) >>> 3) Posting for community review and feedback. >>> 4) If it looks like a consensus is reached, then implement the changes and defined, and call it out on the RFC-Editor site and current practice. >>> >>> The IAB will be in the loop in case they want to review process or consensus. >>> The RSE should lead this process to be sure all important inputs and voices are heard. Executing these steps might be 'lighter' than all these steps imply; we'll make them as light or heavy as warranted. >>> >>> Thoughts? >>> >> This sounds like an extremely expensive process for deciding on something that should be a matter specific to the RFC production center. >> >> Was there ever a community consensus that NROFF has any official role? >> >> Best regards, Julian >> > Julian, > Good point - the process is potentially weighty. However, the test of how heavy to make the process is to see if anyone cares. If there's no community interest or disagreement, then it goes very quickly and we can drop particular steps. If not, we make the process correspondingly extensive and deliberate. So, the right (short?) way forward is available within my "soup to nuts" superset process. That said, what does anyone on this thread think about nroff? Does anyone care? > > Re past community consensus about NROFF's role, I wasn't here for much of that and would again like to here what anyone knows about the history. > > thanks, > Glenn > From sginoza@amsl.com Wed Sep 29 13:51:06 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838683A6D27 for ; Wed, 29 Sep 2010 13:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBS483Cblrgp for ; Wed, 29 Sep 2010 13:51:03 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 55FE63A6D08 for ; Wed, 29 Sep 2010 13:51:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id E2066E08C2; Wed, 29 Sep 2010 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANDuZdqEaXXX; Wed, 29 Sep 2010 13:51:46 -0700 (PDT) Received: from isoc-lt02.isoc.local (e5.c4b7d1.client.atlantech.net [209.183.196.229]) by c1a.amsl.com (Postfix) with ESMTPA id 09EB8E08AC; Wed, 29 Sep 2010 13:51:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Sandy Ginoza In-Reply-To: <4CA39E0E.5010202@att.com> Date: Wed, 29 Sep 2010 13:51:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1081) Cc: RSE , xml2rfc-dev@ietf.org, Glenn Kowack , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 20:51:07 -0000 Thanks for providing the clarification Tony! Please see comments = in-line. On Sep 29, 2010, at 1:14 PM, Tony Hansen wrote: > When talking about nroff, you have to be *very* specific as to which = role you're referring to. >=20 > 1) There are people who happily use nroff today to *generate* I-D's to = give to the RFC Editor. I'm co-author on one doc where my co-author = prefers it. This use is not affected by what we're discussing. > 2) He should be able to send the nroff input to the RFC Editor, = although I don't know that the RFC Editor has ever accepted nroff source = files from random users. Sandy? Alice? If nroff source *is* accepted = from users, this use should not be not affected by what we're = discussing. Yes, we accept .nroff files from authors, and we would continue to = accept/use author submitted .nroff files as starting points for the = editing process. > 3) The RFC Editor stores a couple of source forms of the RFC as part = of its archive. This has traditionally been the nroff source, but in = recent years they've stored the XML2RFC source plus the tweaked version = of the nroff. For RFCs that were not written in XML, I believe they also = convert the text version into nroff and then back again in order to have = the nroff version available. >=20 > It's only use case #3 that is being discussed here -- the use of nroff = by the RFC Editor as a required-internal archive format. If an .xml file is submitted, we store the .xml and .nroff source files, = but .nroff if considered the official archival source file. Below is a summary of the conversion process for the various starting = points of the editing process. A) NROFF --> TXT B) TXT --> NROFF --> TXT C) XML --> NROFF --> TXT As Tony indicated, cases A and B would continue without change; the list = is only discussing case 3. =20 Moving away from having an .nroff source file in the near future seems = like a bad idea, as the output looks very different depending on whether = you are using an .xml or .nroff source file. Thanks, Sandy >=20 > Tony >=20 > On 9/29/2010 3:51 PM, Glenn Kowack wrote: >> On Sep 29, 2010, at 3:36 PM, Julian Reschke wrote: >>=20 >> =20 >>> On 29.09.2010 19:50, Glenn Kowack wrote: >>> =20 >>>> Very important question. Not just who, but how. Sandy and Alice = put the right tone on this: long-term community discussion and RSE = consideration. Nroff has been around so long, we should be both very = deliberate and be sure the community has a chance to review and be = comfortable with this. If we were to go in this direction (which is = still hypothetical), we'd need to do something like this, after further = discussion: >>>>=20 >>>> 1) RFC Editor (PC staff and RSE) should make a summary assessment = and recommendation after RSAG input. This should be transparent so the = community can provide input. An RSE committee (like the Citations = committee) is probably overkill, but if required, then we'd set one up. = We would invite community members to participate. >>>> 2) Sign-off by the RSE after full RSAG review. (I would expect = their broad support for this, or it's back to the drawing board.) >>>> 3) Posting for community review and feedback. >>>> 4) If it looks like a consensus is reached, then implement the = changes and defined, and call it out on the RFC-Editor site and current = practice. >>>>=20 >>>> The IAB will be in the loop in case they want to review process or = consensus. >>>> The RSE should lead this process to be sure all important inputs = and voices are heard. Executing these steps might be 'lighter' than all = these steps imply; we'll make them as light or heavy as warranted. >>>>=20 >>>> Thoughts? >>>> =20 >>> This sounds like an extremely expensive process for deciding on = something that should be a matter specific to the RFC production center. >>>=20 >>> Was there ever a community consensus that NROFF has any official = role? >>>=20 >>> Best regards, Julian >>> =20 >> Julian, >> Good point - the process is potentially weighty. However, the = test of how heavy to make the process is to see if anyone cares. If = there's no community interest or disagreement, then it goes very quickly = and we can drop particular steps. If not, we make the process = correspondingly extensive and deliberate. So, the right (short?) way = forward is available within my "soup to nuts" superset process. That = said, what does anyone on this thread think about nroff? Does anyone = care? >>=20 >> Re past community consensus about NROFF's role, I wasn't here for = much of that and would again like to here what anyone knows about the = history. >>=20 >> thanks, >> Glenn >> =20 >=20 From tony@att.com Wed Sep 29 14:16:08 2010 Return-Path: X-Original-To: xml2rfc-dev@core3.amsl.com Delivered-To: xml2rfc-dev@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E583A6DE0 for ; Wed, 29 Sep 2010 14:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.364 X-Spam-Level: X-Spam-Status: No, score=-106.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8899nSoVpDR for ; Wed, 29 Sep 2010 14:16:07 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 09A143A6DC7 for ; Wed, 29 Sep 2010 14:16:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1285795010!51336341!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16391 invoked from network); 29 Sep 2010 21:16:50 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Sep 2010 21:16:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TLGFFJ003070 for ; Wed, 29 Sep 2010 17:16:16 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o8TLGCJr003032 for ; Wed, 29 Sep 2010 17:16:12 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o8TLGkMA002257 for ; Wed, 29 Sep 2010 16:16:46 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o8TLGjq4002196 for ; Wed, 29 Sep 2010 16:16:45 -0500 Received: from [135.91.110.251] (ds135-91-110-251.dhcps.ugn.att.com[135.91.110.251]) by maillennium.att.com (mailgw1) with ESMTP id <20100929211644gw100ei12pe> (Authid: tony); Wed, 29 Sep 2010 21:16:44 +0000 X-Originating-IP: [135.91.110.251] Message-ID: <4CA3ACBB.30900@att.com> Date: Wed, 29 Sep 2010 17:16:43 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Sandy Ginoza References: <4CA35020.40205@gmx.de> <9BB36665-8FCF-4CFE-BC22-0594AF755221@RiverOnce.com> <4CA39521.3080606@gmx.de> <4CA39E0E.5010202@att.com> <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> In-Reply-To: <5C69EC65-216D-4989-AC3C-6D0E6CE1C8CE@amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: RSE , xml2rfc-dev@ietf.org, Glenn Kowack , RFC Editor Subject: Re: [xml2rfc-dev] Migration to ietf.org or rfc-editor.org X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion about particulars of xml2rfc development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 21:16:09 -0000 Thanks for the confirmation Sandy. This is going on a slight tangent to the other questions, but is directly relevant to the question of the evolution of the xml2rfc processor. I'd really like to understand better the differences you encounter using xml2rfc -> text vs xml2rfc -> nroff -> text. Also, do you do any post processing on the nroff output? Do you need to use post processing filters that eliminate backspaces or do other odd things? Tony On 9/29/2010 4:51 PM, Sandy Ginoza wrote: > Moving away from having an .nroff source file in the near future seems > like a bad idea, as the output looks very different depending on > whether you are using an .xml or .nroff source file.