, defaulting to allow breaks anywhere). For the last two cases the main use case is to make it easier for readers to have all of some critical part of the RFC available on the same page (e.g., security considerations text). In all of these cases the page break hints will be advisory (e.g., if some artwork does not fit on a page, it must be split), and non-critical (rendering can't fail if the break preference can't be met). Nico -- From nobody Thu Oct 23 18:01:21 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C11A8845 for ; Thu, 23 Oct 2014 18:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9EzbEzHraaI for ; Thu, 23 Oct 2014 18:01:16 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DC91A87F1 for ; Thu, 23 Oct 2014 18:01:16 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s9O11EZX024411 for ; Thu, 23 Oct 2014 18:01:15 -0700 Received: from vpn-135-70-100-25.vpn.swst.att.com ([135.70.100.25]) by maillennium.att.com (mailgw1) with ESMTP id <20141024010113gw100r93ase>; Fri, 24 Oct 2014 01:01:14 +0000 X-Originating-IP: [135.70.100.25] Message-ID: <5449A4D9.7030208@att.com> Date: Thu, 23 Oct 2014 21:01:13 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XML2RFC Interest Group Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/1bZCzV0DQn01xgzOT4XNyaeu2Yk Subject: [xml2rfc] getting past the conundrum X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 01:01:19 -0000 I think there's a couple points that need to be brought up about . *) is being deprecated from use. *) It is expected that NO deprecated elements will be allowed in actual RFC XML fils. (That's part of the definition of deprecated elements.) *) However, in the meantime, will still be available for use in I-Ds. I think we need some more experience with the V3 formatter to decide if there's anything in how is really being used that *) couldn't be done in other ways, or *) would make us rethink either that deprecation, or *) the need to provide better facilities for such. Tony Hansen From nobody Thu Oct 23 23:01:59 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F3D1A88C6 for ; Thu, 23 Oct 2014 23:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsnHUUmYUJ48 for ; Thu, 23 Oct 2014 23:01:54 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186231ACFC5 for ; Thu, 23 Oct 2014 23:01:52 -0700 (PDT) Received: from [192.168.2.160] ([84.187.32.111]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMCFR-1XkaDY2tsz-0083Du; Fri, 24 Oct 2014 08:01:41 +0200 Message-ID: <5449EB3D.1030502@gmx.de> Date: Fri, 24 Oct 2014 08:01:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Charlie Perkins References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> In-Reply-To: <544981C3.7090305@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2KeeRd6Nbox2a+sx9CdC7lQV4IHOSDoPLGHwxrrMIf1b3xzKUmX j/+uDd+HyQrlF5BAz0T2ASJGcs3kInOSNjKGgTP8pJ1X5LPaJXrn5Ao6sP1cXHeYnbJboOQ U4lf96ABGDVlpiXb6UExUynMbn/B0ZkS9qCpdbhwr6Up4ecGWspbl/RL7+U6Zg/QeaShHxs SWPeMB4pge9ckVltoZ9IQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/koS_IT0VT0bfFZYlFp-6lyMQ9FI Cc: XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 06:01:56 -0000 On 2014-10-24 00:31, Charlie Perkins wrote: > Hello Julian, > > For other use cases: > - I already mentioned that some lists belong on a single page Yes, and I believe the formatter has sufficient information already. > - Similarly a figure caption should be on the same page as the figure Yes. Why does the formatter need a hint for that? > - I prefer not to have a single line of a section alone on a page, > especially for short sections. If the section header appears > alone at the bottom of a page that is even worse. Again. No hint needed. > One way to find out the use cases is to have xml2rfc report > when people use page break, analyze the need, propose a > better solution, and verify with the document writer. I reckon > that darned near 100% of the writers would be glad to help, > and after a few months the temporary page break feature > could be removed. I'd prefer to do it exactly the other way around. Best regards, Julian From nobody Fri Oct 24 02:15:29 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36581AD943 for ; Fri, 24 Oct 2014 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tot0zCPbwk5w for ; Fri, 24 Oct 2014 02:15:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA141AD939 for ; Fri, 24 Oct 2014 02:15:26 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LqE5k-1YLJRC3NcO-00dr1G; Fri, 24 Oct 2014 11:15:22 +0200 Message-ID: <544A18A1.9050902@gmx.de> Date: Fri, 24 Oct 2014 11:15:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Nico Williams , Paul Hoffman References: <543FD40B.5030308@pi.nu> <543FE561.5040606@gmx.de> <543FF75F.5030303@isi.edu> <8B9CF456-84A8-4EA3-9222-6FDE546A9F80@tzi.org> <54402A8E.6050200@gmx.de> <5440E701.2020107@gmx.de> <54496AA8.5090109@alum.mit.edu> <2CDAF53C-04D5-4A5D-996F-C284B46A8B65@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3Sa9/SUuQ1pjuIHl8TXQSJhF/38zIiGJCwwmUl0bOXaTWOILuOD 3BX1h9rBp4HpMp9VrrP31GtVSQkaTkWcDWXDq2+Ybb/EJfbLmrwuIq1oSDCzS+uhYBjOjPS MY6ddbGxDieYZx4wZwg74zMbE2bQzaeVsoN5LvSTPG7y8CQddyoPCw7eFhchvCD2FVaRlKT Lljnx7i7pgMzF4e4nhY1Q== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/cdalZB30z5IThSpJ-sFBnZW3oxw Cc: XML2RFC Interest Group Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:15:27 -0000 On 2014-10-24 01:18, Nico Williams wrote: > On Thu, Oct 23, 2014 at 5:39 PM, Paul Hoffman wrote: >> Would this only be in and ? Or other places? > > Great question. These are the cases I can think of: > > - multi-paragraph list items: it may be better to break between items > than between paragraphs (this could be an attribute of the list and/or > list items, and the default could be to prefer breaking between > items); How frequently is this relevant in practice? > - tables: group the leading and trailing N rows so that one never > sees just one row on a page (this could be an attribute of the table > element though, and the default could be N=3 for tables with six or > more rows, N=2 for tables with four or five rows, and N= rows> for tables with fewer than four rows); Would we ever need something different from these defaults? > - and , indeed (this could be an attribute of > and ); An attribute saying what? > - paragraphs: try not to break in the middle of this paragraph (this > could be an attribute of , defaulting to allow breaks); What would be a case where you would try to avoid breaking inside a paragraph? > - groups of paragraphs: try not to break in the middle of these > paragraphs (this could be an element, or a list with no indentation > and no bullets, and just one multi-paragraph item); > > - general preference to break between paragraphs, never in the middle > of a paragraph (this could be an attribute of and

, > defaulting to allow breaks anywhere). > > For the last two cases the main use case is to make it easier for > readers to have all of some critical part of the RFC available on the > same page (e.g., security considerations text). That sounds like a fix to a problem that's caused by looking at paginated output in the first place :-) I have trouble seeing why certain sections need "keep-on-same-page" while others do not. The example of Security Considerations sounds very arbitrary to me. > In all of these cases the page break hints will be advisory (e.g., if > some artwork does not fit on a page, it must be split), and > non-critical (rendering can't fail if the break preference can't be > met). Of course. Best regards, Julian From nobody Fri Oct 24 02:42:08 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F381AD944 for ; Fri, 24 Oct 2014 02:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdmAEpU7KFIQ for ; Fri, 24 Oct 2014 02:42:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC961AD942 for ; Fri, 24 Oct 2014 02:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9O9fwkY014621; Fri, 24 Oct 2014 11:41:59 +0200 (CEST) Received: from [192.168.217.113] (p5489073F.dip0.t-ipconnect.de [84.137.7.63]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 59F4BD46; Fri, 24 Oct 2014 11:41:58 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <5449EB3D.1030502@gmx.de> Date: Fri, 24 Oct 2014 11:41:56 +0200 X-Mao-Original-Outgoing-Id: 435836516.405833-192b40db3f789682d27f1e708d5bfcb8 Content-Transfer-Encoding: quoted-printable Message-Id: <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/bUGDtz3GlRGq-g6_LdpdhVAXgOI Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:42:06 -0000 On 24 Oct 2014, at 08:01, Julian Reschke wrote: >=20 > No hint needed. A useful example to ponder may be draft-ietf-6lo-ghc-05 This would be much harder to read without the tweaks. Requiring the author to provide hints to a level of detail that makes = this manual intervention unnecessary doesn=E2=80=99t sound very = productive. (Yes, I have been drinking the =E2=80=9Cdeclarative = markup=E2=80=9D Kool-Aid since 1982. I just know it=E2=80=99s not = always the best way.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Oct 24 03:15:53 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3971B1A8AA2 for ; Fri, 24 Oct 2014 03:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEPa_iD-fMjy for ; Fri, 24 Oct 2014 03:15:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B121A88FA for ; Fri, 24 Oct 2014 03:15:43 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LpPg1-1YMjXc0kmz-00fBoP; Fri, 24 Oct 2014 12:15:25 +0200 Message-ID: <544A26B3.8020605@gmx.de> Date: Fri, 24 Oct 2014 12:15:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Carsten Bormann References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> In-Reply-To: <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ZI9vBCQF9RUKms48ZB2IeSX+LAeaqqWDlMZY6xSc1ZNXaZrYiw7 NPwOXYQIkyd41EweHSqgCIhhOoiJfsdLJqzLTgxNVJ3XlXekrpJd9i/tCyq7zTlOYDHC/Cv DGJwIIvm8PIAtR5iLy34o+W9cLiLDowu6KLmyyGjV5+Gij00mexHAqctUsYBDMDzQJcHHCi CY6j8tRApV8n7kc2OczKA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/_Y4Z40YHWUXX_DztpKH052-ArzU Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 10:15:46 -0000 On 2014-10-24 11:41, Carsten Bormann wrote: > On 24 Oct 2014, at 08:01, Julian Reschke wrote: >> >> No hint needed. > > A useful example to ponder may be draft-ietf-6lo-ghc-05 > > This would be much harder to read without the tweaks. > > Requiring the author to provide hints to a level of detail that makes this manual intervention unnecessary doesn’t sound very productive. (Yes, I have been drinking the “declarative markup” Kool-Aid since 1982. I just know it’s not always the best way.) Thanks for the concrete example. We're talking about the appendix, right? You can instruct xml2rfc (v1) to keep text together with artwork by moving it into . (Yes, tested) This however doesn't do what you want when the artwork alone would fit onto a page, but including the preamble, won't. In this case, xml2rfcv1 will keep the preamble on the same page as the artwork, but break the artwork. Is it more important to keep the preamble with the artwork, or to avoid breaking inside the artwork? In general, the more "unbreakable" things there are, the harder it is for the page breaking to do something useful without overrides. In this case, I'd probably reformat the examples into smaller chunks (v3 will allow multiple elements in one

). Best regards, Julian From nobody Fri Oct 24 03:35:54 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A81A88E6 for ; Fri, 24 Oct 2014 03:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59LbB6c-lM8C for ; Fri, 24 Oct 2014 03:35:44 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FBC1A8943 for ; Fri, 24 Oct 2014 03:35:44 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 91E4C180006E; Fri, 24 Oct 2014 12:35:42 +0200 (CEST) Message-ID: <544A2B7D.8010102@pi.nu> Date: Fri, 24 Oct 2014 12:35:41 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Carsten Bormann , Julian Reschke References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> In-Reply-To: <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/CT5IwtLJ4Urtp5FeYhPTKCWIg18 Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 10:35:52 -0000 Folks, The way I see this is that I don't particular care what is within the as long as it give me a line break and is not paragraph . Just one single element that gives me the the line break. I think I agree with most of what Julian says "not needed for RFC and final formatting". Though we have some cases where folks think it is useful. We need the xml to write RFCs and IDs, that is slightly different. I guess I've removed most of the elements when document is in its production form. But when developing the ID the is extremely useful. /Loa On 2014-10-24 11:41, Carsten Bormann wrote: > On 24 Oct 2014, at 08:01, Julian Reschke wrote: >> >> No hint needed. > > A useful example to ponder may be draft-ietf-6lo-ghc-05 > > This would be much harder to read without the tweaks. > > Requiring the author to provide hints to a level of detail that makes this manual intervention unnecessary doesn’t sound very productive. (Yes, I have been drinking the “declarative markup” Kool-Aid since 1982. I just know it’s not always the best way.) > > Grüße, Carsten > > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 24 04:00:45 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA71A89C4 for ; Fri, 24 Oct 2014 04:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XocvhzYT1kR6 for ; Fri, 24 Oct 2014 04:00:42 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403B31A038B for ; Fri, 24 Oct 2014 04:00:42 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9B64F180006E; Fri, 24 Oct 2014 13:00:40 +0200 (CEST) Message-ID: <544A3157.1080501@pi.nu> Date: Fri, 24 Oct 2014 13:00:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tony Hansen , XML2RFC Interest Group References: <5449A4D9.7030208@att.com> In-Reply-To: <5449A4D9.7030208@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/7Vgs_mWrPk3VjikJDFWOCnsxTqw Subject: Re: [xml2rfc] getting past the conundrum X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 11:00:43 -0000 Tony, I had not read this when I sent my previous mail. I think the formula - "not allowed in RFC files, but allowed in ID files" - works for me. Caveat - it could that some of the use cases that are not discussed turns out that is useful for RFC files also. But I don't think I have enough insight to have an opinion on that. /Loa On 2014-10-24 03:01, Tony Hansen wrote: > I think there's a couple points that need to be brought up about . > > *) is being deprecated from use. > > *) It is expected that NO deprecated elements will be allowed in actual > RFC XML fils. (That's part of the definition of deprecated elements.) > > *) However, in the meantime, will still be available for use > in I-Ds. > > I think we need some more experience with the V3 formatter to decide if > there's anything in how is really being used that > > *) couldn't be done in other ways, or > *) would make us rethink either that deprecation, or > *) the need to provide better facilities for such. > > Tony Hansen > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 24 04:03:32 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C111A89B5 for ; Fri, 24 Oct 2014 04:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOy_uJb2D7k5 for ; Fri, 24 Oct 2014 04:03:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B4F1A038B for ; Fri, 24 Oct 2014 04:03:29 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lh6sJ-1YUw1A28Ax-00oZ1r; Fri, 24 Oct 2014 13:03:19 +0200 Message-ID: <544A31ED.5040404@gmx.de> Date: Fri, 24 Oct 2014 13:03:09 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Loa Andersson , Carsten Bormann References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> <544A2B7D.8010102@pi.nu> In-Reply-To: <544A2B7D.8010102@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zR+J9uDJPFnUvg3ucsY8odrL45/Z9UMRexSRb7yV9zXP7Y/Ze7z W3BJl8b+98fi5B6cOlMhmDCWumSL0K0UY22allDzbnRq+WegMDhxNfq7yXDOYoGPML22W6y xtkOwrPTsxzs04vUuU45T2NQBYXpwxNPyKaLE71BNlWl8j6DsHZ3oiflkvrATY0haq1si3P EboYBDDueFEGsjyQHGUqw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/10XuzxdOOchVbw7rfmklHpRjtKk Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 11:03:31 -0000 On 2014-10-24 12:35, Loa Andersson wrote: > Folks, > > The way I see this is that I don't particular care what is > within the as long as it give me a line break and is > not paragraph . Just one single element that gives > me the the line break. > > I think I agree with most of what Julian says "not needed for RFC > and final formatting". Though we have some cases where folks think > it is useful. > > We need the xml to write RFCs and IDs, that is slightly different. > I guess I've removed most of the elements when document is > in its production form. > > But when developing the ID the is extremely > useful. > ... Can you explain why it's more useful "when developing"? Best regards, Julian From nobody Fri Oct 24 05:37:06 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5399C1A8AED for ; Fri, 24 Oct 2014 05:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wHhoQJYlNE9 for ; Fri, 24 Oct 2014 05:36:56 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810B41A8AE4 for ; Fri, 24 Oct 2014 05:36:56 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id s9OCar8s020716 for ; Fri, 24 Oct 2014 05:36:55 -0700 Received: from vpn-135-70-100-18.vpn.swst.att.com ([135.70.100.18]) by maillennium.att.com (mailgw1) with ESMTP id <20141024123652gw100r93ate>; Fri, 24 Oct 2014 12:36:52 +0000 X-Originating-IP: [135.70.100.18] Message-ID: <544A47E3.9050204@att.com> Date: Fri, 24 Oct 2014 08:36:51 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Loa Andersson , XML2RFC Interest Group References: <5449A4D9.7030208@att.com> <544A3157.1080501@pi.nu> In-Reply-To: <544A3157.1080501@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/wBfwCR5gz-QwpjjFoEu6cMPfZx0 Subject: Re: [xml2rfc] getting past the conundrum X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:37:03 -0000 One additional note: the plan for deprecated items is that they disappear in some future version of the grammar. Tony On 10/24/14, 7:00 AM, Loa Andersson wrote: > Tony, > > I had not read this when I sent my previous mail. > > I think the formula - "not allowed in RFC files, but allowed in ID > files" - works for me. > > Caveat - it could that some of the use cases that are not discussed > turns out that is useful for RFC files also. But I don't > think I have enough insight to have an opinion on that. > > /Loa > > On 2014-10-24 03:01, Tony Hansen wrote: >> I think there's a couple points that need to be brought up about >> . >> >> *) is being deprecated from use. >> >> *) It is expected that NO deprecated elements will be allowed in actual >> RFC XML fils. (That's part of the definition of deprecated elements.) >> >> *) However, in the meantime, will still be available for use >> in I-Ds. >> >> I think we need some more experience with the V3 formatter to decide if >> there's anything in how is really being used that >> >> *) couldn't be done in other ways, or >> *) would make us rethink either that deprecation, or >> *) the need to provide better facilities for such. >> >> Tony Hansen >> >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Fri Oct 24 06:54:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8871A001D for ; Fri, 24 Oct 2014 06:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDElObl-8HRd for ; Fri, 24 Oct 2014 06:54:18 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC87B1A0081 for ; Fri, 24 Oct 2014 06:54:18 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 25465180110A; Fri, 24 Oct 2014 15:54:17 +0200 (CEST) Message-ID: <544A5A07.6090401@pi.nu> Date: Fri, 24 Oct 2014 15:54:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tony Hansen , XML2RFC Interest Group References: <5449A4D9.7030208@att.com> <544A3157.1080501@pi.nu> <544A47E3.9050204@att.com> In-Reply-To: <544A47E3.9050204@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/0ckYHoLLU-S9XkjxLzHY6DsnmYw Subject: Re: [xml2rfc] getting past the conundrum X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:54:21 -0000 Tony, Does this mean that what is working for IDs early in the life if v3, will cease to work towards the end of its life time. This seems a bit ill-considered, if I write an ID where the grammar works and then return to it some arbitrary time later it will no longer work? /Loa On 2014-10-24 14:36, Tony Hansen wrote: > One additional note: the plan for deprecated items is that they > disappear in some future version of the grammar. > > Tony > > On 10/24/14, 7:00 AM, Loa Andersson wrote: >> Tony, >> >> I had not read this when I sent my previous mail. >> >> I think the formula - "not allowed in RFC files, but allowed in ID >> files" - works for me. >> >> Caveat - it could that some of the use cases that are not discussed >> turns out that is useful for RFC files also. But I don't >> think I have enough insight to have an opinion on that. >> >> /Loa >> >> On 2014-10-24 03:01, Tony Hansen wrote: >>> I think there's a couple points that need to be brought up about >>> . >>> >>> *) is being deprecated from use. >>> >>> *) It is expected that NO deprecated elements will be allowed in actual >>> RFC XML fils. (That's part of the definition of deprecated elements.) >>> >>> *) However, in the meantime, will still be available for use >>> in I-Ds. >>> >>> I think we need some more experience with the V3 formatter to decide if >>> there's anything in how is really being used that >>> >>> *) couldn't be done in other ways, or >>> *) would make us rethink either that deprecation, or >>> *) the need to provide better facilities for such. >>> >>> Tony Hansen >>> >>> _______________________________________________ >>> xml2rfc mailing list >>> xml2rfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/xml2rfc >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Oct 24 07:33:34 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E111A0125 for ; Fri, 24 Oct 2014 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtLxsJyR0kRK for ; Fri, 24 Oct 2014 07:33:29 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30EB1A0084 for ; Fri, 24 Oct 2014 07:33:29 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5 TLS/8.14.5) with ESMTP id s9OEXRNk024456 for ; Fri, 24 Oct 2014 07:33:29 -0700 Received: from vpn-135-70-100-18.vpn.swst.att.com ([135.70.100.18]) by maillennium.att.com (mailgw1) with ESMTP id <20141024143327gw100r93b1e>; Fri, 24 Oct 2014 14:33:27 +0000 X-Originating-IP: [135.70.100.18] Message-ID: <544A6336.7050907@att.com> Date: Fri, 24 Oct 2014 10:33:26 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: XML2RFC Interest Group References: <5449A4D9.7030208@att.com> <544A3157.1080501@pi.nu> <544A47E3.9050204@att.com> <544A5A07.6090401@pi.nu> In-Reply-To: <544A5A07.6090401@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/m6zZuzL2esKoHrpu4wWls4KkkRg Subject: Re: [xml2rfc] getting past the conundrum X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:33:32 -0000 Hmmm, we're talking past each other a bit. We do expect there to be some give and take on the v3 grammar while we work on the tools and cycle experience from the tools back into the grammar and vice versa. We would certainly try not to break anything in that process, and any breakage would be discussed prior. This is just like the work done in any of our working groups on protocol definitions. When the v3 definition is DONE, some tags and attributes from v2 will be listed as deprecated. Being marked as "deprecated" means a few things: *) The deprecated tag/attribute MAY be used in I-Ds. *) The deprecated tag/attribute will NOT be used in the files that the RFC editor publishes. *) The tools may generate warnings when a deprecated tag/attribute is used. (When the RFC editor uses the tools, they would instead produce errors.) *) A later version of grammar (version 4 or version 5, if such were ever to be done) would be free to remove the deprecated tag/attribute from the grammar and subsequent tools. A consequence of all this is that for any I-D that makes it to the stage where it is going to go to the RFC editor, any deprecated tag/attribute will need to be converted to a non-deprecated equivalent. I'm sure that the RFC editor would prefer that this replacement would occur much earlier in the process, such as before WG last call or before an I-D became accepted as a WG document. I'll send another message talking about the consequences of this with respect to . Tony On 10/24/14, 9:54 AM, Loa Andersson wrote: > Tony, > > Does this mean that what is working for IDs early in the life if v3, > will cease to work towards the end of its life time. > > This seems a bit ill-considered, if I write an ID where the grammar > works and then return to it some arbitrary time later it will no longer > work? > > /Loa > > On 2014-10-24 14:36, Tony Hansen wrote: >> One additional note: the plan for deprecated items is that they >> disappear in some future version of the grammar. >> >> Tony >> >> On 10/24/14, 7:00 AM, Loa Andersson wrote: >>> Tony, >>> >>> I had not read this when I sent my previous mail. >>> >>> I think the formula - "not allowed in RFC files, but allowed in ID >>> files" - works for me. >>> >>> Caveat - it could that some of the use cases that are not discussed >>> turns out that is useful for RFC files also. But I don't >>> think I have enough insight to have an opinion on that. >>> >>> /Loa >>> >>> On 2014-10-24 03:01, Tony Hansen wrote: >>>> I think there's a couple points that need to be brought up about >>>> . >>>> >>>> *) is being deprecated from use. >>>> >>>> *) It is expected that NO deprecated elements will be allowed in >>>> actual >>>> RFC XML fils. (That's part of the definition of deprecated elements.) >>>> >>>> *) However, in the meantime, will still be available for use >>>> in I-Ds. >>>> >>>> I think we need some more experience with the V3 formatter to >>>> decide if >>>> there's anything in how is really being used that >>>> >>>> *) couldn't be done in other ways, or >>>> *) would make us rethink either that deprecation, or >>>> *) the need to provide better facilities for such. >>>> >>>> Tony Hansen >>>> >>>> _______________________________________________ >>>> xml2rfc mailing list >>>> xml2rfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/xml2rfc >>> >> > From nobody Fri Oct 24 09:03:24 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8D01A1A7B for ; Fri, 24 Oct 2014 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.299 X-Spam-Level: ** X-Spam-Status: No, score=2.299 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_VISIT=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyPx0uABJuFK for ; Fri, 24 Oct 2014 08:36:05 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4EB1A1A79 for ; Fri, 24 Oct 2014 08:36:04 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-11v.sys.comcast.net with comcast id 73Zl1p00C2Bo0NV013c3Do; Fri, 24 Oct 2014 15:36:03 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-05v.sys.comcast.net with comcast id 73c01p00J1KKtkw013c1BH; Fri, 24 Oct 2014 15:36:03 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s9OFa0sR013895; Fri, 24 Oct 2014 11:36:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s9OFZxbb013893; Fri, 24 Oct 2014 11:35:59 -0400 Date: Fri, 24 Oct 2014 11:35:59 -0400 Message-Id: <201410241535.s9OFZxbb013893@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: xml2rfc@ietf.org, rfc-interest@rfc-editor.org In-reply-to: (nico@cryptonector.com) References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414164963; bh=H0RoHSboaiLkPsD/doUPbEm0AQMG4ytvJ1GuBMI8s4c=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=WbTio1TsLuWNPn6p3YyuxN6ahfm0zgOX+qXpVcg3H5c3gzCrVhqdS7jEGqZDS2CnZ mBB2DMJCSGGQotCkWvygls+hutizUrDYrMLAOrUjLT3rAb+kOFbHsBGVXbJcKgiMEb NlCgu2qbsoqiG0LwFOv3rkNyeQJAvjIXg1uMfE/xQQS2Hn57ilWvxRxtjbG+VafOpb yt86i6h+ZncK4XPGYAf0JciNMbIzG13EWNfvZLM/Z8YSsrnboJzLSkxGzJWpuYpGLE uhqNQIMjzuZWxXFI5NP4z22iA2aFn/W9w8iHd6l8eCmhomXHZIlykIZ+1wGIVmvAw0 iGTiSRmZ6JnPA== Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/BhqOiwbez_rLnJe0ptZipkALR4c X-Mailman-Approved-At: Fri, 24 Oct 2014 09:03:22 -0700 Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:36:06 -0000 > > Again: use case? > > The use cases were given, but they aren't use cases for "vertical > blank space". They are use cases for other things: > > - multi-paragraph list items (I forget if in v3 the schema supports > this properly) [etc.] This being the universe of computers, we've been down this road before. Viz., it comes time to reform some part of the universe, and for all sorts of good reasons, the Great New Thing incorporates all and only the things that we have good arguments for. For instance, we stopped writing system software in assember and started writing it in Pascal, which was carefully designed to let you express the things you should be able to express and not express the things you shouldn't. Then we suddenly discover that there are things we need to express that we really *shouldn't* have to express, but somehow we *do* have to express. For instance, people quckly found that Pascal doesn't let you do those tricky, ugly little things that save so much processing if you can just do the trick once in 10,000 lines of code. The result is we write our system software in C, which lets you do as those horrible tricks, not Pascal. The real test of a new vocabulary is to rewrite a large sample of documents in the new vocabulary and *see what breaks*. Because if you don't test it in reality, you can easily be designing the next Pascal. Dale From nobody Fri Oct 24 09:07:30 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158181A1BAE for ; Fri, 24 Oct 2014 09:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDG9UU7DziXU for ; Fri, 24 Oct 2014 09:07:28 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7001A1BAC for ; Fri, 24 Oct 2014 09:07:28 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 4195B20047B8E for ; Fri, 24 Oct 2014 09:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0rweTST/xSqimk6BnvTs Er1ecIY=; b=SBOMp4uvWODLe9wmeHqOTFiHZHjYTPYENj92qqDmVDF7pHL783q1 JnUTFnvv3az3n9HoDSGARbS+hYH1ga+4uKoG+EBKhleMxAXW3FgSPQTW82RdmxKE X5Vj4s7GxbZK7Njb+xUhaM1tkUe4Nu+raT0riRkfz+BE9P4hTdpkYzw= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPSA id EBAFA20047B8A for ; Fri, 24 Oct 2014 09:07:25 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so1430814wgh.12 for ; Fri, 24 Oct 2014 09:07:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.8.98 with SMTP id dj2mr5051902wid.70.1414166844697; Fri, 24 Oct 2014 09:07:24 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Fri, 24 Oct 2014 09:07:24 -0700 (PDT) In-Reply-To: <201410241535.s9OFZxbb013893@hobgoblin.ariadne.com> References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <201410241535.s9OFZxbb013893@hobgoblin.ariadne.com> Date: Fri, 24 Oct 2014 11:07:24 -0500 Message-ID: From: Nico Williams To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/SxTm3BMjj6E-dp3GjXBnYnYRrik Cc: XML2RFC Interest Group , RFC Interest Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:07:29 -0000 On Fri, Oct 24, 2014 at 10:35 AM, Dale R. Worley wrote: > The real test of a new vocabulary is to rewrite a large sample of > documents in the new vocabulary and *see what breaks*. Because if you > don't test it in reality, you can easily be designing the next Pascal. This is not a completely objective test because "what breaks" is a matter of subjective opinion. We're having this [recurring] debate precisely because the matter is subjective, and reasonable people can disagree as to "what breaks". Nico -- From nobody Fri Oct 24 09:48:20 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875FC1A86E0 for ; Fri, 24 Oct 2014 09:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1fZeI73cB-7 for ; Fri, 24 Oct 2014 09:48:17 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id DBB471A7002 for ; Fri, 24 Oct 2014 09:47:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XOB3ng+kCE4y4OKBECIuRs2SPI2NIag22/nGNLA5aI0PKufF3tW/2AW12ZBrooVP; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Xhi1n-0005of-DQ; Fri, 24 Oct 2014 12:47:51 -0400 Message-ID: <544A82B5.7090305@earthlink.net> Date: Fri, 24 Oct 2014 09:47:49 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Julian Reschke References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> In-Reply-To: <5449EB3D.1030502@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac77ca9c2bc3050d9ab446f51051b408b1f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/IxrBbBDxhr3DLYiNveduX7-lgcM Cc: XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:48:18 -0000 Hello Julian, My suggestion to allow page break was exactly for the reason that it's sometimes difficult to predict when one might need it, and a few months of using the new system but including the page break might be long enough to uncover the other use cases I didn't mention. On 10/23/2014 11:01 PM, Julian Reschke wrote: > On 2014-10-24 00:31, Charlie Perkins wrote: >> >> For other use cases: >> - I already mentioned that some lists belong on a single page > > Yes, and I believe the formatter has sufficient information already. Could you provide one sentence that describes the algorithm and what information it uses? > >> - Similarly a figure caption should be on the same page as the figure > > Yes. Why does the formatter need a hint for that? > >> - I prefer not to have a single line of a section alone on a page, >> especially for short sections. If the section header appears >> alone at the bottom of a page that is even worse. > > Again. No hint needed. It sounds to me like these will not be a problem -- good to hear that. > >> One way to find out the use cases is to have xml2rfc report >> when people use page break, analyze the need, propose a >> better solution, and verify with the document writer. I reckon >> that darned near 100% of the writers would be glad to help, >> and after a few months the temporary page break feature >> could be removed. > > I'd prefer to do it exactly the other way around. Yes, that is clear. I only suggested it because prediction is much much harder than hindsight. Regards, Charlie P. From nobody Fri Oct 24 10:07:56 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BAC1A882B for ; Fri, 24 Oct 2014 10:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bLpVTCkDqRi for ; Fri, 24 Oct 2014 10:07:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EAB81A87C7 for ; Fri, 24 Oct 2014 10:02:53 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M6wWn-1Y52494BJl-00wihc; Fri, 24 Oct 2014 19:02:47 +0200 Message-ID: <544A8627.1090501@gmx.de> Date: Fri, 24 Oct 2014 19:02:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Charlie Perkins References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <544A82B5.7090305@earthlink.net> In-Reply-To: <544A82B5.7090305@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:k/rC20Ukl8nOCejV89mSl3DhepB0n9hdh9VDddWkp1YA7PAxn/h 9B4hgLwLF7AEp26M5t5j2NwpyUoj8MHPpBpsBED+D4WNebbPpQE+adC4NATrL0MFxi0K2cE /m4QHXWNjaS+1hVf6O/LvGRlJ3aWpLf6mbuoU7Yj8A2TPe9bt3IDE3o1w8Mf43KTu8DgnzD R+7SfKRrYuYUqqLQQyJ1A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/gzn_-fISPLHo6L7XftuAFXjMTP8 Cc: XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:07:49 -0000 On 2014-10-24 18:47, Charlie Perkins wrote: > Hello Julian, > > My suggestion to allow page break was exactly for the > reason that it's sometimes difficult to predict when one > might need it, and a few months of using the new > system but including the page break might be long enough > to uncover the other use cases I didn't mention. > > On 10/23/2014 11:01 PM, Julian Reschke wrote: >> On 2014-10-24 00:31, Charlie Perkins wrote: >>> >>> For other use cases: >>> - I already mentioned that some lists belong on a single page >> >> Yes, and I believe the formatter has sufficient information already. > > Could you provide one sentence that describes the algorithm and > what information it uses? No, because I don't know the internals of the current formatter. You may want to look up the source code (it's on tools.ietf.org). > ... Best regards, Julian From nobody Fri Oct 24 10:14:19 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC41A8735 for ; Fri, 24 Oct 2014 10:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_VISIT=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2FjFrKxvSqV for ; Fri, 24 Oct 2014 10:14:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94BD1A8733 for ; Fri, 24 Oct 2014 10:14:10 -0700 (PDT) Received: from [192.168.1.26] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0La2Xx-1YOmUk1wBZ-00lpwI; Fri, 24 Oct 2014 19:14:07 +0200 Message-ID: <544A88D3.7070209@gmx.de> Date: Fri, 24 Oct 2014 19:13:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Dale R. Worley" , xml2rfc@ietf.org, rfc-interest@rfc-editor.org References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <201410241535.s9OFZxbb013893@hobgoblin.ariadne.com> In-Reply-To: <201410241535.s9OFZxbb013893@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YR4tPw/uZFKmAa80MhQRPF3lEbeCFH7fpNN3XqUYm6IuuMZ2ksE 1NdxvdNxu1lWlLAD4VgS0FLSnR44mlrmYi/0uxbuxns8XrEh3qfeJe/cReJ3xa+EIuACmBt WWywm4sZDE3CfJugHFeD+ktnvOBTZzeEJx4wJ+3oTf2vBAVmVxWdiLxzIFFHaukES9WI5R5 lMUspPpeulkXxRiHMgdlA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/0j-U70wGnTTVrssCCTnsqW6oHBw Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 17:14:12 -0000 On 2014-10-24 17:35, Dale R. Worley wrote: > ... > This being the universe of computers, we've been down this road > before. Viz., it comes time to reform some part of the universe, and > for all sorts of good reasons, the Great New Thing incorporates all > and only the things that we have good arguments for. For instance, we > stopped writing system software in assember and started writing it in > Pascal, which was carefully designed to let you express the things you > should be able to express and not express the things you shouldn't. > > Then we suddenly discover that there are things we need to express > that we really *shouldn't* have to express, but somehow we *do* have > to express. For instance, people quckly found that Pascal doesn't let > you do those tricky, ugly little things that save so much processing > if you can just do the trick once in 10,000 lines of code. The result > is we write our system software in C, which lets you do as those > horrible tricks, not Pascal. > > The real test of a new vocabulary is to rewrite a large sample of > documents in the new vocabulary and *see what breaks*. Because if you > don't test it in reality, you can easily be designing the next Pascal. > > Dale > ... Hint: there already is a conversion tool (written by Tony). Best regards, Julian From nobody Sat Oct 25 07:25:58 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A056F1A0040 for ; Sat, 25 Oct 2014 07:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFmStFU7xJDG for ; Sat, 25 Oct 2014 07:25:55 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3C01A0033 for ; Sat, 25 Oct 2014 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s9PEPiQK013629; Sat, 25 Oct 2014 16:25:44 +0200 (CEST) Received: from [192.168.217.113] (p5489011D.dip0.t-ipconnect.de [84.137.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4B569403; Sat, 25 Oct 2014 16:25:40 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Carsten Bormann In-Reply-To: <544A26B3.8020605@gmx.de> Date: Sat, 25 Oct 2014 16:25:29 +0200 X-Mao-Original-Outgoing-Id: 435939929.667533-fb9d48a7b5cee6f7ab6302148342484f Content-Transfer-Encoding: quoted-printable Message-Id: References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> <544A26B3.8020605@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/rCulfuoBycaQ775d1BgfT4G19E0 Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 14:25:56 -0000 On 24 Oct 2014, at 12:15, Julian Reschke wrote: >=20 > In general, the more "unbreakable" things there are, the harder it is = for the page breaking to do something useful without overrides. In this = case, I'd probably reformat the examples into smaller chunks (v3 will = allow multiple elements in one

). As an author, I=E2=80=99d rather put the page breaks where they make = sense and be done with it. While hinting is great for the first 80 %, there is no known way to = infuse a formatter with *all* the considerations that are immediately = obvious to a human observer. I think it is important to be able to put in such tweaks at the draft = stage as well =E2=80=94 this is the first time a specification gets many = new readers, and it is worth it making their work easier. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Oct 25 07:33:23 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDF31A0010 for ; Sat, 25 Oct 2014 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFWOKbt5R3rh for ; Sat, 25 Oct 2014 07:33:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A4B1A000B for ; Sat, 25 Oct 2014 07:33:20 -0700 (PDT) Received: from [192.168.2.160] ([84.187.62.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpbfG-1YM1n93Ox4-00fO77; Sat, 25 Oct 2014 16:33:18 +0200 Message-ID: <544BB495.8070108@gmx.de> Date: Sat, 25 Oct 2014 16:32:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Carsten Bormann References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> <544A26B3.8020605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:u4CJN2gyhQPzUcKDXTM+I6DZDm2cebwoEgbDxVguYy5e0Jqf7gY tu8pGSttyCFXYlpKQoeQR476m93L/sPbKAPddUFzDfYr5eW8pm4dPMlXdLxa011q9HhNLpe pOeFy7NvqleBNvXKwj3ky5It/qK3HHA9+SkndONcXf1/zZiJ5EnsnT+Gs1ndooNLxf3tlnR rjz6so10LmSNl2tziJcig== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/5DQ0BxcluMDQ799JXW79b8P5bSo Cc: Charlie Perkins , XML2RFC Interest Group , rfc-interest@rfc-editor.org Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 14:33:22 -0000 On 2014-10-25 16:25, Carsten Bormann wrote: > On 24 Oct 2014, at 12:15, Julian Reschke wrote: >> >> In general, the more "unbreakable" things there are, the harder it is for the page breaking to do something useful without overrides. In this case, I'd probably reformat the examples into smaller chunks (v3 will allow multiple elements in one

). > > As an author, I’d rather put the page breaks where they make sense and be done with it. Well, in a world where pagination depends on font, font size and paper format, you can't put a page break somewhere. You *can* include hints, though. > While hinting is great for the first 80 %, there is no known way to infuse a formatter with *all* the considerations that are immediately obvious to a human observer. > > I think it is important to be able to put in such tweaks at the draft stage as well — this is the first time a specification gets many new readers, and it is worth it making their work easier. I expect that once we're there, the majority of readers will actually read the HTML (which is a far bigger improvement than optimized page breaks in plain text). Best regards, Julian From nobody Sat Oct 25 09:53:37 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D1A1A00CF for ; Sat, 25 Oct 2014 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y09bufakzM8K for ; Sat, 25 Oct 2014 09:53:34 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5498F1A1AB6 for ; Sat, 25 Oct 2014 09:53:32 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-03v.sys.comcast.net with comcast id 7Ut71p0025Clt1L01UtX9E; Sat, 25 Oct 2014 16:53:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id 7UtX1p00K3Ge9ey01UtXan; Sat, 25 Oct 2014 16:53:31 +0000 Message-ID: <544BD58A.9040508@alum.mit.edu> Date: Sat, 25 Oct 2014 12:53:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: xml2rfc@ietf.org References: <543FD40B.5030308@pi.nu> <543FF9E6.2080001@seantek.com> <54400057.3030904@gmx.de> <54496B2E.5080400@gmx.de> <544981C3.7090305@earthlink.net> <5449EB3D.1030502@gmx.de> <5FB110ED-20C0-4CBE-B365-9BFFB72A350D@tzi.org> <544A26B3.8020605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414256012; bh=1wzZ1LAMh3GrUyUJbL/Y5E9Q9QT4di2EN+BibRTvMtE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jJ5F+v96iiBCNdKR7CCbk/yLAb25uNeDLefzwSLNTLBbkvwBoKXoAO6xlbFI8yRaI GYNkmIn0Am1mXaRxWS7btLzuAQECj20+5M3gZvoIMvBqmm3eemDVyAcIHGdda2lclq 30arNAEN9tiJivZyAuT/TynVxrT9X7MnD7kGvixg6gamvTAT2MnKJivpyCGsXdfjMR TO+aKv+uEaA0/3AjB9H+gzqJzoRa3TnGkQk7/KIuybAX8i4hTH2xQA7Zf9El5U8Oq+ SQ+lK21Shva+Xg9F80ptNxpsgO5c2L/8uMllLx0svBtuXc+LEgzD/AaPId0A7NUH8Q FGXGF7Llwt6kQ== Archived-At: http://mailarchive.ietf.org/arch/msg/xml2rfc/68vKHJeAQ7BGJa0Gre1_IgiFAoY Subject: Re: [xml2rfc] [rfc-i] will disappear X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 16:53:35 -0000 On 10/25/14 10:25 AM, Carsten Bormann wrote: > On 24 Oct 2014, at 12:15, Julian Reschke wrote: >> >> In general, the more "unbreakable" things there are, the harder it is for the page breaking to do something useful without overrides. In this case, I'd probably reformat the examples into smaller chunks (v3 will allow multiple elements in one

). > > As an author, I’d rather put the page breaks where they make sense and be done with it. > While hinting is great for the first 80 %, there is no known way to infuse a formatter with *all* the considerations that are immediately obvious to a human observer. As Julian already said, manual page breaks don't work when the pagination will be done for different page sizes, etc. > I think it is important to be able to put in such tweaks at the draft stage as well — this is the first time a specification gets many new readers, and it is worth it making their work easier. When I am writing MSWord documents I am often tempted to put in manual page breaks. But I've found that doing so usually results in a massive waste of time, because then every time there is a change to the document I may have to tweak them again. For the most part I have learned to just chill out and leave it to the pagination algorithm, and tolerate the inadequacies of the algorithm. It really isn't that important. I agree that hinting is a possibility. (I do often try to use "keep together" and "keep with next" in MSWord, though they only rarely seem to do the right thing.) IMO it would be better to put the work into the formatting tools - so that they work well without hints. Regarding unbreakable stuff screwing up pagination algorithms, I don't think anything should be *totally* unbreakable. There might be a rule that says to keep all of a single artwork together, but that still must be violated if the artwork is bigger than the page size. ISTM that boundaries between words, paragraphs, sections, etc. should each have some degree of "stickiness". Then the pagination algorithm can run some sort of minimization algorithm. Thanks, Paul > Grüße, Carsten > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc > From nobody Sun Oct 26 06:36:20 2014 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DCC1A8747 for ; Sun, 26 Oct 2014 06:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpQDjrU1Z0uY for ; Sun, 26 Oct 2014 06:36:15 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id A0C291A8746 for